What's Your PM-to-Engineer Ratio?
You can hit the ideal ratio and still have the wrong team
The ratio of product managers to engineers has been a point of conversation for as long as I can remember. Pre-Gen-AI, the guidance was one PM for every six to ten engineers. Post Gen-AI, the rhetoric among tech creators has flipped: we need more PMs per engineer so that execution doesn’t stop. The reasoning is that AI has now solved for the speed of building, so the bottleneck is identifying the right problems to solve.
I have seen teams where several roles split the coordination work between them. One person translated what the business wanted. Another turned that into features and user stories. A third kept the engineers unblocked. You can’t collapse that into a tidier ratio just because it looks top-heavy, because each role was doing a genuinely different job. But none of them owned the one thing that mattered most: the judgment of whether we should build the thing at all. The coordination was well staffed. The decision wasn’t staffed by anyone.
The problem is not that these roles exist. Coordination is real work, and the connective tissue that translates between business, build, and holding context across hand-offs is often the most undervalued judgment on the team. That is not the part AI touches. What AI absorbs is the mechanical output some of these roles have been reduced to producing: the decomposition, the user-story drafting, the status reformatting. If a product manager’s job had been narrowed to turning requirements into tickets, without the judgment of why we’re building, whether we should, or how we’ll validate it, then that narrowed job is exactly what AI now does in seconds.
Across enterprises, product and engineering leaders are resizing their teams for AI. Companies everywhere are laying people off in AI’s name, hoping to gain efficiencies and do more with less. And so the same question comes back, now with real stakes attached: what is the right ratio when AI writes the code?
The implicit assumption underneath that question is that team design in the AI era is a sizing problem. But the way I see it, we gravitate towards what we can easily count. Headcount is easy to count. Capability is not.
The PM-to-engineer ratio is a vanity metric. It counts what’s easy and hides what matters.
Two teams with an identical one-PM-to-five-engineers ratio can ship two completely different things. The variable is judgment density, the capability the ratio can’t see. A team can have the perfect ratio and still be the wrong team. An organization can be rich in headcount and rich in judgment, framing the problem well and deciding what not to build. Or it can be rich in headcount and stuck in feature-factory mode, waiting for requirements and shipping to a predetermined date. The ratio tells us nothing about which one we have.
AI is very good at producing that output faster than ever before. A right-sized feature factory using AI tools just becomes a faster feature factory, and it may ship the wrong thing sooner.
So the move for leaders is not to right-size the team to some tech creator’s generalized ratio, but to raise the judgment bar and build the right capabilities. Only then should we talk about reducing headcount. Density doesn’t show up on a spreadsheet, but it is readable. Here are the questions I’d ask to tell whether you have a headcount problem or a density problem:
Is each role on the team an order-taker or judgment-rich?
Where are the real gaps and bottlenecks?
How many hand-offs does it take for a requirement to travel from business to build?
When did the PM last do discovery with real users?
So we, as leaders, need to stop asking what the ideal ratio is and start asking how much judgment sits behind each unit of build. A number on a spreadsheet is not the same as a team that can make sound product decisions. And judgement is much harder to see. Its density is what decides whether AI makes you faster or just faster at being wrong.