Does AI Replace Product Managers?

The short answer

AI does not replace product management. It removes the typing, not the deciding.

The common prediction goes like this: AI writes the code, so engineers take end-to-end ownership, and product managers and designers fade into a minority. Roles blur. Hybrid generalists win.

We believed a version of that too. Then we watched two teams do the opposite. Neither ended up with fewer roles. Both ended up with sharper ones.

The first team hired a second product manager

Two engineers, one product manager. This year their delivery got much faster. The engineers stopped writing code by hand — they now review it, test it, and own whether it ships.

Here is the part we did not expect. Within a few months the bottleneck moved off engineering entirely. It landed on deciding what to build next. There was always something waiting on a decision.

They hired a second product manager. Not because the work got easier, but because the queue moved.

The second team gave a junior developer work she should not have been able to own

A junior developer building an MCP layer, on a platform she knew almost nothing about. Normally that does not work. Owning a piece like that usually needs depth in the codebase and months of accumulated context about why things are the way they are.

She built it in a day and tested it end to end.

What made it possible was upstream. A couple of days went into getting the context right before she started, and the feature slicing was rewritten five or six times. What came out was a PRD and a set of acceptance criteria.

We asked her what was different. She had done this kind of work before, from tickets. Writing that level of detail by hand is slow, so tickets end up thin. Then the coding agent asks the questions the ticket did not answer, she cannot answer them either, and she is waiting on a lead. Her estimate: with the criteria written first, the agent asked her about 90% fewer questions.

That number is worth sitting with. How many questions a coding agent asks tells you how much you left undecided.

What actually changed

Both teams look like the merge prediction from the outside. Nobody is writing code by hand. Job titles are getting less useful. But the roles did not merge into one generalist. They re-formed around the two jobs that survived.

• Deciding. What are we building, what does done mean, what are we not doing. That work did not shrink when code got cheap. It got more exposed, because everything else got faster around it.
• Verifying and delivering. Does this actually work, does it hold up, does it ship. The engineer's job moved from typing to owning the answer.

Those are different skills. They did not collapse into one person. They separated more clearly than before.

Why the artifacts survive

A feature, a user story, an acceptance criterion are not paperwork. They are decisions written down early.

If nobody writes them, the questions still get asked. They get asked later, one at a time, by an agent in the middle of building, to a developer who cannot answer them. That is the same product management work, surfacing at the worst possible moment and in the least useful form.

So the job changes shape rather than disappearing. Less moving tickets around. More deciding, written clearly enough that someone else — or something else — can act on it without you in the room.

What this means if you are hiring

The experience a person needs to own a piece of work is partly a function of how much of the context lives in someone's head, and how much of it is written down somewhere they can read.

That changes who you can hire and what they can own. It also changes where your constraint sits. If your engineers get twice as fast this quarter, watch where the queue forms. In our experience it forms in front of the decision, not the build.

Where we would not oversell this

Two teams. Both small. One of the pieces described above is built but not deployed yet, so the proof is not complete — and built is not shipped. The 90% figure is the developer's own estimate, not an instrumented measurement.

We also build Feature1, which is a tool for writing this context down, so discount accordingly. The observation stands without it: watch where the queue forms after your engineers get faster. That is the job that matters next.