Product Operating Model
Marty Cagan’s framework for building technology products by consistently creating outcomes over outputs, using empowered cross-functional teams and continuous discovery.
Last updated: 2026-04-12
Overview
The product operating model (POM) is a conceptual framework from Marty Cagan and the Silicon Valley Product Group, formalized in the 2024 book TRANSFORMED: Moving to the Product Operating Model. It defines a set of first principles that leading product companies use to create technology-powered solutions.
Cagan’s definition: “The product operating model is about consistently creating technology-powered solutions that deliver value to customers and that also drive results for the business. It’s about achieving outcomes versus merely producing output.”
Three dimensions:
- How products are built — cross-functional teams own problems, not features
- How problems are solved — continuous discovery, assumption testing, iterative learning
- Deciding which problems to solve — outcome-driven prioritization
The POM overlaps heavily with Teresa Torres’s continuous discovery practices, and both share a foundation: the team building the product must be in regular contact with customers and empowered to make decisions.
Project Model vs. Product Model
| Dimension | Project Model | Product Model |
|---|---|---|
| Unit of work | Project (defined scope, start, end) | Product (evergreen, never done) |
| Success metric | On time, on budget | Outcomes delivered |
| Decision-making | Stakeholders dictate features | Teams own problems, stakeholders give input |
| Funding | Fund projects | Fund teams or outcomes |
| Planning | Annual roadmap of features | Continuous discovery, outcome-based planning |
The project model loses out on opportunities to learn from customers and refine products over time. “Projects have a clear beginning and end. Products are never done.”
Adoption: When and How
Readiness signals
Two CEO-level conditions are required (from Torres and Hope Gurion):
- The CEO believes the current way of working will not drive future success
- The CEO feels real pain from the status quo (lost market share, failed financial targets)
Without CEO conviction, transformation stalls when resistance inevitably rises.
Common triggers
- Facing increased competition
- Investing heavily in technology without achieving desired outcomes
- Seeing competitors succeed with the product model
Pilot team approach
The biggest mistake in adopting the POM: rolling it out to everyone at once. Training all teams simultaneously creates chaos and resistance that undermines the change.
The right approach: start with pilot teams — one or a few teams who adopt the product model while the majority continues on the project model. Once pilots demonstrate success and you understand what works in your context, scale gradually.
Pilot teams need:
- Clear mandate and executive air cover
- Regular rituals to share progress (discovery demos)
- Stakeholders who give input without dictating solutions
Transformation timeline
Years, not months. Transformation involves changing funding models, how leaders make decisions, and how teams operate. Manage expectations accordingly.
Empowered Teams
Empowered teams own customer problems, not a feature backlog. Key behavioral shifts:
- During planning, executives fund outcomes or teams — not projects
- Outcomes take precedence over outputs in day-to-day work
- Stakeholders give input on solutions but don’t dictate which solutions to build
Teams are held accountable to outcomes they’re chasing, not delivery of a pre-specified feature list.
Role Changes
CEO: Must champion the need for change; without CEO belief and felt pain, transformation fails.
Product leaders: Define the strategy, set the outcome objectives for teams, translate business goals into team missions.
Product teams (trios — PM, designer, engineer): Own the problem space. Conduct continuous discovery; make tradeoff decisions within their mission.
Stakeholders: Move from feature-requesters to input-givers. Provide business context and constraints; trust teams to figure out solutions.
POM in Different Contexts
Startups: No existing product yet? Start with a directional outcome. Even “whether or not” questions benefit from customer interviews, opportunity mapping, and assumption testing. Avoid the trap of pure ideation without customer contact.
Large enterprises: More stakeholders, more gatekeepers, harder coordination. Key challenges: enabling direct customer contact (sales/marketing often gatekeep), showing the right level of detail to stakeholders (not every interview, just the thinking that led to where you are), and scaling accountability when you can’t inspect every team directly.
Regulated industries: Additional constraints but still viable. Products in regulated industries are also evergreen and never done.
Signs the Transformation Is Working
- Executives fund outcomes or teams (not projects) during annual planning
- Outcomes take precedence over outputs in day-to-day work
- Product teams are empowered to solve customer problems, not just asked to build features
- Stakeholders give input on solutions but don’t dictate which ones to build
- Measurable improvement in the outcomes defined over time
Connections
- prototype-and-prune — Julie Zhuo’s parallel framing for AI-era product development; complements POM’s outcome focus
- agent-evaluation — Torres’s eval progression work connects directly to measuring product outcomes
- teresa-torres — continuous discovery is the discovery practice within the POM; Torres and Torres fill the “how to decide which problems to solve” dimension
- marty-cagan — originator of the POM framework
- product-development — broader topic area
Sources
- The Product Operating Model Explained: From Pilot Teams to Full Transformation — Melissa Suzuno, producttalk.org — added 2026-04-12; clipping: Clippings/The Product Operating Model Explained From Pilot Teams to Full Transformation.md