The old trio is falling apart
Tech Lead, Design Lead, Product Manager. The classic product trio. Built on a premise that no longer holds: that the code is the expensive part.
Code is becoming a commodity. When a designer can prompt her way to a working prototype, and a PM can code an MVP in an afternoon, the team no longer needs to be organized around who executes what.
The question is what to organize around instead.
Three areas of competence, not three new titles
The easy reaction is to draw three new roles. The Generalist, the Architect, the Compliance Anchor. It’s tempting because roles are easy to talk about, easy to hire for, easy to put in an org chart.
It’s the same mistake product organizations have always made: believing that structure follows titles. That mistake is worth not repeating.
An honest counterposition: formal titles are not worthless. They force an articulation of responsibility that otherwise disappears into the informal (Pollok et al., 2019), and they are one of four interdependent legs, structure, processes, rewards, people, in a well-functioning organization (Galbraith, 1982). The point is not that titles should be abolished. The point is that they are secondary to the competencies, and most organizations have that order reversed.
Three areas of competence always need to be covered in a product team. How many people cover them, and whether the same people cover several, depends on context.
Generalist ability. Understanding users, business and product at the same time. The ability to ship without waiting for anyone. A year ago you would have called that an unrealistic profile. Today it’s just a person with an AI subscription and good product sense.
Architectural overview. Not to write the code, but to validate it. When everyone prompts their way to features in their own direction, someone has to make sure it holds together. That the database doesn’t look like a landfill. That the security model isn’t built on hope. It requires the one thing AI can’t replace yet: overview.
Compliance awareness. Security, GDPR, regulation. When code is written faster than ever, and half the team can’t explain what their own code does, the boring person in the room suddenly becomes the most important one.
Use the list as a check on whether the team is in balance. If one of the three is missing, you’re in trouble, no matter how many people you have.
Cagan’s four risks survive, the coupling to roles does not
This is not an excuse to forget customer value. Marty Cagan’s four risks still stand: can we build it, will anyone use it, will anyone pay for it, does it work for the business.
What changes is not whether the risks need covering. It’s who covers them.
The trio model, PM, designer, lead engineer, was held together by one premise: each role was the only one that could do its own work. The PM couldn’t code. Engineers didn’t do design research. Designers didn’t make product decisions. Collaboration was a necessity, not a choice.
That premise is gone. Any of the three roles can now draft the others’ work.
That doesn’t mean Cagan is wrong about the trio being valuable. He’s right that good product development requires the three disciplines to meet around decisions. But the rationale has changed foundations. What used to be held together by division of labor is now held together by division of decisions: by who knows what should be done.
The research points the same way
A study of 38 developers and 102 survey respondents found that people who assigned AI more fluid roles had higher adoption and use than people who locked it into a single role (Zakharov et al., 2025). The point is about AI, but it reaches further: organizing that lives on fluidity beats organizing that lives on titles.
That’s also where the debate stands right now. Cagan defends the trio model as elevated craft. Other voices, Benioff, Tsemirava and the versatilist school, argue that the roles dissolve into generalists with depth in one area.
My position sits closer to the second camp. Roles are useful as direction, not as walls.
Small teams win, and always have
The Team Topologies thinking from Skelton and Pais starts with a simple observation: dependencies between teams are the biggest scaling problem in modern software.
The insight isn’t new. Brooks’ law is from 1975: adding manpower to a late software project makes it later. An empirical study of 58 open source projects with 580,000+ commits and 30,000+ developers confirmed it quantitatively: coordination needs scale non-linearly with team size, and productivity drops (Scholtes et al., 2015).
We’ve known it for 50 years. And yet Danish enterprise projects have consistently solved delays by adding people. The deadline slipped, a consultant was called in, a new scrum team was formed, and the delay got worse.
Why? Because the alternative, saying we don’t have the capacity, we postpone or cut scope, has been organizationally impossible. Output was measured on “do we have enough people on the task”. So you hired more.
AI removes the excuse.
If three people can deliver what five could before, and five can deliver what ten could before, you can finally organize by the rule that was always right: keep teams as small as possible and dependencies out.
The idea is old. The difference is that for the first time it’s practically achievable in a Danish enterprise context.
What governs the product organization
When teams become small and self-sufficient, what does the product organization actually govern?
Not distributing tasks. Not tracking output. Not coordinating release notes. Not making capacity plans.
The product organization is governed by outcomes: which effects count, and which trade-offs are acceptable. Output becomes meaningless as a measure at AI volumes, because everyone can produce more. The only meaningful measurement left is whether something actually made a difference.
A structural point before it’s a people point. If output is still what decides budget, prioritization and direction, the whole rest of the pyramid collapses. Outcomes are the precondition for everything else.
Cross-team coordination, an open question
Cross-team coordination doesn’t disappear. It gets minimized, but it’s still there.
In an AI era I believe coordination moves from role to value stream. You organize around the path a customer’s problem travels from start to solution, and let teams follow the value stream instead of assigning them components. Roles still need to exist, but they’re secondary to what the structure serves.
The research agrees that moderate levels of coordination beat both minimal and maximal coordination (Hahn et al., 2025). In large organizations there are 27 different mechanisms that can carry that coordination (Berntzen et al., 2023).
I’m still in doubt here. This isn’t finished thinking. My preliminary position: follow the value stream, keep coordination as minimal as possible, and accept that something will still need coordinating across teams.
The principle for this layer
The principle is short:
As few people as possible. As few dependencies as possible.
That’s the frame everything else hangs on. Fewer people only becomes reality if the few who remain have the right combination of competencies, which is the subject of the next layer.