PM Ratios for Agentic Teams: Why Product Definition Is the New Bottleneck

Forty engineers, one PM, two designers. That is the actual headcount on OpenAI's Codex team, documented by Gergely Orosz in the Pragmatic Engineer.^[2] Most engineering leaders hit that number and reach for the same dismissal: exceptional talent, special circumstances, doesn't generalize.

Wrong question.

The interesting question isn't whether 40:1 ports to your org. It's why teams that respond to a PM bottleneck by hiring more PMs end up slower, not faster. Andrew Ng watched the traditional 6:1 ratio compress in real time on his own teams — six engineers per PM, then four, then two, then one-to-one — and then watched teams propose one PM for every half an engineer.^[3] The diagnosis is correct: engineering is no longer the constraint, deciding what to build is. The reflex fix — more PMs, deputize product-minded engineers — doesn't touch the structural cause.

The structural cause is misallocated decision authority. PMs hold the call on decisions where engineers carry more context. Engineers wait on permission for decisions they should be making alone. Adding people to that topology doesn't fix it. It adds more people navigating the same confusion at a higher coordination tax.

Engineering velocity was the dominant constraint for most of the last decade. Build cycles took weeks. Sprints felt perpetually behind. PMs kept the backlog deep because engineering needed the buffer — without it, engineers stalled between batches of well-defined work.

Agentic coding tools compressed that buffer hard. GitHub's study with Accenture across 4,800 developers found PR cycle time dropped from 9.6 days to 2.4 days — a 75% reduction.^[7] Successful builds increased 84%. Code generation quality improved enough that review friction dropped with volume. Teams running Claude Code, GitHub Copilot in agent mode, or Cursor with autonomous features routinely report 2–3x velocity on individual tasks.^[4] Test generation, boilerplate, and documentation move even faster. The backlog that took a quarter to clear now ships in weeks.

This is not a new problem appearing. It's an old problem that engineering throughput was masking. Product definition was always the constraint. Deciding which problem to solve, for whom, to what fidelity, in what order — that work was never fast. It didn't matter how slow it was when engineering was slower.

Now it matters. McKinsey's study of 40 PMs across the full product lifecycle — discovery, viability, build — found AI lifted PM output by 40%.^[8] That sounds good until you put it next to the 55% task speed gains on the engineering side and the 75% PR cycle time reduction. The gap is widening, not closing. The factory floor runs faster than the design room can feed it. And the standard response — add more designers — misses why the design room is slow.

The instinctive fix is more headcount. If the ratio is 1:8 and engineering doubled throughput, hire to 1:4. Some organizations are running exactly that play. 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]

It buys time. It doesn't fix the structure.

More PMs don't speed up product decisions. They multiply the number of people involved in making them. Each new PM brings coordination overhead: syncs with engineering leads, rituals with other PMs on cross-cutting concerns, backlog reviews, stakeholder management. Coordination cost scales with headcount. Output does not. Teams that doubled PM count during previous engineering productivity surges typically ended up with more process and the same velocity.

Here's the harder claim: the work that creates the product bottleneck isn't volume. It's ambiguity. One PM can't feed ten engineers because writing ten specs isn't what slows them down. Each spec carries discovery, stakeholder input, trade-off reasoning, iteration. Adding another PM doesn't compress that work. It splits the ambiguity into smaller piles with more handoff 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 carry better context. Engineers wait on permission for calls they're already qualified to make. 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 sit on a spectrum. One end: which problem to solve — PM-owned, requires customer proximity and business context. Other end: how to implement — engineer-owned, requires technical context and implementation knowledge. In most teams, PMs hold authority across the middle of that spectrum, where engineers actually carry more context: feature scope, API surface design, MVP boundaries.

A three-tier model makes the split explicit and enforceable. Marty Cagan's empowered teams framework gets at this — teams assigned problems to solve, held accountable to outcomes, given genuine authority inside a strategic boundary^[9] — but it predates agentic execution. The three-tier model extends it for teams where agents, not just engineers, are doing the execution.

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 calls require customer proximity and org-level visibility that most engineers don't have and shouldn't be forced 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 carry information the other doesn't. Joint authority means neither side proceeds alone, and the decision must land on a specific documented conclusion, not 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 calls 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 fell out of alignment as engineering velocity accelerated.

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

Each has a distinct job. The PM works upstream: crisp problem definitions, measurable success criteria, the business context that makes scope decisions sensible. Not a requirements document — a context document. What does a good outcome look like in 30 days? What's 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 stated intent. This is more product work than before — but it's product work inside 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 deciding 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 no one person could manage directly.

Shifting Tier 2 and 3 calls to engineers frees substantial PM time — that 40% productivity gain from AI tools becomes genuinely multiplicative rather than just keeping pace. What PMs do with it matters more than the reallocation itself.

The PM who was previously writing implementation specs, attending sprint ceremonies to track execution, and answering technical clarification questions mid-sprint now has 30–50% of their working week back. Teams that have run this restructure consistently report the same thing: PMs stop doing discovery work because they never had time for it, and then suddenly have time for it — but don't know how to do it well.

This is where the restructure stalls. The freed capacity has to go into Tier 1 work, not drift into other meetings.

Decision rights restructures fail quietly. The org chart changes, titles stay the same, and behavior drifts back to the old pattern within weeks. Watch for these.

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 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.

The org charts that will survive the agentic transition aren't the ones with the most PMs or the most engineers. They're the ones that figured out, precisely, which decisions belong where — and then had the discipline to hold the line. Every team already contains people with the right information for each tier. The question is whether authority is aligned with that information, or misallocated by title and historical habit. Fix the alignment, and the ratio takes care of itself.