Anthropic shared a number that reframes the whole "AI is replacing product managers" debate. With coding agents, their engineering output roughly tripled. Their product management output didn't move. Engineers ship faster than ever, and the work now piles up in front of the people who decide what to build.
That's the quiet plot twist of 2026. The story everyone expected was AI thinning out PM ranks. The story playing out is the opposite. When building gets cheap and fast, the scarce input becomes clear thinking about what's worth building, and that input still comes from a human.
The bottleneck didn't vanish. It moved upstream, and it landed on the PM.
The bottleneck moved, it didn't disappear
A system is only as fast as its tightest constraint. For fifteen years, that constraint was engineering. PMs wrote more than teams could build, so backlogs grew and prioritization was the art of choosing what to cut.
Coding agents broke that math. When a team ships three times the output, the queue drains faster than one PM can refill it with well-formed, well-reasoned work. The line that used to form in front of engineering now forms in front of product.
This is why the replacement narrative misreads the moment. Lenny Rachitsky ran an experiment pitting AI-generated PM work against human responses, and the AI version won two of three tasks. Impressive, and still beside the point. The output AI produces is only as good as the judgment that framed the request. Speed at the keyboard doesn't create the conviction about what matters.
The productivity gap that matters in 2026 isn't between PMs and AI. It's between PMs who use AI to think faster and those who use it to type faster.
What AI compressed, and what it didn't
Be precise about which parts of the job collapsed, because that's where the time savings are real.
AI compressed the production work:
- Drafting: first-pass PRDs, release notes, user-story breakdowns, and status updates.
- Synthesis: clustering survey responses, tagging interview transcripts, summarizing a quarter of feedback.
- Backlog mechanics: acceptance criteria, ticket formatting, routine grooming.
AI did not touch the judgment work:
- Deciding what's worth building when ten options all look reasonable.
- Reading a room and knowing which stakeholder fear is real and which is noise.
- Holding a position under pressure from a loud executive with a pet feature.
- Sequencing bets so the order itself creates leverage.
The first list used to eat most of a PM's week. Now it eats an afternoon. The second list never compressed, and it's exactly the part that determines whether the faster engineering team builds the right thing or the wrong thing at triple speed.
Why judgment and initiative resist automation
The durable part of the role is the part with no clean training signal. A model learns from patterns in what's been written down. The hardest PM work lives in what hasn't.
Initiative is the clearest example. Someone has to notice that a problem is worth solving before any prompt gets typed. As one commenter on Lenny's debate put it, the part that takes longest to automate is the grit and judgment to take initiative when nobody asked you to. A model waits for instructions. A product manager decides there's a fight worth picking.
Taste is the other piece. Knowing what good looks like for your specific users, in your specific context, isn't retrievable from a general corpus. It comes from talking to customers, watching them struggle, and building a mental model no document fully captures. AI can draft against that taste once you have it. It can't hand it to you.
Stop being the bottleneck without lowering the bar
The wrong response is to push more output through faster and call it productivity. That just moves low-quality decisions downstream at higher volume. The right response is to spend your reclaimed hours on the judgment work and to operationalize everything else.
Use the AI dividend deliberately:
- Reinvest, don't refill. The afternoon you saved on drafting goes into customer conversations and decision quality, not into producing more documents nobody asked for.
- Templatize the repeatable. Turn your recurring PM work into reusable prompts and skills so the production layer runs without you in the loop each time. This is where treating PM throughput as a system, the discipline behind product operations, pays off directly.
- Guard the decision, not the doc. Your signature goes on the call about what to build and why. Let AI handle the artifact around it.
Lowering the bar is the trap. When output is cheap, the only scarce currency left is whether the work was worth doing. Protect that, and you stop being the constraint by getting better at the part machines can't do, not by doing more of the part they can.
More PMs, not fewer
Follow the logic to its end and the staffing conclusion flips the headlines. If engineering throughput tripled and product is now the constraint, the way to speed up the whole system is to widen the constraint. That means more sharp product thinkers feeding faster teams, not fewer.
The role changes shape on the way there. Less time assembling documents, more time deciding and defending. Smaller PM-to-engineer ratios stop making sense when one PM can no longer keep three accelerated engineers supplied with good problems.
The PMs who win the next two years aren't the ones who type the fastest with AI. They're the ones who kept their judgment sharp while the production work got automated around them, and who learned to feed a faster machine without feeding it the wrong things.
