Faster building means more product decisions, not fewer
There is a popular idea going around right now: building software has become so fast that product managers are no longer needed. Engineers can talk to users, AI can write the specs, and the layer in between can be removed.
It feels logical. If the expensive part of software was always the building, and the building is now cheap, then everything that existed to protect engineering time looks like overhead.
But that reasoning has a gap in it.
It assumes that product management is mostly about coordination. Writing tickets, running standups, translating between customers and engineers, keeping the roadmap document up to date. If that were the job, I would agree it is dying. AI is genuinely good at that kind of work, and honestly, it was never the valuable part anyway.
The actual job is deciding. What to build, for whom, in what order, and what to deliberately not build. That work does not shrink when building gets faster. It grows.
Think about what speed actually does to a team. Every shipped iteration ends in a fork. Do we go deeper here or move on? Did this solve the problem or just look like it did? What did we learn, and what does it change about the next bet? When a team ships five times faster, it hits those forks five times more often. The bottleneck quietly moves from writing the code to knowing what the code should do.
Building got cheap. Deciding did not.
Can engineers make those decisions? Of course. Some of the best product thinking I have seen came from engineers, and a team where nobody except the PM thinks about the product is a broken team. But whether a team needs someone dedicated to this depends on the cost of being wrong.
On an internal tool or an early prototype, a wrong guess costs a few days. You ship, you watch, you correct. The feedback loop is the product manager. But when a wrong assumption touches billing, onboarding, or a feature that thousands of businesses rely on, the mistake does not show up in a dashboard by Friday. It shows up as churn three months later, and by then the team has built two more things on top of it.
The faster you ship, the faster you can compound in the wrong direction. Speed is an amplifier. It amplifies good judgment and bad judgment equally.
This is also why the PM-to-developer ratio is a misleading number, even though many companies treat it as a benchmark. People point to teams running one PM per thirty engineers as proof that the role is fading, and to teams running one PM per five engineers as proof of bloat. Both readings miss what the ratio actually depends on: the shape of the work.
Product decisions do not scale with headcount. They scale with the number of parallel bets. If your product needs twenty or thirty engineers to build one feature, harden it, and make it stable, that is one decision stream. Most of the team is committing into the same task, and one product manager covering it is entirely reasonable. A ratio of 1 to 25 there is not a sign that product management is dying. It is a sign that the work is deep rather than wide.
Flip the shape and the math flips with it. A team of eight engineers spread across four small bets, each aimed at a different customer problem, generates far more decisions per week than thirty engineers grinding on one hard thing. That team can genuinely need more product attention than a team three times its size.
So when two companies land on wildly different ratios, it usually says less about their opinion of product managers and more about their products. Copying someone else’s ratio without their work shape is copying a number and hoping the context comes with it. It does not.
There is also a quieter problem with removing the role. The work does not disappear with the title. It gets distributed. Customer conversations happen, but nobody synthesizes them. Priorities get set, but by whoever argues loudest or whatever is most interesting to build. Every engineer carries a slice of the product hat, which sounds empowering until you realize that a decision owned by everyone is owned by no one.
I have seen this myself. And it usually works fine, right up until a problem arises that nobody wants to pick up and be responsible for. The setup looks healthy while things are going well, because shared ownership is easy when there is nothing hard to own.
The most visible symptom is the half-finished feature. Resources went into it, it shipped in some partial state, and then it just sits there. Nobody wants to remove it, because that means admitting the effort was wasted. Nobody wants to finish it, because it is not their problem and there is always something newer to build. So the product slowly fills up with stale features, each one a decision that everyone deferred and no one closed.
Some companies make that trade-off deliberately and it works for them, usually because their users are people just like the builders. When you are your own customer, your intuition is real data. The further your users are from you, the less that holds. Most software is built for people whose day looks nothing like the day of the person building it. Someone has to close that gap on purpose, repeatedly, as a job and not a side quest.
And AI does not close it. AI can summarize a hundred support tickets, draft a spec, and pull together competitive research in minutes. I use it for all of that. What it cannot do is own a bet. It cannot sit across from a frustrated customer and earn back trust. It cannot be accountable when the decision turns out wrong, and accountability is the whole point of having a decision-maker.
So no, I do not think the role is dying. I think it is being stripped down to what it always should have been. The ticket writing and status reporting are going away, and good riddance. What is left is judgment under uncertainty, and the faster the industry builds, the more of it is needed.
If your product manager only produced documents, AI replaced them a while ago. If they produce decisions, you are about to need more of them, not fewer.