The PM-to-Engineer Ratio Just Inverted. Here's What That Changes.
The PM-to-engineer ratio has inverted. Andrew Ng's observation: teams have gone from 1 PM per 4 engineers to 2 PMs per 1 engineer. The bottleneck has moved from engineering to product. Here's what that changes about how you work.
For most of the last decade, product teams have operated on roughly the same ratio: one product manager for every four to six engineers. It was the standard. It made sense. Engineering was expensive and slow, and the PM's job was to make sure those expensive, slow engineers were working on the right things.
That ratio is inverting. Andrew Ng recently observed that at many AI-enabled teams, the effective ratio has shifted from roughly one PM per four engineers to something closer to two PMs per one engineer. A single engineer with AI tools can now produce what used to require a team. Which means the bottleneck has moved — out of engineering and squarely into product.
This is not a hypothetical. If you've been in a fast-moving product team in the last eighteen months, you've already felt it. Engineering isn't the slow part anymore. Product is.
What the Old Ratio Was Actually Solving
The 1:4 ratio (one PM, four engineers) wasn't designed — it emerged from constraint. The constraint was that building anything took months. You needed a lot of engineering time to ship a feature, so you needed a PM to focus that time on the right things. The PM was the filter in front of the bottleneck.
In that world, the job of product management was largely about saying no. The engineering queue was always longer than what could be built. So PMs prioritised, wrote specs, managed the roadmap, and tried to make sure that when the engineering team finally finished something, it was something that mattered.
Discovery was valuable — but secondary. You could do a few customer interviews, sense-check the hypothesis, and move. There was so much time between deciding to build something and shipping it that you had plenty of opportunities to course-correct. The discovery loop was slow, but the build loop was slower.
What the Inversion Changes
When you can build in days what used to take weeks, the scarcity flips. Now the constraint is knowing what to build next. Engineers aren't waiting for you to finish implementing a ticket — they're waiting for you to tell them what to do next. And if you can't give them the next validated thing to work on, they'll build whatever's closest to hand.
This changes three things fundamentally:
1. Discovery is no longer optional.
In the old world, you could survive with patchy discovery. You had time. The build cycle bought you months to gather signal, refine the hypothesis, and adjust. In the new world, the build cycle might be two weeks. If your discovery practice is weak, you'll find out your bet was wrong just as quickly — but you'll have already shipped something to real users that you'll now need to walk back, patch, or maintain.
Keep reading
AI Decisions Need Product Boundaries: A Practical Guide to Bounded AI Decisions
AI is moving from generating answers to making small decisions inside real workflows. Here is how product teams define the boundaries before an AI decision reaches a user or system.
Spec Hallucination: The 15-Minute Claim Trace for AI-Written Specs
AI writes specs that sound sourced but often aren't. The Claim Trace is a 15-minute audit that labels every claim Sourced, Inferred, Assumed or Invented before engineering builds from it.
What Counts as Evidence? The Risk Receipt for Value, Usability, Feasibility, and Viability
AI made feasibility cheap to prove. Value, usability, and viability still need their own evidence — and a great prototype demo counts for less than it feels like. Here's the Risk Receipt framework for checking what you've actually retired.