The PM-to-Engineer Ratio Just Inverted. Here's What That Changes.

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.