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

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, because no term existed for what the strong companies had in common. When he finally had to pick one, he took product operating model partly 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 actually do discovery and land on something that works for the customer and the business. And how you build, test and deploy, which is not just shipping but 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, which is the point: they are what stays constant across companies that otherwise look nothing alike.

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, frequent, uncoupled releases. Instrumentation of everything. Monitoring of everything.

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

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 plainly.

There is a misreading in the other direction too, and it is worth naming before you pitch this internally. Empowered does not mean the teams decide everything. When Lenny Rachitsky relayed Meta's CTO describing that company as very top-down, with Zuckerberg and the execs setting the strategy and the big bets, Cagan answered that this is exactly what he sees in good product companies and 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, before you build, which number is supposed to move; Ronny Kohavi's overall evaluation criterion is the discipline that turns the third dimension of the product model from a claim into a measurement.