The Product Team: How does AI change the structure of a larger product organization?

In The New Team I described what a single AI-driven product team looks like: one Product Owner and one or two Developers, working in tight feedback loops that produce shippable software in hours rather than weeks. That post was about the atomic unit. This post is about what happens when you zoom out.

Most product organizations were not designed around a single team. They were designed around the assumption that delivering software is slow, expensive, and risky. Every layer of the org chart - the directors, the program managers, the design ops leads, the release coordinators - exists to manage that slowness and risk. When the underlying work becomes fast and cheap, those layers do not automatically become useful. Many of them become friction.

If we are honest about what AI does to delivery speed, we have to be equally honest about what it does to the rest of the organization that surrounds delivery.

The shape of the old organization

A traditional product organization has roughly three layers stacked above the development teams:

1. Coordination roles - program managers, release managers, scrum-of-scrum facilitators, delivery leads. Their job is to move information between teams and to synchronize work that has been split across team boundaries.
2. Specialist supporting functions - design, UX research, legal, security, accessibility, translation, technical writing, data, analytics. Each of these typically operates as its own team with its own backlog, intake process, and SLA.
3. Product leadership - directors and VPs of product who set strategy, manage roadmaps, prioritize across teams, and negotiate with stakeholders.

The shape of this organization makes sense when a feature takes six weeks to deliver. Coordination work is small relative to delivery work, so spending two weeks aligning teams before they start is acceptable overhead. Specialist functions can operate on their own cadence because the development teams will be busy for weeks regardless. Product leadership can plan in quarters because that is the natural rhythm of the work.

None of this is true anymore once teams are running on AI.

What breaks first

The first thing that breaks is the coordination layer. When a team can complete what used to be a two-week feature in an afternoon, the program manager who was scheduling a planning meeting for next Tuesday is now the bottleneck. The meeting itself takes longer than the work it was meant to coordinate. The Gantt chart is out of date the moment it is drawn.

The second thing that breaks is the specialist intake queue. If a development team can deliver a feature in a day but has to wait three days for a legal review, four days for translated strings, and a week for a design review, then the team’s effective throughput is set by the slowest external function, not by their own capability. We have simply moved the bottleneck.

The third thing that breaks - and this is the one most organizations do not want to face - is the assumption that product strategy is something a small group does at the top and then hands down. When teams can run experiments and ship variations in hours, the value of a perfectly negotiated annual roadmap drops to almost zero. The roadmap is wrong by the second week.

The shape of the new organization

I do not think the answer is to flatten the entire organization into a pile of two-person teams. Some structure remains useful. But the structure has to be optimized for a very different set of constraints.

Fewer, smaller teams

A product organization that previously had eight teams of six people will not need eight teams of two or three people. It will need three or four teams of two or three people. The output of an AI-driven team is large enough that you simply do not need as many teams to cover the same product surface area. This is the hardest thing for organizations to accept, because it implies that a meaningful portion of the engineering organization has to be retrained into different roles or moved into different work. A few candidates of where to move people are into a role to help build the technical implementations for the specialists mentioned in the next section or in a role to help define the experiments or build out agents that can analyze the data generated by the product experiments as described later.

The teams that remain should be aligned to product outcomes, not to technical components. Component-aligned teams (the “auth team”, the “billing team”, the “platform team”) made sense when changing a component was expensive. When changing code is cheap, you want teams aligned to the customer-facing outcomes they are responsible for, with the latitude to touch whatever components they need.

Specialist functions become platforms, not queues

The supporting functions should not be reshaped as queues that development teams submit tickets to. They should be reshaped as platforms that development teams consume on demand.

A design organization stops being a team that produces Figma files in response to requests, and becomes a team that owns the design system, the component library, and the MCP server or sub-agent that lets a development team’s AI generate compliant interfaces without a human designer in the loop. The designers are still doing design work - they are designing the system that the AI uses - but their output is consumed continuously and automatically, not ticket by ticket.

The same pattern applies everywhere. Legal builds an agent that knows the company’s contract language, regulatory constraints, and prior decisions, and the development teams call it. Translation builds an agent that handles strings on demand. Security builds skills and hooks that run inside the development loop. Accessibility builds linters and verifiers that the AI runs against every change.

The role of these functions does not disappear. The expertise is still required. But the unit of delivery shifts from “a human responding to a ticket” to “a system that responds in seconds”. The people in these functions spend their time building and maintaining that system rather than handling individual requests.

Coordination becomes lighter and more outcome-focused

Program management does not vanish, but it changes substantially. The work of synchronizing teams becomes much smaller because there are fewer teams and because feature toggles let teams ship independently and coordinate at the moment of release rather than during development.

What remains is genuine cross-team strategy work: deciding which outcomes to pursue, deciding when a multi-team initiative is worth the coordination cost, and deciding when to retire toggles. This is real work, but it is a fraction of what program management used to be. Most organizations will need one program-level role for what used to require an entire program management office.

Product leadership shifts from roadmap to experiment portfolio

The hardest shift is at the top. Product leaders accustomed to managing a roadmap of committed deliverables now have to manage a portfolio of experiments. The artifact they produce is no longer “here are the twelve features we will ship this year”. It is “here are the outcomes we are trying to move, here are the bets we are running this month, and here is what we have learned”.

This is uncomfortable because it removes the illusion of certainty that roadmaps provide. It is also more honest. For serious product groups, they have been trying to move toward this for years, but it was hard to execute on. AI changes this. The roadmaps were always wrong; AI just makes the wrongness visible on a much shorter timescale.

Product leaders also have to spend more time on what teams are not doing. With this much delivery capacity, the temptation is to build everything. The new job at the top is to defend focus and to kill work aggressively.

I also see two additional roles that are needed at the product leadership level. For smaller product organizations this could easily be one person wearing both hats.

The first role is a technical application lead who can design and implement the technical solutions that enable AI-driven delivery. They will focus on building out the agent plugins, workflows, and other technical components that make AI-driven delivery possible and reliable. This person should also work with the product manager to determine how to assign the work to the right teams. Finally, they should define the feature toggles, communicate them to the teams, and work with the product manager on releases.

The second role is a technical quality lead who can ensure that the AI-driven delivery is producing high-quality results. This is not a QA manager role. This person will focus on providing the necessary infrastructure, subagents and plugins to handle the integration testing of what the teams are rapidly producing. An emphasis could also be on delivering the proper AI based tools to handle non-functional requirements like security and performance.

What this means for headcount

I am going to be direct about this, because organizations dancing around the question is not helping anyone.

The total headcount of a product organization optimized for AI-driven delivery is significantly smaller than the headcount of a traditional one delivering the same product. The biggest reductions are in engineering, testing, and coordination. The smallest reductions - and in some cases growth - are in the specialist functions that are building platforms, because the platform work is real and was previously under-resourced in most organizations.

This is not a comfortable conclusion, and I do not present it as one. But pretending the math works out to the same number of people is going to leave organizations with cost structures that make them uncompetitive against companies that have done the restructuring honestly.

What this does not mean

It does not mean that people are interchangeable, or that experience does not matter, or that you can run a product organization without senior judgment. The opposite is true. The leverage of a single experienced person goes up dramatically when AI handles the mechanical work. A great Product Owner paired with a great Developer and a good set of agents will out-deliver an entire traditional team of fifteen.

It also does not mean that everything should be optimized for speed. Some decisions - the architectural ones, the regulatory ones, the trust-and-safety ones - still benefit from being slow and deliberate. The point is not to make every decision faster. It is to stop letting slow decisions impose their cadence on work that should be fast.

Where to start

If you are running a product organization today and you want to start moving toward this shape, I would suggest:

1. Pick one product area and let it run the new structure end to end. Do not try to restructure the whole organization at once.
2. Identify the specialist function that is most often the bottleneck for that team, and start the platform conversation there. The first agent or skill or MCP server you build will teach you what the next ones need to look like.
3. Stop committing to long roadmaps. Start committing to outcomes for the next four to six weeks and let the team’s experiments fill in the how.
4. Be honest about what the coordination layer is doing. If a meeting exists to track work that now ships faster than the meeting cadence, the meeting is the problem.

The product organizations that come out of this transition healthy will be the ones that treat it as a structural change, not a tooling upgrade. Buying every developer a Claude Code license and changing nothing else is not the answer. The answer is to redesign the organization around the new economics of delivery and to be willing to make the hard decisions that follow from that.