The AI Product Operating Model Has a Survivorship Problem

The short version

This week Aakash Gupta and Rohan Varma published "The AI Product Operating Model," and the core argument is correct: the traditional product org rests on the belief that engineers are your scarcest resource, that belief is dead, and when building gets cheap the build-then-decide sequence inverts. The diagnosis is sound. The evidence is the weak part. Every case study, Cursor, Codex, Anthropic, Medvi, OpenClaw, is a company that won, and survivorship bias is the one bias built to make a true claim look far more proven than it is. The inversion is real and the case studies are the right tail, not the mean outcome. Three things the survivor stories hide: greenfield is the easy version, regulated domains punish the inversion, and the operating model was never the hard part. The hard part is the taste to know where it applies. So read the piece, then ask who tried this and is not here to tell you how it went, and design for that company too.

This week Aakash Gupta and Rohan Varma published "The AI Product Operating Model," and the core argument is correct. Their claim is that the entire traditional product org rests on a single belief, that writing code is hard and engineers are your scarcest resource, and that the belief is no longer true. When building gets cheap, the build-then-decide sequence inverts, you build first and evaluate second, and whole phases of the old SDLC collapse. I have been making a version of this argument for two years. So has anyone paying attention. The diagnosis is not where the piece is weak.

The evidence is.

Look at who is doing the carrying. Cursor. Codex. Anthropic. Medvi. OpenClaw. Every single name in that essay is a company that won. The whole argument is built on the survivors, and survivorship is the one bias engineered to make a true claim feel far more proven than it actually is. You only see the winners. The failures left no evidence, so the picture is skewed before you ever start reasoning from it. This is the same mechanism I keep coming back to in you're only listening to the survivors.

That matters, because the inversion is real and the case studies are not the mean outcome. They are the right tail.

The graveyard didn't write a blog post

For every Cursor running 40 engineers and one PM past 4 billion dollars in ARR, there is a company that read the same memo, fired half its product team, killed sprint planning, let agents ship straight to production, and is now quietly drowning in code nobody on staff can debug. They did not publish a retrospective. Losers rarely do. So the discourse fills up with the companies that survived the bet and goes silent on the ones the bet destroyed, and we mistake the survivors for the strategy.

“

Survivorship is the one bias engineered to make a true claim feel far more proven than it is. The inversion is real. The case studies are the right tail, not the mean.

”

The inversion can be both correct and dangerous at the same time. Most high-variance strategies are. Presenting the upside of a high-variance move as if it were the expected result is exactly how survivorship bias does its damage. If you want the same logic run forward instead of backward, that is the whole point of interviewing the planes that didn't come back.

Greenfield is not the hard problem

Cursor inverted its operating model with no legacy code, no compliance regime, no fossilized org chart, and no installed base to protect. That is the easy version. The essay even opens with a Codex hackathon where two engineers did in three days what a large enterprise had scoped at ten engineers and twelve months. I believe it. I also notice those were the cleanest possible conditions, a contained project handed to people who already think in agents.

The question every operator is actually sitting with is not "how did Cursor do it." It is "how do I move a four-thousand-person org with twelve years of technical debt and a SOC 2 auditor in the building toward this without the wheels coming off." That is the brownfield problem, and it is the entire job. The piece paywalls the playbook and waves at the transformation. The transformation was always the work, which is why I treat the operating model as a migration to run, not a diagnosis to admire.

Some domains punish the inversion

"Build first, evaluate second," with agents verifying their own output at the point of generation, is a beautiful loop when the cost of a wrong build is thirty minutes of agent time. I build clinical AI. In my world the cost of a wrong build is a misread medication, a denied claim, a patient harmed, or a regulator at the door. You do not get to ship it overnight and decide in front of the working product when the working product is making decisions about someone's health.

“

The inversion has a domain limit, and the further you travel from a code editor, the harder it bites. The model is not universal. It is conditional, and the conditions are the part nobody selling it wants to discuss.

”

The AI product operating model is not universal. It is conditional, and the conditions are precisely the part nobody selling the model is eager to discuss. Knowing which side of that line you are on is most of what I mean by knowing when not to use AI.

The part the survivors hide

Here is what the winner stories obscure. The operating model was never the hard part. Adopting it is a weekend of courage. The hard part, the only part that has ever been hard, is the judgment about where the model applies and where it quietly kills you. Cursor's team had that judgment. So did Codex's. That is why they are in the blog post and the graveyard is not. The model did not make them win. Their taste about when to trust the model made them win, and taste does not ship inside a downloadable diagnostic worksheet.

This is the same reason cheap building does not automatically produce good products, which I unpack in the prototype graveyard, and it is the dividing line in the old PM versus product builder ledger. The tooling inverted. The judgment did not get easier. It got more load-bearing.

Pick one thing to try this week

So read "The AI Product Operating Model." The diagnosis is sound and you should internalize all of it. Then ask the one question survivorship bias exists to stop you from asking: who tried this exact thing and is not here to tell you how it went? Write down the company that took the same bet and failed, in your domain, with your constraints. Design your operating model for that company too, because the odds are much better that you are them than that you are Cursor.

Sources: Aakash Gupta and Rohan Varma, "The AI Product Operating Model", Product Growth, June 17, 2026. Company figures (Cursor, Codex, Medvi, OpenClaw) are as cited in that piece.