Product Management Is the New Engineering Bottleneck

The scrum master opens the standup. Engineering is ready. The sprint backlog has two tickets left and both are waiting on the product owner to finalize the acceptance criteria. The engineers have been ready since yesterday. The sprint ends in three days. This is not a failure of engineering velocity — it is a failure of product throughput. And it is happening on teams everywhere right now, because AI didn't just accelerate code output. It inverted who the constraint is.

Andrew Ng put it plainly: "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 debate that followed on Hacker News was heated — many pushed back, some agreed — but what teams are actually experiencing on the ground is harder to argue with. Engineer-to-PM ratios are collapsing from 8:1 toward 2:1 or even 1:1. One team proposed a ratio of 1 PM to 0.5 engineers, which would have sounded absurd a year ago. It no longer sounds absurd. It sounds like the direction things are moving.

The constraint shifted, and most teams haven't reorganized around it

The old world was built around engineering as the bottleneck. Engineers were expensive, their time was scarce, and the whole workflow was organized to keep them productive. PMs wrote detailed specs so engineers didn't waste cycles on ambiguity. Sprint planning padded timelines because implementation took longer than estimated. Roadmaps were quarterly because execution was that slow.

AI coding tools — Cursor, Claude Code, GitHub Copilot — compressed implementation time dramatically for a wide class of work. Greenfield features that took two weeks now take two days. Boilerplate that took an afternoon takes an hour. The constraint that the entire workflow was organized around softened considerably, and a different constraint — one that was always there but rarely rate-limiting — became the new bottleneck. As one framing that's circulated widely put it: "Product management overtook engineering as the limiting factor in value delivery." The friction of coding was nearly eliminated. The new limiting factor is the human-driven process of making smart, fast decisions.

What the product owner's day looks like when engineering runs at AI speed

Product owners and product managers were not designed for the throughput requirements of an AI-assisted engineering team. Their work — deciding what to build, writing acceptance criteria, resolving feasibility questions, reviewing scope, verifying delivery — was calibrated to engineering teams that moved at human speed. When engineering moves three times faster, every upstream and downstream function that touches the product owner becomes a potential queue.

Where a product owner becomes the active constraint in an AI-assisted sprint:

  Scenario 1: Feasibility question during ticket refinement
  Engineer: "Does a webhook endpoint already exist for this event type?"
  PO: "I'm not sure — can you check?"
  Engineer: opens code, looks around for 20 minutes, comes back with the answer
  Cost: 20 minutes of engineering time to answer a product question

  Scenario 2: Scope boundary decision mid-sprint
  Agent generates code that extends beyond the ticket's stated scope.
  PO needs to decide: accept the expansion, revert it, or reopen the ticket.
  PO is in two other meetings. Decision waits 4 hours.
  Cost: engineers can't merge; downstream tickets blocked

  Scenario 3: Pre-sprint backlog not ready
  Engineering team finishes sprint 3 days early. Backlog is thin.
  PO hasn't written the next batch of acceptance criteria.
  Engineers make judgment calls about what to build next.
  Cost: 30% of next sprint's output wasn't formally scoped

  Scenario 4: "Is this already built?" asked at planning
  Engineering asks whether a capability exists before estimating a ticket.
  PO doesn't know. Engineer is pulled in to check the code.
  Planning session extends by 45 minutes.
  Cost: engineering time used to compensate for product's context gap

The pattern across all four scenarios is the same: product doesn't have fast enough access to the system state required to make a decision, so either the decision is delayed, an engineer is pulled off the work to look something up, or the decision gets made by default — engineering makes a judgment call and product finds out at the demo. None of these outcomes are what anyone planned. They are all downstream of the same root cause: product owners stuck waiting on translation from engineering every time the codebase is involved.

Why the ratio collapse matters for how teams are structured

The engineer-to-PM ratio is not just a staffing curiosity. It is a proxy for where the leverage lives on a team. At 8:1, one PM coordinates eight engineers — the PM's decisions flow downward and the scarce resource is engineering time. At 1:1 or inverted, the PM's ability to make fast, well-grounded decisions is the thing that keeps engineering unblocked. The PM's decision throughput is the scarce resource.

Most product teams are not staffed, tooled, or trained for decision throughput. They are staffed for decision quality — careful roadmap thinking, stakeholder alignment, detailed requirements documentation. Those things still matter. But in an AI-assisted engineering environment, slow decisions are as costly as wrong decisions, because a team of engineers waiting on a product call is burning time at a rate that wasn't possible before AI tools existed.

The CTO or VP of Engineering who is watching sprint velocity improve dramatically while simultaneously watching delivery outcomes stay flat is often looking at this problem. Engineering is executing faster. Product is deciding at the same speed. The gap between those two rates is where the sprint slippage lives — not in implementation, but in the decisions that precede and follow it.

The information problem underneath the bottleneck

Most of the questions that make product owners a bottleneck are not hard questions. "Does this already exist?" "What would this change affect?" "Is this feasible given what's already built?" These are codebase questions. They have specific, current answers that exist in the repository. The reason they create a bottleneck is not that they are difficult — it is that product owners cannot get to the answers without asking an engineer.

That dependency — PO needs codebase information, PO asks engineer, engineer context-switches, engineer answers, PO makes decision — is the structural source of most product-as-bottleneck situations. Engineering adopted AI while product workflows stayed the same, and every question that routes through an engineer adds latency at the exact moment when teams need the least latency possible.

The same information problem shows up in feasibility discussions during refinement, in scope boundary decisions mid-sprint, in the "is this already built somewhere?" question that pops up at planning and stalls the whole session. Every instance of "let me check with engineering" is a product-as-bottleneck moment — small individually, compounding to a sprint-level drag in aggregate.

What self-serve product intelligence actually changes

When product owners can query the codebase and Jira state directly — in plain language, without an engineering call — the bottleneck dynamic changes. The question "does a webhook endpoint already exist for this event type?" gets answered in thirty seconds instead of a twenty-minute engineering detour. The scope boundary decision that was waiting four hours for a PO to come out of meetings gets made faster because the PO has the system context in hand when they look at the question.

Questions a product owner can answer without an engineering call — using Kognita:

  "Does a webhook endpoint exist for order status events?"
  -> Kognita: Yes. OrderWebhookController handles order.status_changed.
     Last modified in PLAT-441, sprint -2. Supports POST to external URLs only.

  "What services would a change to the user profile schema touch?"
  -> Kognita: UserService (owner), AuthService (reads email field),
     NotificationService (reads notification_prefs), AnalyticsService (reads
     account_created_at). Four services. Schema migration would require
     coordinated deploy across all four.

  "Is the reporting dashboard feature already partially built?"
  -> Kognita: ReportingService exists. Implements usage aggregation and CSV export.
     No frontend dashboard component found. PROD-88 (closed, sprint -5) covers
     the backend. PROD-91 (open, not started) covers the frontend. Backend is
     done; frontend is not.

  "What did engineering touch this week that wasn't in our sprint plan?"
  -> Kognita: Three files outside sprint scope modified. AuthService token
     refresh logic updated (no linked ticket). PaymentService added retry logic
     (linked to PLAT-503, which is in a different squad's sprint).
     UserService added deprecated endpoint warning headers (no ticket).

Kognita gives product owners, product managers, and scrum masters plain-language access to live codebase and Jira state. The queries above are real — "what services would a change to the user profile schema touch?", "is the reporting dashboard feature already partially built?", "what did engineering touch this week that wasn't in our sprint plan?" — and they return specific, grounded answers from the actual codebase, not from documentation that may be six months out of date.

The value is not that AI does the product thinking for the PO. The value is that the PO arrives at the decision point with an accurate picture of what the system currently looks like — so the decision is faster and better-grounded, not just faster. Every role is becoming more technical in the sense that everyone needs system context to do their job. Self-serve access is the way to close that gap without requiring product people to become engineers.

What changes when the bottleneck is named

Teams that acknowledge product is the current bottleneck — not as a criticism of the product function but as an honest systems diagnosis — can reorganize around it. Scrum masters can shift their facilitation from managing engineering blockers to managing product decision throughput. CTOs can instrument the right metrics: how long does a ticket sit waiting on product clarification? How many planning sessions run over because of feasibility questions that nobody could answer in the room?

Product owners who are given tools that reduce their dependency on engineering for information can move faster without needing to become technical. The standup question shifts from "what's blocking you?" answered by engineering with process blockers, to answered by product with decision points — and those decision points can be resolved when the product owner has system context at hand.

Final take

Andrew Ng's argument has landed. Coding is no longer the scarce resource it was for the first thirty years of software product development. What is scarce now is the ability to make fast, well-grounded product decisions — about what to build, at what granularity, with what constraints, against a codebase that is changing faster than any human team's mental model can track.

When product is the bottleneck, every unanswered question costs an engineer an hour of waiting. The answer is not more meetings between product and engineering — it is giving product teams direct access to the system state they need to make decisions without a meeting at all.