When Engineering Ships 10x Faster, Product Becomes the Wall: PM Ratios for Agentic Teams

One product manager for every 40 engineers sounds like organizational malpractice. That's the actual headcount ratio on OpenAI's Codex team — forty engineers, one PM, two designers — documented by Gergely Orosz in the Pragmatic Engineer.^[2] Most engineering leaders who encounter that number react the same way: "exceptional talent, special circumstances, doesn't generalize."

They're not wrong to be skeptical. But they're asking the wrong question.

The right question isn't whether a 40:1 PM ratio is achievable elsewhere. It's why teams that respond to their PM bottleneck by hiring more product managers so often end up slower, not faster. Andrew Ng watched the traditional 6:1 engineer-to-PM ratio compress in real time on his teams — to four, then two, then one-to-one — and then observed teams proposing one PM for every half an engineer.^[3] His diagnosis: engineering is no longer the constraint. Deciding what to build is. But the fix most leaders reach for — hire more PMs, deputize product-minded engineers — doesn't address the structural root cause.

The root cause is misallocated decision authority. PMs hold authority over decisions where engineers have more relevant context. Engineers wait for direction on decisions they're better positioned to make independently. Adding more people to that structure doesn't fix it. It adds more people navigating the same confusion at higher coordination cost.

In any constrained system, resolving one bottleneck reveals the next. Engineering velocity was the dominant constraint for most of the past decade. Build cycles took weeks. Sprints felt perpetually behind. PMs maintained large backlogs because engineering needed that buffer — without it, engineers would stall between batches of well-defined work.

Agentic coding tools compressed that buffer. Teams running Claude Code, GitHub Copilot in agent mode, or Cursor with autonomous features commonly report 2–3x velocity gains on individual tasks.^[4] Test generation, boilerplate, and documentation accelerate even more dramatically. The backlog that once took a quarter to clear can now be dispatched in weeks.

What this reveals isn't a new problem. It's an old problem that engineering throughput was hiding: product definition was always the constraint. Deciding which problem to solve, for whom, to what fidelity, and in what order — that work was never fast. It just didn't matter how slow it was when engineering was slower.

Now it matters. The factory floor is running faster than the design room can supply it. And the standard response — add more designers — misses why the design room is slow in the first place.

The instinctive fix is to add PM headcount. If the ratio is 1:8 and engineering doubled its throughput, hire to 1:4. Some organizations are doing exactly this. Anthropic, per 2025 reports, is both hiring more PMs and "deputizing product-minded engineers to act as mini-PMs on projects under two weeks."^[3]

The hiring response helps in the short term. It doesn't fix the structural problem.

More PMs don't speed up product decisions — they increase the number of people involved in making them. Every new PM brings coordination overhead: syncs with engineering leads, alignment rituals with other PMs on cross-cutting concerns, backlog reviews, stakeholder management. Coordination cost scales with headcount, not with output. Teams that doubled PM count during previous engineering productivity surges often ended up with more process, not less velocity.

There's a harder truth here. The work that creates the product bottleneck isn't volume — it's ambiguity. The reason one PM can't feed ten engineers isn't that they lack time to write ten specs. It's that each spec requires discovery, stakeholder input, trade-off reasoning, and iteration cycles. Adding another PM to the room doesn't make that faster. It divides the ambiguity into smaller piles with more handoff cost between them.

Correct diagnosis: most teams have the wrong people making the wrong decisions at the wrong time. PMs hold authority over decisions where engineers have better context. Engineers wait for permission on calls they're qualified to make independently. That's not a capacity problem. That's a decision rights problem.

The structural fix isn't more PM headcount. It's moving decision authority to where the relevant information lives.

Product decisions exist on a spectrum from "which problem to solve" — PM-owned, requires customer proximity and business context — to "how to implement the solution" — engineer-owned, requires technical context and implementation knowledge. In most teams, PMs hold authority over decisions in the middle of that spectrum, where engineers actually have more relevant context: feature scope, API surface design, MVP boundaries.

A three-tier model makes this split explicit and enforceable.

Tier 1 — PM authority. Which problem to solve. Who the user is. What success looks like. Cross-team coherence — ensuring individually reasonable features don't combine into incoherent product behavior. Priority ordering across the team's surface area. These decisions require customer proximity and org-level visibility that most engineers don't have and shouldn't need to acquire.

Tier 2 — Joint authority (PM + Engineer). Feature scope and constraints. MVP boundary. API surface principles. UX decisions that affect overall product coherence. These sit at the intersection of product intent and technical reality. Both parties hold information the other lacks. Joint authority means neither can proceed alone — and the decision must reach a specific, documented conclusion, not a vague consensus.

Tier 3 — Engineer authority. Implementation approach. Architectural trade-offs within the agreed scope. Agent task delegation and verification criteria. Test strategy. Deployment sequencing. Engineers own these decisions completely, including the downstream consequences. When a PM reviews a Tier 3 choice, they're consuming engineering time without adding useful signal.

This isn't a radical inversion of responsibility. It's a precise renegotiation of a boundary that became misaligned as engineering velocity accelerated.

Once decision rights are distributed, the functional unit changes. Traditional teams ran on a PM-Engineer dyad: PM writes, engineer builds. In an agentic team, the functional unit is a trio: PM (intent), Engineer (judgment), Agent (execution).

Each role has a distinct job. The PM's work is upstream: provide crisp problem definitions, measurable success criteria, and the business context that makes scope decisions sensible. Not a requirements document — a context document. What would a good outcome look like in 30 days? What's the non-negotiable? What's the acceptable failure mode the team can learn from?

The engineer's job is translation and judgment: converting PM intent into a technical approach, making scope calls within the Tier 2 boundary, delegating appropriately to agents, and verifying that agent output actually satisfies the stated intent. This is more product work than before — but it's product work within a defined scope, not across the team's entire surface area.

The agent's job is execution: code generation, test creation, PR submission, documentation updates. Agents don't need product judgment. They need clear task boundaries and verification criteria. That's the engineer's domain to define, not the PM's.

The Codex team's 40:1 ratio works because the one PM operates exclusively at Tier 1. During bug triage sessions, they process over 100 issues in an hour using Codex itself — not writing fix specs, but determining which problems matter and in what order.^[1] The 40 engineers own everything below that priority signal. The PM provides the direction; the engineers amplify it through agents at a scale one person could never manage directly.

Decision rights restructures fail quietly. The org chart changes, titles stay the same, and behavior drifts back to the old pattern within weeks. Here's what to watch for.

PMs still in sprint reviews, focused on how things were built. If PM attention is on implementation choices rather than outcome progress, Tier 3 authority hasn't transferred in practice. Implementation review belongs to the engineer and their metric.

Engineers escalating more decisions than before. This signals the authority map is unclear, or that engineers haven't internalized that the authority is genuinely theirs — that they won't be second-guessed for using it. Escalation frequency should decline over the first two quarters as the map becomes trusted.

Two engineers made conflicting implementation calls that created product inconsistency. This is the Tier 2 failure mode: decisions that needed joint PM-engineer input were treated as Tier 3 engineer-only calls. The fix is clarifying which scope and API surface decisions require the joint track — not pulling authority back from engineering entirely.

The PM starts giving implementation direction. "You should use a REST endpoint, not GraphQL" is scope regression into Tier 3. If a PM has a strong opinion about implementation, surface the underlying concern. Often there's a valid Tier 1 issue — customer-visible latency, API contract stability — expressing itself as a technical instruction. Address the concern at the tier where it actually belongs.

One pattern observed repeatedly in teams attempting this restructure: redistributing Tier 3 authority while keeping the old spec process intact. Engineers nominally had implementation authority but were still waiting on PM specs before starting. The ratio changed on paper. Velocity did not.