Reset, Adapt, or Transform? Making Sense of the Product Operating Model
Lately, I’ve been hearing a lot about the Product Operating Model, largely due to Marty Cagan’s new book Transformed: Moving to the Product Operating Model, published in 2024. As a well-known product thought leader, Cagan presents the Product Operating Model as a way for organizations to move beyond outdated processes and truly embrace customer-driven innovation.
At Springbach, we’ve been digging in. One of the things I was most curious about was how this model differs from what we already know about Agile and Scaled Agile. What new and interesting concepts does it introduce? How does it help organizations execute strategy more successfully?
Rather than summarizing the book, I want to share the insights that stood out to me as a long-time practitioner in product development, agile frameworks, and enterprise transformation.
A Model with a Point of View
Cagan doesn’t hold back. In Transformed, he throws Accenture and SAFe under the bus in Chapter 1, making it clear that he believes many organizations have lost their way by prioritizing process over outcomes. Whether you agree or disagree with his critique, one thing is certain: the Product Operating Model offers a compelling alternative to the traditional frameworks many companies have relied on.
Three Dimensions of the Product Operating Model
The Product Operating Model is defined by three dimensions:
Changing How You Build
This is essentially DevOps. There’s little departure from industry best practices here—continuous integration, automated testing, and deployment pipelines remain essential.
Changing How You Solve Problems
This big takeaway here? Feature roadmaps are out. "Problems to Solve" are in.
Many organizations rely on feature roadmaps—detailed lists of planned features, often mapped out months (or even years) in advance. The problem? These roadmaps lock teams into predefined solutions before they’ve had a chance to deeply understand the underlying customer problems.
The Product Operating Model (POM) takes a different approach. Instead of committing to a fixed list of features, teams focus on "problems to solve"—real customer challenges that, if addressed, would drive meaningful outcomes.
This concept aligns with modern product thinking frameworks, such as Jobs to Be Done (JTBD) and Outcome-Driven Innovation. The idea is simple:
🔹 Feature Roadmap Mindset:
"We need to build Feature X, Y, and Z by Q3."🔹 Problem-Solving Mindset:
"Customers are struggling with [problem]. How might we solve it in a way that they love and that works for the business?"A word or warning here: you can’t give problems to solve to an unempowered team. To succeed, teams need both decision-making authority and the right skill sets to deeply understand the user, the business context, and the technical constraints.
Changing How You Decide Which Problems to Solve
The final dimension of the Product Operating Model highlights the product-specific capabilities required to establish a customer-centric vision and an insights-driven strategy. This means investing in the roles, activities, and discipline of Customer and User Experience to identify the most important problems to solve. Cagan references a Russian proverb:
"If you chase two rabbits, you will not catch either one."
Many organizations struggle with prioritization, spreading teams too thin across initiatives that don’t move the needle. A clear Product Vision and Strategy are critical to solving this.
Cagan goes on to define a cross-functional product team with these critical responsibilities:
Product Manager → Viability (Is this product worth building?)
Product Designer → Usability (Can users effectively use it?)
Tech Lead → Feasibility (Can we build it?)
I could contrast the entire model with the Scaled Agile Framework (SAFe), but I won’t do that here—except to note an interesting difference. SAFe defines its own cross-functional leadership team similarly, but with these responsibilities:
Product Owner/Manager → Viability (Is this product worth building?)
Tech Lead/Architect → Feasibility (Can we build it?)
Scrum Master/RTE → Sustainability (Can the team deliver effectively over time?)
Even then, I noticed that SAFe underemphasizes User Experience, while the Product Operating Model skims over the Process responsibility that helps teams work effectively.
Might I suggest—just as I’ve advised my clients for years—that four key functions must be represented in our teams?
Product Management (Viability) – Ensuring the product is valuable and aligned with business objectives.
Product Design (Usability) – Ensuring the product is intuitive and user-friendly.
Technology (Feasibility) – Ensuring the product can be built and scaled effectively.
Process Leadership (Sustainability) – Ensuring the team operates efficiently and improves continuously.
Only when all four elements are in place can teams truly balance customer needs, business goals, and execution realities to build great products.
As Cagan dives deeper into the Model itself, I would like to highlight 4 additional insights:
The Danger of "Domain Dogma"
The Product Operating Model places a lot of emphasis on Product Roles, such as Product Manager, Product Designers, and Product Leaders and makes it clear that the priority should be on empowering these product roles to deeply understand customer needs, business context, and how to create value. The need to make an investment in these roles is clear, but he also warns to be aware of whom you select to perform these roles. Cagan introduces the term "domain dogma" describing how deep expertise can sometimes become a liability. He suggests product leaders need to know their domain, but they also need to challenge assumptions and explore new ways of thinking.
Innovation Over Predictability
The Product Operating Model has 21 principles, most of which sound very familiar to the agile practitioner. A few have a slightly refreshed, modern take. One stands out to me specifically - Innovation over Predictability. For me, for many years, this was the great thing about SAFe – it provided predictability in a time when trust in product delivery was so low that we needed to prove we could meet commitments before we could challenge any other status quo. For a while, that was a kind of currency – let’s prove we can predictably deliver on our commitments, and once we do that maybe you will trust us enough to take our other ideas seriously.
Now, maybe it’s time to make innovation our currency. Maybe innovation should replace predictability.
"Let us prove that we create innovative solutions that solve real problems, and once we do that, maybe you will trust us enough to make the changes needed to do it predictably."
Continuous Discovery
I have always disliked "discovery phases"—sometimes at the expense of discovery itself. It's often used as an excuse for big, up-front planning to create the “perfect” solution and delays the delivery of any value for months and months. This model uses a term I had not heard before – Continuous Discovery. He declares that a true product team should be testing a large number of ideas but only building less than half of them. A team should be spending:
1 hour, 3 times a week, every week on Discovery.
This was a lightbulb moment for me. If we want better outcomes, we need better inputs—and that requires ongoing, structured discovery, not a big, upfront discovery “phase”. This is a concept I can get behind.
The Role of Transparency
Later in the book, Cagan highlights something I’ve seen in every dysfunctional program I’ve ever encountered:
"Product teams depend on executives to share as much relevant strategic context as possible so they can make good decisions. And executives depend on product leaders and teams to openly share the data and reasoning behind their decisions."
Lack of transparency is the root issue behind many failing initiatives. I don’t care what framework you use—if leadership and product teams aren’t sharing information openly, the model will fail.
Do You Need to "Transform"?
The final part of the book discusses transformation. Do you need to “transform” to the Product Operating Model? Maybe, maybe not. If you need something new and exciting to provide a fresh start, this is a great place to start, and you can expect to see a real payoff. But maybe you don’t need a complete overhaul. Maybe you just need to inspect and adapt your existing processes and ask what purpose those processes were meant to serve and if they are still doing that.
Here’s what I’ve seen:
Over time, organizations evolve and adapt their processes. But sometimes, we forget why we made certain compromises. If we take a step back and reflect on past decisions, we will likely realize that many of our process compromises are no longer relevant—they have become baggage.
Instead of a full "transformation," maybe what you really need is a reset—a moment to inspect and adapt and get back to the principles of whatever model or framework you have already invested in.
What’s Next? Let’s Experiment.
If you’re curious about the Product Operating Model, here’s how we can help:
✅ Need an assessment? We can conduct one in under a week.
✅ Have a problem to solve? We’ll work with you to design a pilot team to test the model, learn, innovate, and deliver results.
✅ Already committed to the Product Operating Model and looking for coaching? We have some of the best Delivery Coaches, Discovery Coaches, Product Leadership Coaches, and Transformation Coaches in the business.
💡 If you’re serious about innovation…