The PM-to-Engineer Ratio Is the First Thing AI Breaks

The short version

The product manager layoffs of 2025 and 2026 are being explained as a skills story: PMs did not adapt, AI made them redundant, the role is dying. That explanation is mostly wrong and it lets leaders off the hook. What is actually happening is a ratio correction. The PM-to-engineer ratio was never about engineers, it was about how much build output one PM could direct. AI raised each engineer's output two to three times, so the same team now generates far more work per PM, and the headcount math that held for a decade broke. This is not a verdict on whether PMs matter. It is arithmetic. But it has a sharp edge: the part of the job that gets compressed is coordination and throughput, and the part that survives is judgment. Here is the math, and what it means for where you want to be standing.

For a decade, the planning anchor was simple. One PM for every seven engineers, give or take. Platform teams ran leaner, zero-to-one teams ran richer, but 1-to-7 was the number that built org charts. I used it. Every product leader I know used it.

Almost nobody asked what the number was actually measuring. We talked about it as if it described engineers. It did not. It described how much build output a single human could feed with decisions, direction, and discovery. The engineers were just the proxy for the output.

Then AI changed the output without changing the proxy, and the whole formula quietly broke.

The ratio was always about output, not headcount

Think about what a PM is actually staffed to do. Not to manage seven people. To supply enough decided, discovered, prioritized direction to keep a certain amount of building productive. The ratio matched a human's decision capacity to a team's build capacity.

When each engineer ships two or three times as much, the build capacity behind that PM jumps without a single new hire. Same seven engineers, far more output, far more decisions required to aim it. The PM is now under-supplying a team that can absorb much more direction than before. Something has to give, and there are only two directions it can give.

Either each PM covers more surface area, pushing the ratio toward 1-to-15 or 1-to-20. Or the team needs fewer engineers to ship the same roadmap, which shrinks the team and the PM count with it. Both are happening right now, and both reduce PMs per unit of output.

“

The PM-to-engineer ratio was never about engineers. It was about how much build output one human could aim. AI changed the output and left the formula behind.

”

Why this looks like a skills purge and is not

Here is why the ratio framing matters, beyond being more accurate. If you believe the layoffs are a skills story, you conclude that the surviving PMs are the ones with the trendiest AI skills, and you go collect certifications. If you understand it is a ratio correction, you conclude something more useful and more uncomfortable: the question is not whether you have new skills, it is whether your particular job was on the part of the ratio that compresses.

Because the compression is not random. When one PM suddenly has to cover the span that used to take three, the only way that works is to automate away the coordination, the documentation, the status relay, the meeting overhead. That is the 80% that gets automated. What is left, the part that does not compress, is deciding what is worth building and why.

So the PMs who get absorbed into the wider span are the ones who were already operating as decision-makers. The PMs who get squeezed out are the ones whose value was being a very organized coordinator, because coordination is precisely the function the ratio shift consolidates. Same talented people in many cases. Wrong side of the math.

The leadership mistake I am watching in real time

If you run a product org, the ratio correction creates a trap, and most leaders are walking into it.

The trap is keeping roadmap ambition flat while pocketing the engineering productivity gain as a headcount cut. It is the path of least resistance. Engineers got more productive, so you ship the same roadmap with fewer people, lay off some PMs to match, and report efficiency. It looks responsible. It is quietly a strategy failure, because you just used a once-a-decade capacity increase to do the same amount of work with less, instead of doing dramatically more.

The better move is to expand ambition to consume the new output. The capacity is real. The question is whether your roadmap is big enough to use it. If you cut to match a flat roadmap, your competitor who expanded their roadmap to match the new capacity is about to out-build you with the same headcount you just trimmed. This is the old PM versus product builder shift seen from the org chart: the constraint moved, and the org that re-plans around the new constraint wins.

“

Using a once-a-decade capacity gain to ship the same roadmap with fewer people is not efficiency. It is handing the upside to whoever expands their ambition instead.

”

How to plan headcount when the ratio is moving

Stop planning in bodies. Plan in output and decisions.

Ask the real question: how much build capacity can one PM actually direct now that the relay and documentation work is automatable? It is a lot more than seven engineers' worth. Staff to that honestly, which usually means fewer PMs but materially stronger ones, each operating with a wider span and a thicker layer of agents handling the coordination underneath them.

Then make the deliberate choice the trap hides from you. Take the engineering productivity gain and decide, explicitly, whether you are banking it as a cut or reinvesting it as ambition. There is no neutral option. Not deciding is deciding to bank it, and banking a capacity windfall is the most expensive default in the building.

The PM role is not dying. The ratio that priced it is repricing, fast, and the reprice is brutal for coordinators and generous for deciders. If you are a PM, get on the deciding side of the line before the math finds you. If you lead PMs, spend the windfall on ambition, not on a smaller team doing the same thing. The ratio is the first number AI breaks. It will not be the last.

Sources: Marty Cagan / SVPG, on product team structure · Lenny Rachitsky, on PM ratios and team design · Stripe / a16z, on AI and engineering productivity