The Engineer-to-PM Ratio Is Collapsing — What That Means for Product Owners

Andrew Ng's argument is now landing in the org chart. The traditional software team, built around a ratio of roughly six engineers to every one PM, is inverting. Teams are reporting 2:1 ratios. Some are at 1:1. One team floated 1 PM to 0.5 engineers — a proposal that would have been dismissed as obviously wrong two years ago and is now at least discussable. The economic logic behind the ratio shift is clear: when coding is nearly free, deciding what to build becomes the expensive, scarce resource. The constraint moved.

Most product organizations have not caught up with where the constraint now lives. Product owners are still writing tickets for teams that outrun them. PMs are still running biweekly discovery cycles for teams shipping at daily cadence. Scrum masters are facilitating standups where agents have already completed the sprint backlog and engineers are waiting on the next spec. The org chart says product and engineering are peers. The reality is that product is now the bottleneck, operating on a cadence calibrated for a world where engineering was the slow thing.

Why the ratio is collapsing

The 8:1 engineer-to-PM ratio was always a reflection of where the work happened. Engineering was expensive, scarce, and slow to scale. Building a feature required significant engineering capacity — weeks of focused work, coordination overhead, code review cycles. Product management was cheap relative to that cost: one PM could generate more specifications than six engineers could implement. The ratio reflected that reality honestly.

AI-assisted development broke the underlying equation. When a PM writes a well-scoped ticket on Monday and it ships on Wednesday — with agents handling implementation, tests, and review scaffolding — the constraint moves. The expensive, scarce resource is no longer engineering capacity. It is the product judgment required to decide what to build, how to scope it precisely enough for agents to execute on it, and how to verify that what shipped matches what was intended. Those tasks are human, and they don't compress the way implementation does.

The Hacker News thread that took off last year — "Andrew Ng says the real bottleneck in AI startups isn't coding — it's product management" — was not a prediction. It was a description of what was already happening in teams that had meaningfully adopted AI tools. The inversion had arrived before most leadership teams noticed it in their org charts.

The engineer-to-PM ratio is collapsing in real teams:

  TRADITIONAL RATIO (2020–2023)
  Structure: 6–8 engineers per Product Manager
  Logic: Engineering was the expensive, scarce resource.
    PM work was cheap relative to engineering capacity.
    Ratio reflected where the bottleneck lived.
  Outcome: PM backlog was always ahead of engineering output.
    Engineers were waiting for specs, not the other way around.

  CURRENT RATIO (2025–2026)
  Structure: 2:1 in many AI-augmented teams; 1:1 increasingly common
  Reported: Some teams proposing 1 PM to 0.5 engineers —
    which would have sounded absurd twelve months ago
  Logic: When coding is nearly free, the value is in deciding
    what to build. The constraint is product judgment.
  Outcome: Engineering backlog runs dry. Agents build ahead of plan.
    PMs are writing tickets for work already in progress.

  THE INVERSION IN PRACTICE
  Old world: PM writes spec → engineers estimate → sprint starts
    → engineers are the bottleneck
  New world: Sprint starts → agents ship in 3 days → PM still
    writing acceptance criteria → agents go off-script
    → PM is the bottleneck

  Andrew Ng's framing:
  "The traditional software team is built around a ratio of roughly
  6 engineers to every 1 PM. That standard is set to be
  completely inverted."

  The economic logic is now undeniable:
  "As the friction of coding is nearly eliminated, the value
  shifts to identifying user needs, defining scope,
  and validating ideas."
  "Product management overtook engineering as the limiting
  factor in value delivery."

What the bottleneck actually looks like

The PM bottleneck is not a single dramatic failure. It accumulates through small gaps that each seem manageable. The backlog runs low on Wednesday. Agents pick up adjacent work. By sprint close, fifteen percent of what shipped wasn't formally scoped. The acceptance criteria for the feature that shipped Tuesday were written three weeks ago and don't quite match the implementation, but nobody notices until a customer complains. The discovery cycle produces insights two weeks after engineering has already made the decision the insights were meant to inform.

Each of these gaps is survivable in isolation. In aggregate, across a quarter, they produce a product that drifted from the roadmap in ways the team can't fully account for — and a product team that is perpetually catching up rather than leading. Engineering adopted AI and the product team got left behind, not because product was slow or disengaged, but because the cadence they were operating on was calibrated for a team that moved at human speed.

What the PM bottleneck looks like on the ground:

  SCENARIO 1: The empty backlog
  Week 3 of a 6-week quarter.
  Engineering has closed all sprint tickets by Wednesday.
  Agents are running and looking for the next task.
  PM is in a discovery interview and hasn't written the next epic.
  What happens: Agents start working on whatever looks adjacent.
    Engineers make judgment calls. By Friday, four things
    shipped that weren't on the roadmap.

  SCENARIO 2: Acceptance criteria lag
  A feature ships on Tuesday.
  PM had written acceptance criteria two weeks ago, before
    the implementation started.
  The feature looks correct to everyone in the room.
  The acceptance criteria specified a behavior the agent
    interpreted differently.
  Nobody notices until a customer files a bug three weeks later.

  SCENARIO 3: Feasibility bottleneck
  PM has an idea for a new feature.
  Before writing the spec, they need to know:
    Is this technically feasible given the current architecture?
    Does something like this already exist in the codebase?
    What would this touch if we built it?
  Old answer: schedule a 30-minute call with engineering.
  New problem: engineering is running agents 24/7 and the
    next available slot is Thursday. The PM loses four days
    waiting on an answer that takes thirty seconds to
    look up if you have codebase access.

  SCENARIO 4: Discovery cadence mismatch
  Team is running biweekly discovery cycles.
  Engineering is shipping at daily cadence.
  By the time discovery findings become accepted tickets,
    the feature they were intended to guide has already shipped.
  Product is validating decisions that are already in production.

The feasibility scenario is the one that compounds most quietly. A PM has an idea. Before writing a spec, they need three answers: Is this technically feasible? Does something like this already exist? What would it touch? In 2022, that required a thirty-minute call with engineering. In 2026, with agents running constantly and engineering calendars full, the next available slot is Thursday. The PM loses four days on a question that has a deterministic answer sitting in the codebase — if they could access it.

The wrong response: adding headcount

The instinctive response to a bottleneck is to add capacity where the bottleneck is. Hire more PMs. Hire more product owners. Scale the product function to match engineering throughput. This is the wrong answer for two reasons.

First, the bottleneck is not a capacity shortage — it is an information friction problem. PMs are slow not because there are too few of them but because every decision requires information they don't have direct access to. "Is this feasible?" requires a meeting with engineering. "What already exists?" requires reading code or asking a developer. "What would this touch?" requires a system walkthrough. The friction in each of those questions is the bottleneck, and adding more PMs who face the same friction produces the same bottleneck at higher cost.

Second, the ratio is collapsing because engineering capacity is effectively infinite relative to product judgment capacity. You can run more agents. You cannot clone product judgment. The answer is to make each PM faster — not to add more PMs who will all be slow for the same reason.

What self-serve answers actually change

A PM who can answer "is this feasible?" in thirty seconds, without a meeting, changes how they work. They explore more ideas before committing to any of them. They reject infeasible directions earlier, before spec-writing investment. They write tighter acceptance criteria because they understand the system context before writing the spec. They verify shipped features themselves instead of waiting for the sprint demo.

This is not a marginal improvement in workflow efficiency. It is a structural change in where the PM spends time. Right now, a significant fraction of product management time is spent on information retrieval — gathering the context needed to make a decision, rather than making the decision. Every meeting with engineering to answer a feasibility question, every Jira search to understand what already shipped, every slack thread to clarify whether something is deployed — these are information retrieval tasks dressed up as coordination. The cost is not just the time; it is the delay between idea and decision, which in an AI-speed engineering environment is often the difference between shaping the sprint and reacting to it.

Kognita as the self-serve layer for product teams

Kognita connects PMs and product owners to codebase and Jira state in plain language — no GitHub access required, no engineering call required, no waiting until Thursday. The queries that product teams currently route through engineering have deterministic answers in the system. Product owners stuck translating between what they need and what engineering can answer are paying an information tax that disappears when the answers are self-serve.

What PMs and product owners can answer in Kognita without engineering:

  FEASIBILITY
  "Does anything like a usage-based billing system already exist
  in our codebase, or would this be built from scratch?"
  -> Surfaces existing billing logic, pricing models, usage tracking
  -> Answers in 30 seconds what previously took a Thursday meeting

  SCOPE
  "What would adding SSO touch if we built it this sprint?"
  -> Returns: AuthService, UserService, SessionManager,
     3 API endpoints, 2 frontend flows
  -> PM now has scope grounding before writing a single line of spec

  SYSTEM STATE
  "Is the checkout refactor from last sprint fully deployed,
  or is there still work in progress?"
  -> Surfaces open PRs, deployment status, incomplete migrations
  -> PM can verify before telling stakeholders it's live

  DEBT CONTEXT
  "We want to add real-time notifications. Is there anything
  in the current architecture that would make this hard?"
  -> Returns: WebSocket infrastructure doesn't exist; NotificationService
     is synchronous; adding real-time would require new infrastructure
  -> PM adjusts scope estimate before the sprint starts

  WHAT CHANGED
  "What got built against the onboarding epic this sprint that
  wasn't in the original ticket scope?"
  -> Surfaces agent-driven additions, scope expansions, follow-on PRs
  -> PM stays calibrated without waiting for the sprint demo

The scope query is the one that changes pre-sprint behavior most directly. A PM who asks "what would adding SSO touch?" before writing the spec gets an accurate scope signal before the story pointing session. They write tighter acceptance criteria. They flag the cross-service dependencies before the sprint starts, not after an agent has opened six PRs across four services. That is the difference between product leading the sprint and product catching up to what engineering already started.

What CTOs and VPs of Engineering should notice

The ratio inversion creates a counterintuitive strategic priority. The highest-leverage investment for an engineering organization running AI-assisted development is not more agents, better models, or faster CI/CD. It is reducing the information friction facing the product team. If product is the bottleneck and each product decision requires an engineering call to gather context, the ROI on additional engineering capacity approaches zero — the output queues behind the product team's ability to direct it.

This is not a product problem to solve in isolation. It is an architectural problem for engineering leadership: what does the system look like when non-technical product owners can access codebase truth and Jira state without routing through an engineer? Every role is becoming technical in the sense that every role now requires system context to do its job — but that doesn't mean every role should have to read code to get it.

Founders and CTOs who understand the ratio shift are making product enablement an engineering priority, not a product team request. The teams that get this right in 2026 will ship more — not because they hired more engineers, but because they removed the information friction that was preventing product judgment from keeping pace with engineering output.

Final take

The engineer-to-PM ratio is collapsing because the economics of software development changed. When coding is nearly free, the value is in deciding what to build. Product management is now the limiting factor in value delivery — not because product teams are underperforming, but because the information infrastructure that would let them move at AI speed doesn't exist yet in most organizations.

The answer isn't more PMs. It's removing the information friction that makes each PM slow. When product owners can answer feasibility questions, verify what shipped, and scope accurately without engineering calls, the bottleneck moves. Self-serve access to codebase truth is not a developer tool. In 2026, it's a product management requirement.