Product operating model: what changes when your team stops building features and starts solving problems

The gap between “we do agile” and actually working like a product company

Most companies think they’ve already made the shift to modern product development. They have product managers, they run sprints, they even talk about outcomes. But Marty Cagan’s 2023 book TRANSFORMED argues that the vast majority of these companies are fooling themselves. They’ve adopted the vocabulary of product companies without the underlying product operating model that makes the difference.

The book isn’t another manifesto about why product matters. It’s a tactical guide for leaders who recognize their current approach isn’t working and want to understand exactly what needs to change. Here’s what Cagan’s framework actually means for how your company builds products—and how to know if you’re ready to make the shift.

What the product operating model actually is

Cagan defines the product operating model as the fundamental way a company decides what to build, how to build it, and how to bring it to market. It’s not a process or a framework you can implement in a quarter. It’s an operating philosophy that touches every aspect of how product work gets done.

The model has three core components:

1. How you decide what problems to solve — Are decisions flowing down from stakeholders as features, or are teams discovering opportunities through direct customer and data exposure?
2. How you solve those problems — Are teams handed solutions to implement, or do they have the space and skills to explore multiple approaches?
3. How you hold teams accountable — Are you measuring output (features shipped) or outcomes (customer and business impact)?

What makes Cagan’s articulation different from previous product thinking is the emphasis on organizational transformation. He’s explicit that you can’t adopt this model by changing how product managers work. It requires changes to how engineering, design, leadership, and even finance operate.

The four key dimensions of transformation

In TRANSFORMED, Cagan breaks the product operating model into four areas that must change together:

• Product strategy — Moving from roadmaps of features to a clear vision and strategic context that guides team decisions
• Team topology — Shifting from project-based teams to durable, empowered product teams with clear ownership
• Product discovery — Building the capability to test ideas quickly before committing engineering resources [INTERNAL_LINK: product discovery]
• Product delivery — Enabling frequent releases and true continuous deployment

The key insight is that these dimensions are interdependent. You can’t have empowered teams without product strategy giving them context. You can’t do real discovery without the delivery capability to experiment quickly. Partial adoption doesn’t work—you get the costs of change without the benefits.

Feature teams vs. empowered product teams: the core distinction

The most important distinction in the book is between what Cagan calls “feature teams” and “empowered product teams.” Understanding this difference is essential because most companies think they have product teams when they actually have feature teams.

How feature teams actually work

Feature teams are the default in most organizations. Here’s what they look like in practice:

• Stakeholders (executives, sales, customers) define what needs to be built
• Product managers translate these requests into requirements and prioritize the backlog
• Designers create specifications for the approved features
• Engineers implement what’s been specified
• Success is measured by whether features shipped on time and on budget

The product manager in this model is essentially a project manager who gathers requirements, writes tickets, and coordinates delivery. Cagan calls this the “mercenary” model—teams that execute but don’t own outcomes.

Feature teams aren’t incompetent. Many ship reliably and work hard. But they’re structurally limited. They can only be as good as the ideas they’re given, and research consistently shows that even experienced executives are wrong about what customers need most of the time. Cagan cites the familiar statistic: roughly 75% of features don’t move the metrics they were designed to improve.

What empowered product teams do differently

Empowered product teams—what Cagan calls “missionaries”—operate on fundamentally different principles:

• Leadership assigns problems to solve (outcomes), not features to build
• Teams include a product manager, product designer, and engineers with the skills to solve the problem end-to-end
• The team has direct access to customers and data
• Product managers are accountable for value and viability; engineers own feasibility; designers own usability
• Teams run continuous discovery alongside delivery—always learning while shipping
• Success is measured by whether the problem actually got solved

The practical difference shows up in day-to-day work. In a feature team, the PM’s job is to define the what. In an empowered team, the PM’s job is to ensure the team discovers a solution that’s valuable (customers want it), viable (the business can support it), feasible (engineering can build it), and usable (customers can figure it out). [INTERNAL_LINK: product manager responsibilities]

The output-to-outcome shift in practice

The transition from output to outcomes sounds simple until you try to implement it. Cagan dedicates significant attention to what this shift looks like operationally because it’s where most transformations fail.

Why roadmaps become a problem

Traditional roadmaps are lists of features with dates. They feel like planning, but they’re actually commitments to specific solutions before anyone knows if those solutions will work. Cagan argues this creates three problems:

1. It assumes you know the right solution upfront — You’re betting months of engineering time on the first idea
2. It locks teams into delivery mode — There’s no time or permission to discover better approaches
3. It optimizes for predictability over impact — Success becomes “we shipped what we said we’d ship” rather than “we solved the problem”

The alternative isn’t “no roadmap.” It’s shifting what the roadmap contains. Instead of features with dates, you have problems to solve with timeframes. Teams commit to making meaningful progress on outcomes, not to delivering specific features. [INTERNAL_LINK: product roadmap]

How OKRs fit (and often fail)

Many companies adopt OKRs hoping they’ll create outcome focus. Cagan is notably skeptical about how most companies implement them. The typical failure mode: key results become feature delivery milestones in disguise. “Launch the new checkout flow” isn’t an outcome—it’s an output with different vocabulary.

Real outcome-based key results look different:

• “Reduce checkout abandonment from 68% to 55%”
• “Increase weekly active users among enterprise accounts by 20%”
• “Decrease time-to-first-value for new users from 3 days to 4 hours”

The test: could the team achieve this key result with multiple different solutions? If the KR specifies the solution, it’s not an outcome.

How to know if your company is ready to transform

Here’s where TRANSFORMED gets practical. Cagan doesn’t pretend every company can or should adopt the product operating model. He outlines specific preconditions and honest assessments of organizational readiness.

The leadership question

The first question is the most important: Does senior leadership actually want to work this way?

The product operating model requires leaders to give up direct control over what gets built. They set direction, provide context, and define success metrics—but they don’t dictate solutions. For many executives, this feels like abdicating responsibility. They were promoted because they had good ideas about what to build, and now they’re being told to stop having those ideas.

Cagan is blunt: if your CEO or CPO isn’t genuinely committed to empowering teams, the transformation will fail. You can’t implement this model bottom-up. Individual teams that try to operate this way in a feature-team company will eventually get crushed by the system.

Signs you’re ready

Beyond leadership commitment, Cagan identifies several indicators that a company is positioned for successful transformation:

• Product-market fit exists — You can’t run discovery-driven development if you haven’t found your core value proposition yet
• Engineering can ship frequently — If releases are quarterly events, you can’t run experiments; you need deployment capability first
• You have (or can hire) the right product talent — Empowered teams need PMs who can do discovery, not just project management
• There’s a clear business reason to change — Companies don’t transform because it’s philosophically better; they transform because their current model is failing

Signs you’re not ready (yet)

Cagan is equally clear about conditions that make transformation premature:

• Leadership sees this as a PM initiative — It’s an organizational change, not a process improvement
• You’re in crisis mode — Transformation takes 1-3 years; if you need results in 90 days, stabilize first
• Engineering is fundamentally broken — You can’t empower teams that can’t ship reliably
• The company culture punishes failure — Discovery requires running experiments, and experiments fail

The actual transformation path

If the book has a weakness, it’s that the transformation process can feel abstract. Cagan advocates starting with pilot teams—one or two groups that operate as empowered product teams while the rest of the organization continues normally. This lets you prove the model works in your context before asking for broader organizational change.

The pilot approach has specific requirements:

1. Pick the right team — A strong PM, capable engineers, and a problem worth solving
2. Get executive sponsorship — Someone senior needs to protect the pilot from organizational antibodies
3. Define real outcomes — The pilot must be accountable for business results, not just “trying a new way of working”
4. Timebox it — 3-6 months is enough to show whether the model works
5. Document everything — The pilot exists to learn, and those learnings need to spread

Companies like Trainline, which Cagan profiles in the book, took 2-3 years to transform fully. That’s not a failure—it’s realistic. The goal isn’t overnight change; it’s building evidence and capability progressively.

What this means for individual PMs

If you’re a product manager in a feature-team organization, TRANSFORMED might feel frustrating. It describes an ideal that seems impossible given your current constraints.

Cagan’s advice: focus on what you can control. Even in feature-team environments, you can:

• Talk to customers directly, even if it’s not expected
• Run lightweight discovery on assigned features—validate before building
• Share outcome data with stakeholders, gradually shifting conversation
• Build relationships with engineering and design that go beyond ticket handoff

You probably can’t transform your company alone. But you can demonstrate what better looks like, making the case for change with evidence rather than theory. [INTERNAL_LINK: product management skills]

The bottom line

The product operating model isn’t new—companies like Amazon, Google, Netflix, and Spotify have operated this way for years. What TRANSFORMED adds is a structured framework for how traditional organizations can make the shift, and an honest assessment of why most won’t succeed.

If you’re a leader considering this transformation, the first step isn’t implementing new processes. It’s answering honestly: are you willing to give up control over what gets built and hold teams accountable for outcomes instead? If the answer is yes, Cagan’s book provides a credible path forward. If the answer is no—or “yes, but…”—no process change will help.

For practical next steps, assess your current state against the four dimensions: strategy, team topology, discovery capability, and delivery capability. Find the biggest gap and focus there first. And if you’re early in your PM career, invest in learning discovery skills regardless of your current company—they’re what separate PMs who can thrive in empowered teams from those who can only manage backlogs.

Frequently asked questions