Two product leaders looked at the same discipline and drew opposite conclusions about whether it should exist.
Tom Verrilli, CPO at Whatnot, built his product org on the premise that "we regret that product management exists." Oshri Cohen, a CPTO writing in mid-2026, argued the role was "an optimization layer for a constraint, expensive software, that no longer exists."
Both statements sound like death notices. Neither one is. And the gap between how they sound and what they mean is the whole story of what's happening to product management right now.
Start with the scene that makes the abstraction concrete. A couple of years ago, someone took over product operations at Komodo and asked their PMs a deceptively simple question: how much time do you actually spend with customers?
The answer was 25%.
The rest broke down like this: 35% on documentation and specs, 25% on stakeholder alignment, 15% on general overhead. Three-quarters of the job was process.
Per the Komodo account: "the artifacts — the PRDs, the Figma files, the spec documents — were becoming the goal rather than the means to a goal."
That's the quiet indictment. Not that PMs were lazy or bad, but that the discipline had metabolized into ceremony. The PRDs, the three review cycles, the estimation sessions — every layer existed for a good reason, back when getting something wrong meant weeks of wasted engineering.
Then that world changed, and the ceremony stayed.
So when the panic-inducing numbers arrive, they land on a role that had already hollowed out from the inside. The 2026 CPO Insights Report, surveying more than 1,500 product leaders, found traditional PM roles down 30% across industries — as steep as 70% in SaaS.
The obvious read is extinction. The obvious read is wrong.
Because the same survey found a newer "Product Builder" category — roles blending product, engineering, and design, shipping with AI-native tooling — up tenfold over the same period.
That's not a profession vanishing. That's a profession being reassigned. What's declining, specifically, is the coordinator version of the role: the PM whose value sat in owning the roadmap and relaying information between teams through ceremony. What AI absorbed was the translation layer.
But "learn to prototype faster" is the shallow lesson everyone is drawing from this, and it's a trap. It answers who gets hired without answering what the role even is once the artifacts are automated. That deeper question is where Oshri Cohen's inversion earns its keep.
Here's his argument. 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, don't waste scarce engineering cycles. Every framework you know is downstream of that. RICE is a sorting algorithm over scarce capacity. Roadmaps are a communication artifact telling stakeholders to stop asking for things.
Now flip the constraint. When building is cheap, the danger inverts to errors of commission — building too many things.
Building is cheap; owning is not. The cost of a feature never fell as fast as the cost of building it. That gap is the entire story.
His sharpest line: "Building is cheap; owning is not." The cost of a feature never fell as fast as the cost of building it. Every feature you ship is something you must support, document, integrate, and eventually deprecate. That gap is the entire story.
Which means the frameworks aren't just dated — they're now pointed backwards. Sorting an infinite backlog is a waste of time when the real question is what work shouldn't exist at all. The new tools are filters, not sorts: Why does this exist? What happens if we delete it? What's the half-life of this feature once shipped?
The old job was to be the advocate for what gets built. The new job is to be the editor of what gets built.
That is a different temperament, and it is much harder.
Eric Lubow gives the failure mode a shape. AI didn't just speed up engineers; it let domain experts build internal workflows over a weekend. Building is everywhere now.
And when someone builds something useful, they solve their own problem — often well. What they skip is everything around it: the rollout plan, the downstream effects, whether it duplicates a capability already in flight, who owns the support burden when they move on.
His framing of the risk is precise: "It's that the right things become depended on before anyone has decided they should be."
Something becomes workflow-critical. It starts accumulating dependents. The product lens was never applied — not because anyone was negligent, but because the builder was focused on their own problem and nobody was watching the threshold.
That's Lubow's threshold principle: the level of rigor should match the weight of what's been built. A tool one person uses needs no PRD. A tool three teams depend on probably does. A system customers touch definitely does.
The PM's job isn't to gate the pipeline. It's to be the immune system that recognizes when a weekend-built tool has crossed a line into something the whole product now depends on — and to calibrate the response before it hardens into infrastructure by accident.
Notice what that requires. Not the fastest fingers in Cursor. The judgment to notice load-bearing when everyone else sees a handy side tool.
This is what survives, and it's more specific than "adapt or die." Elizabeth Stone, Netflix's CPTO overseeing product, engineering, and design, names it directly: per her, the most important skill she looks for is systems thinking, and separately she discusses how to manage the flood of AI-generated output without losing quality or signal. When output is cheap, the scarce capacity is discernment across the whole system.
Oji Udezue — three-time CPO at Typeform, Calendly, and Parsable — puts the same thing in terms a PM can act on.
He built a system of 17 skill files for AI-native product work, and the design principle underneath all of them is this: LLMs very rarely tell you no. So he built gates that do.
His vet-a-feature skill runs the sharp problem test — three questions, fail one and the idea is dead — then sets a bar: you need to be 3x better than the current workaround or nobody switches. The whole architecture exists to say no.
Then the line that should be pinned above every product org this year: "the scarce skill is no longer building something. It's the judgment to say this one and not that one. I call it Taste at Speed. You cannot prompt your way to this skill, and you can't hire an agent to hold it for you. You have to own it as a PM."
That's the reckoning, stated cleanly. Not "is PM dead," but: what percentage of your current work requires judgment that can't be synthesized, versus coordination that could run without you?
Most people, if they're honest, already know which side is larger.
The Komodo audit was uncomfortable because it exposed a discipline that had drifted into overhead. The CPO data looks like a funeral. But read both against Cohen's inversion and the arc reverses.
Building got cheap. Owning didn't. And the PMs who survive won't be the ones who learned to prototype fastest — that skill is now table stakes and half-commoditized already.
They'll be the ones whose judgment sets the threshold when everyone can build and nobody can tell what's load-bearing.
The demo replaced the memo. The taste to know which demo should ship — and which should never have existed — didn't go anywhere. It just stopped hiding behind the paperwork.