Product Management Was a Workaround. AI Removed the Thing It Worked Around.

There's a specific kind of awkwardness in product organizations right now that nobody is willing to name out loud. PMs are still running their rituals, discovery, prioritization, OKRs, JTBD interviews, RICE scores, roadmaps in three tidy columns labeled Now / Next / Later. Engineers are still going to those rituals. Designers are still building artifacts to feed them. The whole machine is humming.

And underneath, nobody is sure what any of it is for anymore.

I want to make a specific argument: product management as we know it was an optimization layer for a constraint that no longer exists. The constraint was that building software was expensive, so deciding what to build had to be careful, batched, and centralized. The PM role was the workaround. AI dissolved the constraint. The workaround is now overhead.

This isn't a "PMs will be replaced by AI" essay. That framing misses what's actually happening. PMs aren't being replaced. The job is being inverted, and most PMs are still doing the old job in the new world, with predictably bad results.

The forgotten origin of PM

It's worth remembering where the modern PM role came from. It crystallized in the 2000s and 2010s, in a very specific context: software was getting cheaper to build than ever before, but it was still expensive enough that a wrong bet cost six months of engineering capacity. Engineers were scarce. Engineering capacity was the binding constraint of the business. So you needed a role whose entire job was to pre-filter engineering work, to take the chaos of customer needs, market opportunities, executive whims, and competitive pressure, and convert it into a sorted, deduplicated, prioritized backlog that engineers could execute against without wasting their precious time.

Every PM framework you know is downstream of that constraint.

RICE? A prioritization heuristic for allocating scarce engineering capacity across more demand than capacity. JTBD? A method for reducing the dimensionality of customer requests so a small team could focus. OKRs? A coordination mechanism for making sure separate teams of expensive engineers were rowing in roughly the same direction. Roadmaps? A communication artifact telling stakeholders to stop asking for new things because the capacity is already booked.

Every one of these tools is an answer to the same underlying question: we can only build a little; what should the little be?

Now look at 2026. The cost of building has fallen by an order of magnitude in maybe eighteen months. A competent engineer with AI assistance is shipping in a week what used to take a quarter. A motivated non-engineer is shipping working software at all, which is a discontinuity nobody is fully reckoning with. The cost of building hasn't gone to zero, but it's gone low enough that building is no longer the bottleneck. Deciding what to build is no longer scarce-capacity allocation. It's something else entirely.

What the new constraint actually is

Here's the inversion: when building was expensive, the danger was failing to build the right thing. Errors of omission. So PM evolved into a discipline of careful selection, find the highest-value bets, sequence them well, don't waste engineering cycles.

When building is cheap, the danger is building too many things. Errors of commission. Every feature you ship is a feature you must support, document, train people on, integrate with the rest of the product, and eventually deprecate. The cost of a feature didn't decrease proportionally with the cost of building it. Building is cheap; owning is not.

This is the central fact most PM organizations are not yet metabolizing. They're treating cheap building as a license to build more, sprint velocity up, feature count up, roadmap density up, when the actual implication is the opposite. In a cheap-building world, the PM's job is to be the immune system of the product. To say no. To kill features. To resist the gravitational pull of "we could ship that in two days." To protect the conceptual integrity of a product that everyone, including AI agents on the engineering side, can now contribute to with very low friction.

This is a much harder job than the one PMs trained for. The old job was to be the advocate for what got built. The new job is to be the editor of what gets built. Those are different temperaments, different skills, different organizational positions.

Why most PM frameworks are now anti-patterns

If the constraint has inverted, then every framework that optimized for the old constraint is now optimizing in the wrong direction. Specifically:

Prioritization frameworks. RICE, ICE, MoSCoW, these are all sorting algorithms over a backlog. They presuppose that the backlog is the universe of valuable work and the question is what to do first. In a cheap-building world, the backlog is infinite by default, and the question is what work should not exist. Sorting an infinite list is a waste of time. The new tools are filters, not sorts. "Why does this item exist?" "What would happen if we deleted it?" "What's the half-life of this feature once shipped?" These questions are not in the standard PM toolkit.

OKRs. OKRs are a coordination protocol for keeping large, slow-moving organizations roughly aligned over quarters. They presuppose batch planning cycles. They presuppose that the cost of changing direction mid-quarter is high enough to justify the overhead of pre-committing to specific outcomes. Neither presupposition holds anymore. Most companies running OKRs in 2026 are running a quarterly theater of commitment over plans that everyone privately knows will change in week three.

Roadmaps. A roadmap is a communication artifact whose primary function was to set expectations with stakeholders about what they would not get. ("It's not on the roadmap.") That function relied on the underlying scarcity of engineering capacity. In a world where building is cheap, the roadmap becomes either dishonest (we're not really committing to this sequence) or constraining for no reason (we could ship that next week but the roadmap says Q3). The honest replacement is something like a thesis, what we believe about the market and why we're investing in this direction, combined with very short, high-confidence near-term commitments.

Discovery as a discrete phase. Classic discovery, interview customers, synthesize insights, identify opportunities, generate concepts, was a batch process designed to reduce expensive build risk. When build is cheap, the cheapest form of discovery is to build the thing and see what happens. Not always; some bets are still too consequential. But the default has flipped. The new question isn't "have we discovered enough to justify building" but "is building so cheap here that discovering through deployment beats discovering through interviews."

JTBD and persona work. These remain useful, but as editorial filters rather than generative inputs. Their original use was to focus a scarce engineering team. Their new use is to be the lens through which the immune system says no.

The PM as editor

If we take the inversion seriously, what does the role look like?

It looks much more like a magazine editor than a project manager. The editor doesn't generate the articles, writers do, and in the new world, "writers" includes AI agents and engineers prototyping freely. The editor's job is to maintain the voice and integrity of the publication: to reject pieces that don't fit, to commission specific work to fill identified gaps, to be the keeper of "what this publication is and isn't." The editor is judged not by how many articles they cause to be written, but by the coherence and reputation of the publication over time.

This is a fundamentally different posture than the modal PM job description. It selects for different skills:

• Taste. The ability to look at a feature and feel, before reasoning your way there, whether it belongs.
• Comfort saying no. Including to stakeholders who outrank you, and including to AI-generated proposals that look superficially compelling.
• Conceptual ownership of the product as a system. Not as a backlog. Not as a roadmap. As a coherent thing with edges.
• Willingness to be unpopular in the short run. Editing is a no-saying profession. PMs trained on stakeholder management and consensus-building find this culturally hard.

Most companies do not currently hire, evaluate, or promote PMs on these dimensions. They hire on framework fluency, stakeholder skills, and ability to ship. Which means most companies are about to discover that their best PMs in the old regime are not their best PMs in the new one.

The one-PM-many-experiments pattern

One organizational pattern is emerging that I think is worth naming explicitly because it doesn't have a clean name yet.

In the old model: one PM, one engineering team, one feature, one ship cycle. The PM's job was to be the single decision-maker for that team's output. The ratio was roughly one PM to five-to-eight engineers.

In the emerging model: one PM, many parallel experiments, many of them AI-driven. The PM is curating a portfolio of probes rather than managing a sequence of releases. They might have one or two human engineers and the equivalent of a dozen AI-driven build streams running in parallel. Their job is mostly to look at what came back, decide what's interesting, kill what isn't, and decide what to invest more deeply in.

This is closer to the way a venture investor works than the way a traditional PM works. The unit of decision is the experiment, not the feature. The skill set is portfolio judgment, not roadmap construction. The metric is signal-to-noise ratio on the experiments, not throughput on the backlog.

Companies that adopt this model can run with dramatically fewer PMs covering dramatically more product surface area. The PMs they keep are paid more and trusted more. The org chart compresses.

What to do if you're a PM right now

Three things. None of them are easy.

Stop measuring yourself by output. Throughput is no longer scarce; if you're competing on throughput, you're competing with agents that ship faster than you can prioritize. Measure yourself on what didn't get built that shouldn't have, and on the long-run coherence of the surface area you own. These are harder to point at in a perf review, which is exactly why they're now where the value lives.

Get embarrassingly close to your product. Use it. Build in it. Break it. Watch others use it. The PM whose value was synthesis of others' reports is being absorbed quickly. The PM whose value is direct judgment about the thing itself is harder to absorb because their input is taste, which models still struggle to replicate at consequence-bearing levels.

Be willing to argue for fewer features in front of executives who reward "shipping." This is the political price of the editor role. Most PMs will not pay it, which is why most PMs will be slowly absorbed into the very AI workflows they were supposed to be managing.

A closing observation

The most interesting product organizations I see in 2026 aren't the ones with the most PMs or the most sophisticated frameworks. They're the ones where someone, sometimes a PM, sometimes a founder, sometimes a single staff engineer with strong taste, is willing to be the editor. To say no, this isn't us. To delete features. To resist the gravitational pull of "we can build that in an afternoon."

Those organizations have products that feel like products. The ones without that role have products that feel like accumulations.

PM as a function isn't dead. The framework-driven version of it is. What's emerging in its place is smaller, sharper, and considerably more difficult, and the people who recognize the shift early are about to have an unusually good few years.