What Is the Product Operating Model?

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

The product operating model, often shortened to POM or "the product model", is a conceptual model built on first principles that leading product companies hold about creating products. SVPG, the firm behind the term, says its purpose is to consistently create technology-powered solutions that deliver customer value and business results: outcomes, not just output. Marty Cagan and co-authors set it out in the 2024 book Transformed.

Three dimensions

• How products are built: Small, frequent, reliable releases: at least every two weeks, ideally continuously.
• How problems are solved: Teams are assigned problems and outcomes, then choose solutions that are valuable, usable, feasible and viable.
• Which problems to solve: Product leaders decide, guided by a customer-centric vision and an insight-driven strategy.

Five concepts, each with four principles

Who does the work

Product teams are cross-functional, long-lived and accountable for results. Product managers own value and viability, designers own usability, tech leads own feasibility, and product leaders coach the teams and give them strategic context.

Why companies move

SVPG points to competitive threats, the valuation rewards for companies that pull this off, and leaders frustrated that technology spending hasn’t delivered. The effort is big, so most organizations should start by working out how much of their current “product” work is really project work.

Project model vs product model in practice

Four risks every team tests

SVPG says product teams have to find solutions that are valuable, usable, feasible and viable. Discovery tests those risks early, when it’s cheap.

A worked example: from feature list to problem

Here’s an illustrative example. A subscription app team is told: “Add a referral program by Q4.” The product-model version starts with the problem instead: new customers rarely hear about the product from existing ones, and acquisition cost keeps rising. So the team gets an outcome, say raising the share of new sign-ups that come from referrals from [baseline] to [target]. Discovery might show a referral program is the answer, or that better in-product sharing of results works faster. Either way the team picks the solution, not the requester, and leaders review the reasoning.

STAKEHOLDER REQUEST REWRITE
Request as received (the output):
What problem are they trying to solve?
Who experiences it, and how often?
What would success look like? (customer behavior and business result)
How will we know? (metric, baseline, target, date)
What is the team free to decide?
What is non-negotiable, and why?
Agreed outcome statement:
  We will [change in behavior or result] for [customer group], measured by [metric], from [baseline] to [target] by [date].

The model through Itamar Gilad’s eight functions

Gilad, author of Evidence-Guided, describes a company as eight cross-disciplinary functions: strategic context, goals and metrics, research, product discovery, product delivery, go-to-market, operations and infrastructure, and culture. Traditional companies over-invest in execution (delivery, go-to-market, operations) and under-invest in observing and thinking (research and discovery). Use the eight as a diagnostic: which function is weakest in your company? See the evidence guide for the full comparison.

Where to start

1. Run the project-or-product diagnostic to see how much of your work is really project work.
2. Choose one durable team and give it a problem and an outcome using the outcome brief.
3. Make sure the team has a product manager, a designer and a tech lead.
4. Move that team to small, frequent releases and instrument its product.
5. Review evidence monthly and adjust funding and constraints based on what you see.

Does the Product Operating Model Work? What the Evidence Says

Moving to a product operating model is slow and expensive, so leaders fairly ask whether it pays off. There’s no controlled trial, but there is survey data, practitioner experience and case stories. This guide sums up what several independent voices say and where the evidence is thin.

The McKinsey data

In December 2023, McKinsey published analysis of what it calls the product and platform operating model: cross-functional teams from business, technology, operations and other functions that work autonomously, plus platform teams that provide reusable capabilities. It built an Operating Model Index (OMI) covering five areas (structure, strategy and governance, ways of working, culture and talent, tooling) and 17 dimensions, surveyed senior leaders at more than 400 public companies, and compared maturity with business results.

McKinsey also named five capability areas where top and bottom performers differ most: the interaction model between product, engineering and operations; product management practices; backlog prioritization; funding; and technical debt management. On funding, it recommends tying funding to measurable goals and releasing earmarked money based on each team's progress, which is the idea behind outcome-based funding.

Itamar Gilad: eight functions and the "unthinking robot"

Product coach Itamar Gilad, author of Evidence-Guided, explains the model by splitting a tech-powered company into eight cross-disciplinary functions. Every company has all eight; the difference lies in how they operate.

Gilad’s image is a robot with strong limbs and weak software. Delivery, go-to-market and operations are bloated, while research and discovery, the parts that observe reality and think, are underdeveloped. He also prefers “evolution” to “transformation”, because a hundred-year-old organization can’t teleport into a Spotify or Stripe in a few quarters.

Product Talk: signs it is working

Product Talk’s guide, written by Melissa Suzuno and updated in September 2026, lists milestones to watch for as adoption moves along.

• In annual planning, executives fund outcomes or teams instead of projects.
• Outcomes take precedence over outputs in day-to-day work.
• Teams are trusted to solve customer problems instead of being told to build features.
• Stakeholders give input on solutions but don’t dictate them.
• The outcomes you defined improve over time.

The same guide says transformation usually takes years, not months, that a hybrid of project and product models is fine while you get started, and that the project model still makes sense for one-off work like compliance changes.

What to conclude

Independent sources point the same way: outcomes over output, empowered cross-functional teams, discovery before commitment, funding tied to progress. None proves causation, and each has an interest, whether a book, a course or a consulting practice. A sensible response is to treat the model as a well-supported hypothesis, run a pilot, and measure the results yourself with evidence-based measures.

Piloting the Product Operating Model: Choosing Teams and Scaling

Product Talk’s guide, written by Melissa Suzuno with input from Teresa Torres and Hope Gurion, and Wolpers’ work on avoiding product washing both recommend the same starting point: a small number of pilot teams that really are set up to succeed. This guide combines their advice.

Are you ready?

Torres and Gurion name two conditions for the CEO: believing the current way of working won’t lead to future success, and feeling real pain from the status quo, like lost market share or missed financial results. Without both, the transformation tends to get dropped when it gets hard. SVPG adds some common triggers: competitive threat, visible rewards at other companies, and frustration that technology spending hasn’t produced results.

How many pilot teams?

Five factors for choosing pilots

Setting pilots up for success

• Business context: the team is driven by an outcome and understands how it contributes.
• Regular customer conversations to find the most important problems to solve.
• Ability to evaluate whether a solution is right with quick assumption tests.
• Faster delivery cycles, with both qualitative and quantitative discovery skills.
• Cross-functional collaboration, including showing work and externalizing thinking.

What leaders must do

• Be aligned with the outcome the pilot team works toward, and involve other stakeholders in defining it.
• Learn what outcome-focused management means, with coaching if needed.
• Encourage teams to be transparent and collaborative in decisions, sharing thinking rather than just status.
• Hold regular rituals, such as the discovery delivery demo, where teams show what they have learned, what they will learn next and what is slowing them.
• Avoid presenting personal preferences as instructions, and say clearly when something is only a suggestion.
• Say when you want updates, for example when the target customer is defined or when solution ideas appear.

Expect resistance

Scaling beyond the pilot

Use pilots to learn which skills teams and leaders need, who’s on board, how funding and planning have to change, and where access to customers is blocked. Separate the problems specific to one team from the ones that keep showing up across pilots, and fix the recurring ones before you roll out further. Product Talk also says a hybrid is fine: project work like one-off compliance changes can carry on while product teams run on the new model.

LEADER SUPPORT AGREEMENT
Leader and pilot team:
Outcome the team works toward, and why it matters:
I agree to
  Accept adequate solutions even if I would have chosen another.
  Say clearly when I am offering a suggestion, not an instruction.
  Share strategic context in writing so the team can decide without me.
  Attend discovery demos and ask about learning, not just status.
Check-in points I want (e.g. target customer defined, opportunities sized, solution ideas):
What I will stop doing:
Review date:

Product Washing: Signs of a Hollow Product Operating Model

As the product operating model got popular, a backlash was bound to follow. Stefan Wolpers, an agile trainer and writer, coined the phrase “product washing” in November 2024 for hollow adoption: companies announce a product-led approach but change the vocabulary, not how decisions, budgets and incentives work. Wolpers argues this is worse than not adopting the model at all, because it breeds cynicism among teams.

Why it happens

Four anti-patterns

What a genuine transition requires

1. Leadership alignment: CEO, CPO, CTO and others visibly back outcome-driven work, including giving up some control over budgets, priorities and initiatives.
2. Competency, not dependency: build internal skills in customer-centric thinking, data literacy and business acumen rather than leaning on outside consultants for every decision.
3. Outcome metrics with matching incentives: move from feature counts and project completion to retention, satisfaction, usage and revenue impact, and change bonus structures to match.
4. Start small and scale intentionally: begin with pilot teams that are genuinely empowered and accountable.
5. A culture of learning: build feedback loops and make it safe to challenge assumptions and fail.

Product Talk reaches a similar diagnosis. One clear sign of failure is focusing only on product managers or teams while ignoring the funding model, stakeholder involvement and how leaders manage teams, which should be by outcomes, not outputs.

Related guides in this hub

• AI Driven Product Operating Model
• POM vs APOM compared
• Outcome-based funding and allocation
• POM in the AI era

Sources

SVPG, "The Product Operating Model: An Introduction"; Cagan et al., Transformed (2024). Also: McKinsey, "The bottom-line benefit of the product operating model" (December 19, 2023); Itamar Gilad, "The Product Operating Model Explained" (June 2, 2025); Product Talk, "The Product Operating Model Explained: From Pilot Teams to Full Transformation" (updated September 29, 2026). Statistics are reported by McKinsey and not independently verified. Product Talk, "The Product Operating Model Explained: From Pilot Teams to Full Transformation" (updated September 29, 2026); Stefan Wolpers, "Product Washing" (November 14, 2024); SVPG, "The Product Operating Model: An Introduction". Stefan Wolpers, "Product Washing" (Hands-on Agile, November 14, 2024); Product Talk, "The Product Operating Model Explained" (updated September 29, 2026). The detector checklist is editorial.

Further reading: Stefan Wolpers, "From Agile to the Product Operating Model" (survey results, 48 practitioners, August 2026).