The Death of the Builder PM

"Wait, what?! Now that I've just installed Claude Code... Are you telling me that the Builder PM is already dead??"

Disclaimer: this post is purposefully provocative to get the conversation going. I don't claim to know what is going to happen, but I do believe the roles will change more than most people anticipate.

The product manager role was never really about building

The PM role did not start in Silicon Valley. It started in brand management.

In the 1930s, Procter & Gamble assigned individual managers to own specific products end to end, not to ship features, but to understand the market deeply enough to decide what the product should do, how it should be positioned, and whether it was creating value worth defending. The job was commercial at its core: read the customer, understand the economics, make the call on what to build and why.

That version of the role held for decades. Then software happened.

When engineering became the bottleneck, the role mutated

In the tech industry of the 2000s and 2010s, shipping software was hard. It was expensive, slow, and required close coordination between product thinking and technical execution. The PM who could navigate that, who could break work into stories, manage a sprint, and get things out the door, became enormously valuable. Execution fluency became the dominant PM identity.

The commercial instinct didn't disappear, but it got buried under backlogs.

Slowly, the role split. The Product Owner emerged as a standalone function, sitting inside the Scrum team, focused almost entirely on throughput. What got built and why, the judgment question, became someone else's problem, or nobody's. Understanding user stories started to matter more than understanding market economics.

Some people saw it happening and pushed back. Rich Mironov has spent two decades arguing that PMs who can't translate their work into the language of money get bypassed. This is not because they're bad at their jobs, but because they're optimizing for the wrong signal.

Melissa Perri made a the same argument from a different angle: organizations that measure PM success by output rather than outcomes fall into the build trap, and most of them never escape it.

They were right. The role had drifted from its original purpose.

Now AI is forcing the correction

Building is getting cheaper. Faster than most people expected, and faster than most organizations have updated their assumptions about.

The marginal cost of shipping a feature is collapsing. What previously required a dedicated engineering team working for months can now be assembled in days. When any team can build the same things in a fraction of the time, execution stops being the scarce resource. It becomes table stakes.

The bottleneck shifts. And when the bottleneck shifts, the value distribution shifts with it.

What becomes scarce is judgment: the ability to decide what to build in the first place, understand why it matters commercially, and assess whether it creates durable value rather than just activity. That has always been the core of the PM role. The builder era buried it. AI is bringing it back.

The convergence nobody is talking about

There's a structural change that will accelerate this. As AI enables engineers to cover more of the ground that previously required a dedicated PM layer (the translation work, the backlog management, the sprint coordination) the builder PM and the engineering role will increasingly converge.

We are already seeing technical operators take on full product responsibility without a separate PM, the same way we're seeing product people build entire software products without specialized engineering support.

What survives as a distinct role is the commercial PM: the one obsessed with market dynamics, customer economics, and business case construction. The one who can tell you not just whether the team can build something but whether it's worth building and for whom and at what price and against which alternative.

That version of the role is not at risk from AI. It is what AI makes more necessary.

Rich Mironov put it clearly at Productized Lisbon in 2025: AI may make software development more efficient. It does not resolve the judgment question. Efficiency at execution is table stakes. What remains scarce is the person who can tell you what to build, why it matters commercially, and whether it creates durable value.

The bar keeps rising

There is one honest complication worth naming. AI systems are beginning to demonstrate something that looks like judgment: the capacity to weigh competing considerations, surface options, reason through trade-offs. That does not neutralize the argument. It raises the bar.

The PM's judgment must operate at a higher altitude than what the model can replicate. And that required altitude keeps rising. The PMs who will be most valuable are not those who use AI as a shortcut to the answer. They are those who use it as a thinking partner while staying genuinely responsible for the decision.

The evidence from practitioners is consistent. The product managers retaining influence as structures flatten are those who anchor it in business outcomes rather than delivery metrics, who develop cross-functional fluency, who can reduce uncertainty earlier rather than waiting for clarity.

That description sounds a lot like the original PM.

Why this matters now

AI is changing the rules of the game, and it's only accelerating. I can't predict the future, but it seems clear to me that the roles and responsibilities in product development will evolve fast. It's important to discuss what actually changes for product leaders and their teams as AI becomes part of the infrastructure rather than just a feature.

I'm curious whether this framing resonates. Do you see it happening in your organization? Is the judgment/throughput distinction showing up in how your team is structured, or how you're being evaluated?

And if this kind of thinking is useful to you, should I keep writing?