From Agile to the Product Operating Model: What Practitioners Say Is Actually Changing

TL; DR: The “Agile to the Product Operating Model” Survey Results

Between August 2 and August 10, 2026, 48 practitioners participated in my Agile to Product Operating Model (POM) survey, which tries to shed light on what is actually changing.

Let me summarize the answers for you: the reported transformations change decision-making less than the Cagan framework suggests. Where respondents report improvements, they appear in delivery and collaboration rather than in business results. Unfortunately, the human side of the transition is the least encouraging part of the answers.

Take all the following information with a grain of salt, given that the sample size is so small. (I recall the good times when 1,000 to 2,000 people would participate in a Scrum master salary report, but those times seem to be over, despite my asking 39,000 people for their contributions via a newsletter.)

Thesis: Product operating model transformations mostly change vocabulary and organizational structure while leaving the decision system, who decides what gets built, on what evidence, at what speed, largely untouched. AI is changing product decisions independently of POM transformations.

---

🎓 🇬🇧 The A3 Delegation System Founding Workshop — September 28-29, 2026

Your team already delegates work to AI: reports, research, customer feedback analysis, stakeholder communication, or parts of operational workflows.

But can you answer these questions without improvising?

• What may AI decide, and what must remain a human decision?
• What does “good enough” mean for this particular work?
• Who verifies the result before somebody acts on it?
• Who checks whether the delegation still works after the model or workflow changes?

If those answers live in one person’s head, or nowhere, your problem is no longer prompting. You have a delegation problem.

The A3 Delegation System gives you a practical way to decide what AI may do, hand over the work clearly, define acceptable results, and inspect the delegation over time.

During two hands-on sessions, you will apply the system to a workflow. You will leave with a clear understanding of how to apply the A3 Delegation System to your workflows so that team members or stakeholders can understand, challenge, and continue your AI delegation work. Everything you learn is directly applicable to your situation the next day. The class is in English.

👉 Join the Workshop Now — $199: The A3 Delegation System Founding Workshop — September 28-29, 2026

---

🇩🇪 Zur deutschsprachigen Version des Artikels: Die Ergebnisse der „Agile zum Product Operating Model“ Umfrage: Was sich wirklich ändert.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.

🎓 Join Stefan in one of his upcoming training classes!

---

Who Answered, and Why I Report Counts, Not Percentages

Of the 48 respondents of the Agile to Product Operating Model, 26 work in organizations that have adopted a product operating model or are moving toward it (we refer to them as the “movers” from here on). The other 22 work in organizations that are not moving; these organizations are still discussing the issue, have decided against it, or have never considered it.

So you get absolute counts, and every finding below is directional, not definitive. Additional limitations are:

• 24 of the 48 respondents are Scrum Masters or Agile Coaches, the roles under the most pressure from this shift.
• 38 of 48 work in organizations with more than 250 people; the sample contains 2 respondents from startups and 2 from scale-ups.

Apparently, the people who have participated in the survey are those who still care enough about agile practice to read a newsletter about it; people who left “Agile” entirely are structurally missing. Also, as I did not ask respondents to identify employers, the 48 participants report on their organizations, not 48 distinct verified organizations.

Putting all together, this is a report from inside large organizations, where the product operating model makes its boldest promises.

One Fundamental Change in 26 Answers

Asked which statement best reflects their experience so far, the 26 movers split like this:

• 9 say mostly relabeling, the same way of working with new vocabulary
• 9 say real change in some areas, relabeling in others
• 7 say it is too early to tell.

Exactly one participant reports a fundamental change in how the organization decides what to build, which is the most interesting learning from the responses: changing the vocabulary, changing the organizational structure, and changing how decisions actually get made are three different things.

Cannot see the form? Please click here.

Better Delivery, Inconclusive Business Results, Worse Morale

The Agile to Product Operating Model survey asked movers to compare six outcomes against their previous way of working. Aggregating “somewhat” and “clearly” in each direction:

Outcome	Better	No change	Worse	Too early / cannot tell
Speed of delivery	9	10	1	6
Value delivered to customers	8	8	2	8
Business results	3	8	4	11
Team motivation and morale	7	4	9	6
Developers’ satisfaction	4	8	7	7
Collaboration with stakeholders	9	6	4	7

The table does not say that the transitions are failing:

• Delivery speed leans positive: 9 better against 1 worse.
• Customer value leans positive: 8 against 2.
• Collaboration with stakeholders leans positive: 9 against 4.
• Business results are inconclusive, with 11 of 26 unable to say and the rest split.

The people dimensions are the only ones that lean consistently negative: morale at 9 orgs is worse than at 7, where it improved; developers’ satisfaction is similar: worse at 7 orgs and better at 4 orgs.

Two ways to interpret this information, and the survey does not help to choose:

(1) The improvements concentrate on the things enterprises already know how to optimize (flow, coordination, delivery), while the transformations may be falling short of the things the model claims to change most fundamentally.

(2) Operational effects precede commercial effects, because business outcomes have longer feedback cycles, and 11 of 26 respondents explicitly cannot yet say.

Consider that flow, coordination, or delivery are easier to measure and attribute than commercial effects, which is a significantly fuzzier area. Therefore, the interesting question is how this changes over time, not how it looks at one moment.

The range of individual experience behind those aggregates is wide. One respondent, 12 months into adoption at a large financial-services organization, described the hardest part as “surviving the political game that the POM shift has been” and reports worse answers on five of the six dimensions. The other two respondents who have been at 12 or more months report the opposite: better value, better morale, and better collaboration. Three long-tenured accounts cannot agree on whether the practical transition mechanics, culture, affected products and services, or the organization itself makes the difference. (That is the curse of a small sample size.)

Agile to Product Operating Model: The Empowerment Gap, and What Settles Uncertainty

Cagan’s own test separates empowered product teams from feature teams: in a product team, the team is tasked with solving a problem and owns the solution. In a feature team, “the value and business viability are the responsibility of the stakeholder or executive that requested the feature”. The survey asked movers which pattern operates today, in the middle of their transitions:

• 9 of 26 report the empowered pattern (leadership sets goals and problems to solve, teams decide what to build)
• 8 of 26 report that leadership decides which features get built and teams implement them.
• 4 of 26 report stakeholder requests are filling the product backlog reactively.
• 4 of 26 say it is genuinely unclear or contested right now
• A single one reports teams setting their own direction.

So even among respondents whose organizations are actively adopting a model whose entire premise is empowered teams, the “feature-list or reactive-backlog” pattern (12) outnumber the “empowered” pattern (9).

A related question asked what settles it when the organization is uncertain whether something is worth building:

• 6 said debate and prioritization before anything gets built
• 5 said whoever has the most authority decides
• 5 said things just get built and shipped, and an explicit decision rarely follows. 4 said research evidence
• 5 said it varies too much to say.

In total, only five respondents fall into the categories I pre-registered as evidence-led: research evidence, disposable prototypes, or ship-and-measure.

There is one case among all the answers: a respondent reports that a disposable AI-assisted prototype reduces build uncertainty: build to learn, decide, and throw it away. That same respondent, 12 months into adoption, also reports better responses across all six outcome dimensions listed above.

Of course, one case is not evidence of a relationship. It is a question worth asking in a larger sample, not a claim I am entitled to make here. In Little Code, Big Waste, I argued that cheap AI code removes the cost gate that used to force a should-we-build-this decision, and that “when generating plausible code becomes cheap, every hour spent building the wrong thing becomes waste that can now be produced at scale”. This survey says the prototype-to-decide pattern barely exists yet in this sample.

Agile to Product Operating Model Survey Shows: The Two Transitions Run Separately

If you believe the keynote version of events, AI is forcing organizations to redesign their operating model around it. The 26 movers report something different. Only one respondent says AI is a core reason for the change; 6 of 26 call it one factor among several; 16 say AI adoption runs in parallel, but separately from, the operating model change; and 3 report little or no role.

Now the other side. Among the 22 respondents in non-moving organizations, 15 report that AI is changing how product decisions are made anyway: 6 noticeably, 9 in pockets, without any formal model change.

Despite the small sample size, the data support a narrow claim: for most movers in this sample, AI and operating-model transformation are separate initiatives, while for most respondents in non-moving organizations, AI is changing product decisions without any model change at all. Formal operating-model change is neither a prerequisite for AI-driven changes to product decision-making nor, so far, organized around them. The survey did not measure how AI enters these organizations or who authorizes it, so I will not claim more than that. The disconnect between the two is already the finding.

My Pre-Survey Hypothesis Scoreboard

Here are my verdicts on my four hypotheses, H1-H4, that led to the creation of the Agile to Product Operating Model survey:

H1, consultant-driven transitions produce more relabeling than leadership-driven ones: Relatively consistent, but no verdict: 3 of the 4 respondents whose transition is driven by consultants or a transformation office report “mostly relabeling,” against 4 of 16 in product-led or executive-led transitions. But those are just four participants.

H2, the empowerment gap: The feature-list plus reactive-backlog patterns (12) outnumber the empowered pattern (9). That is observed in this sample, however, not established beyond it.

H3, where AI drives the move, product judgment is the scarcest capability: incorrect on my side: Among the 7 respondents whose organizations treat AI as a core reason or a factor in the move, the most frequent scarcity answer is “delivery capacity is still the bottleneck” (3), ahead of product judgment (2). Across all 26 movers, the scarcity question splits three ways: “stakeholder alignment and decision speed” (7), delivery capacity (6), and product judgment (6).

One distinction keeps H3’s rejection from closing the question. The survey measures perceived constraints, and perception rarely reflects reality accurately. AI may have changed the economics of implementation faster than organizations have updated their sense of where the workflow bottleneck sits. Whether delivery capacity objectively remains the constraint is a different question, and this survey cannot answer it. What it can say: practitioners today experience decision speed, delivery, and judgment as roughly competing constraints, and the judgment-scarcity era I anticipated is not the world they report living in.

H4, organizations that build without explicit decisions report worse customer value than evidence-led ones: rejected as stated: 1 of 5 build-without-deciding respondents reports better customer value, against 2 of 5 evidence-led ones. Again, the number of replies is too small.

Changing the Structure Without Changing the Decision System

Three of the findings above belong side by side. Only 1 of 26 movers reports a fundamental change in how build decisions are made. Only 9 of 26 report the empowered decision pattern operating today. Only 5 of 26 fall into the evidence-led categories for resolving build uncertainty.

Together, they suggest a more precise diagnosis than “the transformation is theater.” Transformations change three different layers, and the layers move at different speeds:

1. Vocabulary changes first: Product operating model, empowered teams, outcomes over outputs; you get the idea.
2. Structure changes second, and often really does change roles, reporting lines, team topologies, or artifacts.
3. The decision system changes last, if at all: Who decides, based on what evidence, under what uncertainty, with what authority, at what speed.

This survey reads like a snapshot of organizations renaming the first layer, reorganizing the second, and leaving the third largely untouched.

That is why the 1-of-26 count deserves the weight I put on it earlier. One of the product operating model’s defining promises is a different way of deciding what to build. If only one of the 26 respondents experiences a fundamental change in that mechanism, the question is no longer whether the transformation is proceeding fast enough, but what is being transformed.

That mental model offers one possible explanation for the outcome table: structural change could improve coordination and flow before it alters the quality of product decisions. Whether that explains the pattern here is impossible to establish from 26 responses. A long-term study of organizations and involved practitioners would need to test whether decision-system change predicts eventual business outcomes. (Consider that a hypothesis this survey generated, not a result it delivered.)

Agile to Product Operating Model: Why Product Washing Is Easier Than Empowerment

The survey cannot tell us why the decision system resists change. What follows is my hypothesis, argued from two decades of watching transformations, not a survey result.

The tempting explanation is that these organizations are implementing the product operating model badly, and that a proper implementation would deliver. I spent those two decades watching the Agile community run exactly that defense. Every failed adoption was “not real Scrum.” The argument is unfalsifiable, and it taught an entire industry to blame practitioners instead of examining incentives. I will not run the same defense for the product operating model.

In November 2024 I described Product Washing: the hollow adoption of product practices that “leaves companies stuck in the same old dynamics but with a new vocabulary,” transformation by reprinting business cards. My hypothesis for the mechanism: product washing is not an implementation failure but what enterprise incentives produce when you ask powerful people to redistribute their own power. The model demands that stakeholders with budget authority hand problem-selection to product leadership and solution-selection to teams. Budget authority is power, and in many large organizations, “product leadership” has become a new title for the same stakeholders who control the money. Meanwhile, middle layers face asymmetric career payoffs: a visible failure damages a career far more than a shared success advances it. Under those payoffs, routing decisions through committees and sign-offs is rational self-protection, and it does not vanish because the org chart was redrawn.

Two honest caveats bound this hypothesis:

First, in regulated industries, some of that scrutiny is very relevant: when a named person must answer to a regulator, a sign-off chain is accountability, and the respondents from banking and the public sector live with constraints no product operating model erases. The skill worth having is telling required governance apart from accountability theater; most organizations run both and label neither.

Second, this survey is a cross-section, not a time series, and two competing explanations fit the same data:

• The transition hypothesis: decision authority changes slowest of all the layers, and these organizations are simply not there yet.
• The attractor hypothesis: enterprise incentives pull transformations toward renamed feature factories and hold them there.

My incentive argument predicts the attractor. With only 3 respondents at 12 or more months, this survey cannot distinguish between them. That is a testable question for a future survey.

The Non-Movers’ Catch-22

The 22 respondents in non-moving organizations deserve more attention than transformation literature usually grants them. Their top reasons for staying put:

• Leadership sees no need or has other priorities (15),
• Lacking the product-management maturity to build on (13), and
• The cost and fatigue of yet another transformation (10).

Only 6 claim their current way of working performs well enough.

The dominant non-mover position is not a confident endorsement of the status quo. And inside the reasons sits a genuine Catch-22. Organizations supposedly need the product operating model because their product capabilities are weak, while 13 of 22 respondents say weak product capabilities are precisely why their organization cannot adopt it. A transformation that requires the maturity it promises to create is a hard sell to people who have already survived several that made the same offer.

Conclusion: Three Questions for Monday Morning

Three questions locate your own organization on this map:

First: who decided the last thing your team built, and would your CPO name the same person? If the answers differ, you have found the gap between the model on the slides and the model in operation.

Second: what settled your organization’s last genuinely contested build decision: evidence, debate, or seniority? “Whoever has the most authority decides” got 5 votes out of 26 in this survey. Be honest about whether your organization would add a sixth.

Third: what would have to be true for a disposable prototype to settle the next contested decision instead? That is a political question, not a technical one: who would have to accept evidence as a tiebreaker, and what would it cost them?

Forty-eight answers later, the better question is no longer which operating model organizations adopt. It is how they make decisions when the cost of trying something has collapsed while the cost of deciding has not: Who decides on what evidence, and how quickly can the organization act on what it learns? That is where my work is heading next.

Key Questions this Article on the Agile to Product Operating Model Survey Results Answers

What actually changes when an organization moves from Agile to a product operating model?

Mostly vocabulary and structure, according to a 2026 survey of 48 practitioners. POM transformations change three layers at different speeds: vocabulary first, organizational structure second, and the decision system, who decides what gets built and on what evidence, last, if at all. Only 1 of the 26 respondents in transitioning organizations reported a fundamental change in how their organization decides what to build.

Does the Product Operating Model improve business results?

The evidence is inconclusive. In a small, self-selected 2026 practitioner survey, 11 of 26 respondents in transitioning organizations could not yet judge business results. The rest split 3 better against 4 worse. Delivery speed (9 better, 1 worse) and stakeholder collaboration (9 better, 4 worse) lean positive, while team morale (9 worse, 7 better) leans negative. Operational gains precede any demonstrated commercial payoff.

Is AI driving the shift to the Product Operating Model?

No, not in this sample. Only 1 of 26 respondents in transitioning organizations named AI as a core reason for the change; 16 said AI adoption runs in parallel but separately. Meanwhile, 15 of 22 respondents in non-moving organizations reported AI changing product decisions anyway. Formal operating-model change is neither a prerequisite for AI-driven changes to product decision-making nor commonly organized around them.

How common are truly empowered product teams in these transitions?

They remain a minority. Nine of 26 surveyed practitioners in transitioning organizations reported team empowerment, in which leadership frames problems and product teams decide what to build. Twelve reported feature-list or reactive-backlog patterns, the very models the product operating model claims to replace. When building decisions are contested, 5 of 26 said whoever has the most authority decides.

Why do organizations decide against the Product Operating Model?

It is rare because their current system works: only 6 of 22 surveyed respondents in non-moving organizations claimed it performs well enough. The leading reasons were leadership seeing no need (15), lacking the product management maturity to build on (13), and transformation fatigue (10). That creates a Catch-22: the maturity deficit the model promises to fix is the same deficit that blocks its adoption.

Agile to a Product Operating Model Survey Results — Related Articles

Product Washing: The Pitfalls of a Superficial Product Operating Model Transformation.

Why Leaders Believe the Product Operating Model Will Succeed Where Agile Initiatives Failed.

Marty Cagan on the Product Operating Model and Scrum’s Future.

Product Team Empowerment Anti-Patterns.

👆 Stefan Wolpers: The Scrum Anti-Patterns Guide (Amazon advertisement.)

📅 Training Classes, Workshops, and Events

Learn more about AI Builders with our AI and Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If your organization’s procurement process requires a different purchasing approach, please contact Berlin Product People GmbH directly.

✋ Do Not Miss Out and Learn More about the Agile to Product Operating Model path — Join the 20,000-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you would like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.