Cited from real sources 6 min read Updated September 2026

A framework by Marty Cagan

Marty Cagan's Product Operating Model: A Set of Principles, Not a Process

The product operating model is Marty Cagan's name for how the strongest product companies work. It is a set of 20 principles. They cover how you pick what to work on. They cover how you solve problems and how you ship. Cagan is blunt that this is not a process or a methodology. Companies that install the titles and the ceremonies see nothing change.

Why he picked the word model

It's a model, it's a conceptual model. It's not a process. It's not a thing. It's more of a set of principles.

A model is something you look at and decide whether it fits you. A process is something you roll out. Most adoptions fail on that distinction alone.

Marty Cagan Lenny's Podcast Watch at 1:03:58

The framework

Three questions, twenty principles

Cagan avoided naming this for two decades. Before the book, he told companies only that they could work like the best or work like the rest. No term existed for what the strong companies had in common. When he had to pick one, he took product operating model for what it does not say. Product-led and product-driven both land on the rest of the company as a power grab, so he ruled them out.

Underneath the label sit three questions. How you decide what to work on, which is product strategy. How you solve problems, which is whether anyone in the building can do discovery. It has to land on something that works for the customer and the business. And how you build, test and deploy. That is not just shipping — it's shipping in a way where you can demonstrate the outcome.

About 20 principles sit under those three, and he calls the whole thing the product model for short. None of them will surprise anyone who has worked somewhere good. That is the point: they are what stays constant across companies that otherwise look nothing alike.

There's a set of principles around the more cultural things, like innovation is more important than predictability.
Cagan, on the cultural principles Watch at 1:08:44

He named two more in the same breath: learning is more important than failure, and principles are more important than process. The delivery principles are just as plain, and just as hard to fake. Small releases. Frequent releases. Uncoupled releases. Instrumentation of everything. Monitoring of everything.

How to apply it

How do you actually move to the product operating model?

Six moves. The first three change what leadership hands teams. The last three change what the organization can support.

  1. 1

    Read what leadership handed your teams this quarter.

    If it is a list of features with dates attached, you run feature teams. That is true whatever the org chart says. That single artifact is Cagan's whole diagnostic.

  2. 2

    Hand over problems instead of features.

    One or two per team per quarter. Customer problems or business problems, on top of the keep-the-lights-on work every team carries.

  3. 3

    Move the measure from shipped to solved.

    Delivery stops earning credit on its own. Cagan frames it for executives as time to money rather than time to market, because that is the number they already care about.

  4. 4

    Put the product strategy back on leaders.

    Product teams do not do product strategy; product leaders do. Leadership places the bets, then gives teams real latitude to figure out how to win them.

  5. 5

    Staff the four competencies for real.

    A serious product manager. A real product designer. A real tech lead. And a product leader who can coach people and write an actual strategy. Most companies have the titles already.

  6. 6

    Raise release frequency until outcomes are checkable.

    Strong teams release on the order of 20 times a day. If you ship quarterly, you cannot test any outcome claim inside the quarter you made it.

They're given hard problems to solve, and the measure is not ship the damn thing. The measure is it solves the problem.
Cagan, on what an empowered product team is handed Watch at 22:02

Boundary conditions

When does the product operating model fail?

Works best when

  • Leadership will give up the feature roadmap and hand down problems instead
  • You can release weekly or faster, so an outcome is testable inside a quarter
  • The CEO and CFO are in the room, since Cagan wrote the transformation book for them and not for PMs
  • Real discovery skill exists in the building, or you are willing to hire it

Fails when

  • You rename the roles and keep the roadmap, which is the most common half-transformation
  • You scale by adding process rather than adding leaders
  • Releases are monthly or quarterly, so nobody learns fast enough for outcomes to mean anything
  • Product ops shows up framed around process and governance, which Cagan treats as a red flag

The first failure is the one worth staring at. Companies buy the vocabulary. They publish new titles. They keep handing teams a list of features. That leaves them with the cost of the change and none of the effect.

What makes it tricky is they have people with those titles, but they don't have people with those jobs.
Cagan, on the four competencies Watch at 1:06:28

The second failure is quieter and shows up later, once the company gets big enough that coordination hurts. Cagan traces it back to what Steve Jobs called the disease of process people, and he gives the fork.

There's two ways to scale. You can scale with process or you can scale with leaders. The only way I know that leads to good outcomes is scaling with leaders.
Cagan, on scaling Watch at 56:06

There is a misreading in the other direction too, and it is worth naming before you pitch this. Empowered does not mean the teams decide everything. Lenny Rachitsky once relayed how Meta's CTO described the company as top-down, with Zuckerberg and the execs setting the strategy and the big bets. Cagan agreed: that is what he sees in good product companies. He objected only to the label. Leaders place the bets. Teams own the solutions.

The part most teams skip is the last one, proving the outcome. Outcome language is decoration until you decide which number has to move, before you build. Ronny Kohavi's overall evaluation criterion is the discipline that turns the third dimension of the product model from a claim into a measurement.

The sources

Where Cagan discusses this

Cagan has been Lenny Rachitsky's guest twice. The 2024 episode is where he defines the product operating model and the four competencies. The 2022 one is where he lays out feature teams and the process trap.

Where experts disagree

Where operators disagree: is discovery a team capability, or the founder and five users?

Marty Cagan

describes a model where teams are given problems, not features, and anyone in the building can run discovery and land on something that works for the customer and the business. Installing the titles and the ceremonies without that is why most adoptions change nothing.

Garry Tan

is describing a company that has none of that yet: ship the jankiest version, filter a hundred curious people down to the five or six with a hair-on-fire problem, and let their reaction decide what is real. Discovery at that stage is the founder and five users, not a capability you distribute.

Cagan is writing for companies that already have a product worth operating; Tan is writing for the ones that do not yet. The failure mode is installing the model before anyone in the room has found fit, which produces the ceremonies Cagan warns about.

Useful? Send it to whoever is running your transformation deck.

Want the full playbook?

Get 128 product management frameworks.

34 frameworks 21 rules 65 heuristics & principles 49 operators

From Stewart Butterfield, Ami Vora, Codebase Guidelines, and 46 more. Drop one .md into Claude, Cursor, or ChatGPT. Your AI cites practitioners, not guesses.

See the pack

Instant .md download · One-time purchase · No subscription

New experts every week

Know when the next expert lands.

Gavel adds new operators to the database every week, each one with cited frameworks you can check and a note on where they disagree with the others. You found this page by searching. Get the next one by email instead.

53 experts 66 cited frameworks

Latest: Amjad Masad on Levels of AI Autonomy

One email a week, only when new experts shipped. Unsubscribe with one click. We never sell or share email.

Related frameworks