POM vs APOM: Cagan and Scrum.org Compared

Part of our AI Driven Product Operating Model hub. Start there for the full map of guides, checklists and templates.

Two formulations dominate the conversation. SVPG’s Product Operating Model (POM) comes from Marty Cagan’s work with technology-powered companies. Scrum.org’s Agile Product Operating Model (APOM) arrived in September 2024 as part of its Professional Product Ownership initiative and extends Professional Scrum with product thinking.

Side by side

The shared core

Both reject the project model. Both give teams outcomes instead of feature lists, expect small, frequent releases, and say structure, incentives and culture have to change together. Scrum.org calls this being holistic. SVPG calls it moving to the model instead of adopting a technique.

The divergence

West's seven APOM characteristics include unique: each product may need its own way of working, and uniform processes are a constraint to justify rather than a default. He also warns that a product model optimizes at product level, so cross-product needs must be handled through portfolio choices and constraints. POM leans on a more defined shape drawn from companies like Amazon, Google and Spotify.

Seven APOM characteristics, mapped to POM

What Scrum.org practitioners report

• Scrum.org’s survey synthesis reports three problems: value competes with features and deadlines, evidence-based decision-making is inconsistent, and structural silos limit autonomy.
• The Accenture episode discusses how companies and organizations introduce APOM.
• The Dyno Therapeutics episode applies APOM ideas in a gene therapy lab, which shows the model working beyond software.
• The Toyota Connected episode covers funding models, product life cycles and dependencies as APOM shapes portfolio management.
• West’s later blog on the APOM Guiding Principles warns against “mechanical Scrum” and says AI may push organizations to become faster, smaller and flatter, as long as they have a strong evidence-based model.

Decision guide by situation

A blended approach

1. Use POM to describe the target: empowered teams, discovery, outcomes.
2. Use APOM’s four areas to audit strategy, people, structure and value cycle.
3. Use EBM measures to track whether the model is working.
4. Apply APOM’s unique principle: let each product tune practices within clear constraints.
5. Revisit quarterly, with change management owned by a named group.

OPERATING MODEL DECISION
Date:
Decision:
Area affected: strategy / people / structure / value cycle
Why now (evidence):
Alternatives considered:
Expected effect and how we will measure it:
Constraints this adds or removes, and why:
Owner:
Review date and result:

Product Teams and Scrum Teams: Where the Roles Differ

Teams adopting a product operating model often already run Scrum. So does the product team replace the Scrum Team, or sit next to it? Marty Cagan was asked this directly in an interview hosted on DZone, and Scrum.org’s own writing covers the Product Owner and Product Manager overlap. This guide compares the two and shows how to combine them.

What the two models say

In SVPG’s model, product teams are cross-functional, durable, informed by strategic context, empowered and accountable for results. They usually include product managers (value and viability, accountable for outcomes), product designers (usability and customer experience) and tech leads (feasibility and delivery), supported by product leaders who coach and provide context.

In Scrum, the Scrum Team has accountabilities for the Product Owner, the Scrum Master and the Developers. Dave West notes in the APOM State of Play series that Scrum makes the Product Owner accountable for maximizing value, while many companies add a Product Manager alongside a Product Owner or instead of one, and define the roles differently by size, industry and structure.

Where they differ

In a 2024 interview with Stefan Wolpers, Cagan argued that most Scrum teams are delivery teams with a Product Owner who mostly administers the backlog, that a Product Owner covers only a fraction of a product manager’s job, and that the Scrum team is missing a professional product designer. He added that the Scrum Master role usually falls to a delivery manager, and that in the product model product leaders (the managers of engineers, designers and product managers) take primary responsibility for coaching and developing their people. He also said Scrum is one delivery process, that engineers can use it if they like, and that many product teams have moved on to Kanban or a streamlined variant. His framing is blunt and it’s one side of the debate. Scrum.org’s view is that organizations define the Product Owner and Product Manager roles differently, and that Scrum makes the Product Owner accountable for maximizing value. Read the full interview for his exact words.

Mapping the roles

Combining them in practice

1. Treat the Product Goal as an outcome with a metric, so the Sprint cadence serves a result instead of a feature list.
2. Add a professional product designer to the team and bring discovery work into the Sprint rhythm.
3. Keep the Scrum Master’s focus on team effectiveness, and have product leaders provide strategic context and coaching.
4. Decide explicitly who owns each of the four risks: value, usability, feasibility and viability.
5. Review outcome evidence at Sprint Reviews, not just a demo of what shipped.

PRODUCT TEAM CHARTER
Team name:
Customer problem space we own:
Current outcomes (max 2):
Team members (product manager, designer, tech lead, others):
How we decide (solution decisions, who is consulted, who decides):
Release cadence target:
How we discover (customer touchpoints per week, experiment types):
Instrumentation and monitoring we rely on:
Stakeholders and how we keep them informed:
Boundaries: what we do not own:
Review date:

DISCOVERY DELIVERY DEMO
Team and outcome:
1. What we learned since last demo (evidence, not activity):
2. What we want to learn next, and how:
3. What we shipped, and what it showed:
4. Work shown: interview snapshots, opportunity map, assumption tests
5. What is slowing us down and what we need from leaders:
6. Questions and suggestions (leaders label suggestions as suggestions):
Decisions and follow-ups:

Product Portfolio and Team Topologies in an APOM

Once a few teams run as products, a new problem shows up: work that crosses products. Shared platforms, common customers, dependent launches and a single pool of money. West’s APOM series gives whole posts to portfolio management and to organizing the product group. This guide summarizes the ideas and shows how to apply them.

The core tension

West observes that leaders accept empowered teams as the answer in complex situations, but worry that local decision-making leads to local optimization that’s bad for the whole organization. A product model encourages each product to pursue its own agenda. Broad needs get handled by choosing the right products and introducing constraints, and evidence like cycle time and clarity about bottlenecks can make those constraints obvious.

Four questions West says come up

Managing the portfolio

Project portfolios track projects and dates. A product portfolio tracks products, their outcomes and the investment in them. Scrum.org’s portfolio material includes an episode with Toyota Connected’s Lucas Smith on funding models, product life cycles and dependencies in a complex product ecosystem, and another with Nabila Sattar Safdar on leading a transition from a project-based to a product-based portfolio. Both are worth a listen for practical detail; see the reading list in the hub.

Organizing the product group

West noted that ideas like Team Topologies affect how a product group is organized. Team Topologies, from Matthew Skelton and Manuel Pais, describes four team types, which are a useful vocabulary for product groups.

Practical steps

1. List your products honestly using the project-or-product diagnostic; split or merge where boundaries are wrong.
2. Name the few constraints that must apply across products, and the reason for each.
3. Use cross-product OKRs sparingly and tie them to outcomes the involved teams can influence.
4. Track flow data to find bottlenecks between teams before reorganizing.
5. Move funding toward products and outcome goals in stages, starting with one or two.
6. Revisit structure each quarter; West stresses change management should be built in, with executive support.

Dave West’s blog series continues with Part 3, on six guiding principles for product portfolio management, and Part 4, on organizing your product group. Read them for Scrum.org’s own principles. We haven’t reproduced them here.

PRODUCT DEFINITION CANVAS
Product name and customers:
Value delivered (customer and business economics):

STRATEGY (the why)
  Vision and goals:
  Outcome metrics:
PEOPLE (the who)
  Team members and skills:
  Culture and incentives that apply:
STRUCTURE (rules and tools)
  Governance and mandatory constraints:
  Third-party contracts:
  Process, systems and technology:
VALUE CYCLE
  Discovery (how we validate ideas):
  Delivery (how we release):
  Operations and support (who runs it):
Dependencies on other products:
What reduces this product's effectiveness today? Remove or justify:

Measuring the Model with Evidence-Based Management

Most organizations measure their products: usage, revenue, satisfaction. Fewer measure the operating model that produces them. Yet Scrum.org’s APOM treats evidence as the cornerstone of every decision, including the decisions that shape the model. This guide shows how to measure whether your model is working, using ideas from Evidence-Based Management (EBM).

Why measure the model itself

If outcomes are flat, the cause may sit in product choices, or in the model itself: slow decisions, silos, funding cycles that can’t move capacity, or constraints nobody remembers the reason for. West’s APOM characteristics include removing practices that reduce a team’s effectiveness unless they’re real governance or control needs. You can’t do that without evidence about which practices slow teams down.

The four key value areas

The Evidence-Based Management guide groups measures into four key value areas. The examples below are common ones, a starting point rather than a fixed list.

Measuring the principles of APOM

Scrum.org's Guiding Principles whitepaper provides specific evidence-based metrics for each principle and is the authoritative source. As an editorial starting point, here are questions that map to its four principles.

Flow metrics for structure

West notes that flow metrics become tools for managing the flow of work and the structure of product groups, and that data like cycle time and clarity on bottlenecks make cross-product constraints visible. Start with a few: cycle time, throughput, and where work waits. Use them to decide where to change structure, not to rank teams.

Balance evidence with action

West stresses that evidence informs decisions and encourages behavior, but it must be balanced with action. A scorecard with forty measures leads to analysis paralysis. Pick a small set per key value area, agree thresholds for what would change your mind, and review them on a fixed cadence such as the quarterly outcome review.

A 90-day measurement plan

1. Days 1 to 30: choose two or three measures per key value area; record current baselines even if rough.
2. Days 31 to 60: instrument the gaps; agree owners and where numbers live.
3. Days 61 to 90: hold the first evidence review; record decisions and what the data changed.

EVIDENCE SCORECARD
Product / group:
Quarter:
Current value
  Measure | baseline | now | decision it informs
Unrealized value
  Measure | baseline | now | decision it informs
Time to market
  Measure | baseline | now | decision it informs
Ability to innovate
  Measure | baseline | now | decision it informs
What did the evidence change this quarter?
What will we stop, start or continue?

Related guides in this hub

• AI Driven Product Operating Model
• What Is the Product Operating Model?
• Outcome-based funding and allocation
• POM in the AI era

Sources

SVPG introduction; Scrum.org, Agile Product Operating Model, "Guiding Principles" whitepaper, "State of Play Part 1" (May 12, 2025), and launch release (September 12, 2024). Also: DZone, "Marty Cagan on the Product Operating Model and Scrum’s Future" (interview); SVPG, "The Product Operating Model: An Introduction"; Scrum.org, "APOM State of Play, Part 3" and "APOM Guiding Principles Have Published". The role-mapping table is editorial. Scrum.org, "APOM State of Play, Part 1" (May 12, 2025), Parts 3 and 4, and Scrum.org Community Podcast episodes on Toyota Connected and portfolio transition; Skelton and Pais, Team Topologies. The portfolio table and practical steps are editorial. Scrum.org, Agile Product Operating Model resources, "Guiding Principles" whitepaper, and "APOM State of Play, Part 1" (May 12, 2025); Scrum.org Evidence-Based Management resources. Example measures are common EBM examples; the principle table is editorial.

Further reading: Stefan Wolpers, "From Agile to the Product Operating Model" (survey results, 48 practitioners, August 2026); Scrum.org, "Unlocking the Agile Product Operating Model (APOM): Addressing the Core Barriers to Value Delivery".