LeadershipNew·Falk Gottlob··9 min read

Cagan Built the Church. I Argue We Don't Need One.

Marty Cagan's product operating model optimizes for a constraint AI erased. The case for product builders over empowered PMs, and where my thesis breaks.

Marty Caganproduct operating modelproduct builderSVPGempowered product teamscontinuous discoveryAI product managementLeadership
Helpful?

Two-column diagram contrasting the Cagan product operating model (scarce build capacity, empowered PM as decider, discovery ritual) against the product builder thesis (scarce judgment, builders state a claim before they ship), joined by a shared bottom rule: the team that learns fastest about real customers wins.

The short version

Marty Cagan and I are now describing the same future. His product operating model, the empowered product team, dual-track discovery, the PM who owns outcomes, was a brilliant description of how scarce engineering capacity should be rationed. AI erased the scarcity. When an agent produces a working prototype in an afternoon, a philosophy built on rationing build capacity is solving last decade's constraint, and Cagan's own 2026 writing concedes it. The product builder thesis I argue for, PRD as output not input, prototype-first, the PM role dissolving into building, is better aimed at the new constraint: judgment and taste are scarce, build capacity is not. But it has its own holes, a survivorship problem, a thinking-never failure mode, and an unsolved coordination story, that most posts comparing product philosophies refuse to name. Here is the honest version of both.

Marty Cagan and I are now describing the same future. He just got there twenty years late, and I got there with too little scar tissue to prove it scales. That is the honest version of this comparison, and most posts comparing product philosophies refuse to write it.

So let's be ruthless with both.

What Cagan actually built

Strip away the books and the keynotes, and the Cagan canon is three claims. Empowered teams beat feature factories. Discovery is a discipline, not a vibe. Product managers own outcomes, not backlogs.

All three are correct. They were correct in 2008 and they are correct now. Inspired gave a generation of PMs language for why their job felt broken, and Transformed gave executives a model to point at. That is real impact, and pretending otherwise is contrarian theater.

Here is the problem. The Cagan model is a description of how Google, Netflix, and Amazon worked in a specific era, packaged as a prescription for everyone else. It assumes engineering capacity is scarce, that shipping is expensive, and that the PM's core value is deciding what gets built because building is slow. Every artifact in the system, the discovery cadence, the quarterly OKRs, the empowered trio, exists to ration a scarce resource. It is a well-built product operating model for a world where the bottleneck was the build.

That resource is no longer scarce. When an agent can produce a working prototype in an afternoon, a philosophy built on rationing build capacity is solving last decade's constraint.

Every artifact in the Cagan system exists to ration scarce build capacity. That resource is no longer scarce.

, The constraint shift

To his credit, Cagan knows it. In February 2026 SVPG published what he called a significant change to two decades of advocacy, openly warning product owners that their role may be theater that AI is now exposing. By April he was writing that in the age of AI, we are all builders, and drawing the line between building to learn and building to earn. That is the product builder thesis with an SVPG logo on it.

Good. Welcome. But let's name what that pivot reveals: the model needed a technology shock to update. A framework that only changes when the ground moves under it was never a framework. It was a snapshot.

Where the Cagan model fails today

It still centers the PM as a role rather than product as a behavior. Even the 2026 SVPG material frames AI as something the PM must upskill into. The deeper question is whether a dedicated decider is needed at all when the cost of trying things collapses. This is the same shift I argue for in PM as a Team of AI Agents: the work doesn't disappear, it stops needing a single human role to carry it. Cagan edges up to that question and retreats every time, because answering it honestly threatens the customer base.

It sells process to companies that lack taste. The product operating model is taught as installable. It is not. The companies that exemplify it had founders with product judgment, and the process grew around the judgment. Installing the ceremonies without the judgment gets you empowered teams confidently building the wrong things with excellent discovery hygiene. Taste is the part you can't install, and it is the part that was always doing the work.

Discovery has calcified into ritual. Dual-track agile, opportunity solution trees, weekly customer touchpoints. In strong teams these are scaffolding. In average teams they became the new theater, a way to look rigorous while deferring the decision. The honest 2026 move is to admit that a shipped prototype in front of a real user is now often cheaper and more truthful than three weeks of discovery interviews.

Now the uncomfortable part: where my thesis fails

The product builder argument, PRD as output not input, prototype-first, the PM role dissolving into building, has its own structural weaknesses. If I don't name them, this post is marketing.

It has a survivorship problem. The thesis works beautifully for senior people with decades of pattern recognition. I can skip discovery rituals because twenty-plus years at Microsoft, Adobe, Salesforce, and Smartcat installed the judgment those rituals try to simulate. Telling a four-year PM to just build is handing them a faster way to ship their bad instincts. Cagan's scaffolding exists because most people need scaffolding. My thesis quietly assumes they don't, which is its own form of survivorship bias.

Prototype-first can become thinking-never. PRD as output is right when the prototype is the argument. It curdles when the prototype replaces the argument. I have watched teams generate five working demos in a week and learn nothing, because nobody forced a falsifiable claim about the customer before opening the editor. Cheap building makes undisciplined teams more prolific, not more correct. Cagan's discovery dogma at least forced a hypothesis.

It underprices coordination. One builder with agents is unstoppable. Forty builders with agents and no shared strategy is forty divergent products wearing one logo. The Cagan model is bloated, but it is bloated with answers to coordination problems my thesis mostly waves at. "Platform thinking" is not an answer to who resolves conflicts between empowered builders. At Falkster.AI this costs me nothing because I am the coordination layer. At a 400-person company it is the whole problem.

It is untested at scale, including by me. I am building Falkster.AI as a founder with total context and zero internal politics. That is the easiest possible environment for the product builder model. The thesis earns the right to dunk on Cagan when it survives a regulated enterprise with three business units and a sales-led culture. Until then, intellectual honesty requires the asterisk.

Cheap building makes undisciplined teams more prolific, not more correct. A prototype that replaces the argument is theater with better production values.

, The asterisk on my own argument

So which is better?

Wrong question, but here is the direct answer anyway.

For where software is going, the product builder thesis is better, because it is built on the actual new constraint: judgment and taste are scarce, build capacity is not. Cagan's model optimizes for a scarcity that no longer exists, and his own 2026 writing concedes the point.

For most companies as they exist today, Cagan is safer, because his model assumes average people and builds guardrails for them. Mine assumes strong people and removes the guardrails. The brutal truth is that most product organizations are staffed for the Cagan world, and dropping them into the builder world without retraining is how you get fast, confident garbage. That gap, between cheap building and disciplined building, is exactly the cost of being wrong(coming Jun 18) when the guardrails come off.

The synthesis neither side has fully written: keep Cagan's insistence on falsifiable hypotheses and outcome accountability, delete his role theology and ritual stack, and replace it with builders who must state what they believe before they ship what they made. Discovery as a question you must answer, not a process you must follow.

What needs to change

For SVPG: stop protecting the PM title. Follow the 2026 pivot to its conclusion and say plainly that the empowered product team of 2030 may have no product manager in it, only product builders with different depth profiles. The hedging reads as customer preservation, not analysis.

For the product builder camp, which includes me: ship the judgment layer. The thesis needs an explicit answer for how non-senior builders develop taste without twenty years of reps, and an explicit answer for coordination beyond founder gravity. Building deliberate judgment reps(coming Jul 13) into the work is the start of that answer, but it is not finished. Until it is, we are selling a senior-only philosophy as a universal one.

Both schools agree on the only thing that ever mattered: the team that learns fastest about real customers wins. Cagan wrapped that truth in process. I'm wrapping it in tools. The customer doesn't care about either wrapper.

Build accordingly.

Sources: Marty Cagan / Silicon Valley Product Group, "Product Coaching and AI" (February 2026) and "We Are All Builders" (April 2026), svpg.com; Marty Cagan, Inspired and Transformed; Teresa Torres on continuous discovery and opportunity solution trees.

Share this post

Also on Medium

Full archive →

Frequently asked

What is Marty Cagan's product operating model?+

It is the framework Cagan built across Inspired and Transformed: empowered product teams beat feature factories, discovery is a discipline rather than a vibe, and product managers own outcomes rather than backlogs. All three claims are correct. The catch is that the supporting machinery, the discovery cadence, quarterly OKRs, and the empowered trio, exists to ration scarce engineering capacity. That scarcity is the assumption AI broke.

How is a product builder different from an empowered product manager?+

An empowered PM decides what gets built because building is slow and expensive, then hands a PRD to engineering as an input. A product builder treats the prototype as the output and the argument, building to learn before building to earn. The PM role stops being a dedicated decider and dissolves into the act of building, because the cost of trying things has collapsed.

Did Marty Cagan change his position on AI in 2026?+

Yes. In February 2026 SVPG published 'Product Coaching and AI,' which Cagan framed as a significant change to two decades of advocacy and which warned that some product roles may be theater AI is now exposing. By April 2026 he was writing that in the age of AI we are all builders, separating building to learn from building to earn. That is the product builder thesis with an SVPG logo on it.

Where does the product builder thesis fail?+

Four places. It has a survivorship problem, working best for senior people whose judgment the rituals were trying to simulate. Prototype-first can curdle into thinking-never when the demo replaces the falsifiable claim. It underprices coordination across many builders. And it is still untested at scale, including by me at Falkster.AI, where I am the entire coordination layer.

Is the Cagan model or the product builder model better?+

For where software is going, the builder thesis is better, because the new constraint is judgment and taste, not build capacity. For most companies as they exist today, Cagan is safer, because his model assumes average people and builds guardrails for them. The synthesis nobody has fully written: keep Cagan's insistence on falsifiable hypotheses and outcome accountability, delete the role theology, and make builders state what they believe before they ship.

About the author

Falk Gottlob

Falk Gottlob

Product Executive · Founder, Falkster.AI

Thirty years shipping product at Microsoft Research, Adobe, Salesforce (Marketing Cloud / Quip / Slack), and several startups including one $6.5B exit and one acquired by Microsoft. Now CPO at Smartcat and founder of Falkster.AI, writing this notebook from the boardroom, not the keyboard.

Comments (0)

Sign in with LinkedIn to leave a comment.

Sign in with LinkedIn
  • Be the first to comment.

Keep Reading

Posts you might find interesting based on what you just read.