What Most Product Operating Models Get Wrong
(And What Actually Works)
A practitioner’s view on aligning UX, product, AI, and leadership in complex organizations.
Most large enterprises do not lack operating models.
They lack operating behavior.
Over the past decade I have participated in several transformations where the structure was redesigned with care. Value streams defined. Product trios introduced. Governance simplified. Decision forums clarified.
On paper the system looked healthy.
And yet โ six to nine months later โ the organization was still escalating decisions upward. Teams still protected pet initiatives. Roadmaps were still treated as commitments rather than hypotheses.
The diagram had changed.
The reflexes had not.
That gap between structure and behavior is where most product operating models quietly fail.
The Illusion of Structural Progress
Operating model redesigns usually begin with good intent.
A leadership offsite. Benchmarking against admired companies. A renewed ambition to “become product-led.”
From there the work tends to focus on containers: reporting lines, roles and responsibilities, portfolio boards, funding mechanisms, governance rituals.
These elements matter. They create clarity. They reduce friction.
But they are secondary.
The primary question is behavioral:
When uncertainty appears, who decides โ and on what evidence?
If that pattern does not change, the operating model becomes cosmetic. And it is worth understanding why โ because the answer is not that leadership is resistant to change. It is that the incentive architecture around decisions has not changed alongside the structure.
When accountability is still measured in delivery milestones and committed roadmaps, the rational response to uncertainty is to push decisions upward. Not because leaders distrust teams, but because the system still rewards certainty over honesty. That tension is structural. Naming it directly is the first step toward resolving it.
I have seen organizations introduce product trios โ product management, design, and engineering โ while still requiring major decisions to be validated in steering committees built for output certainty. The trio exists in theory. Authority remains elsewhere.
What emerges is a hybrid model with hidden gravity. The language of product is adopted, but the decision system still reflects traditional delivery governance.
Behavior follows gravity, not diagrams.
The Hidden Power of Decision Altitude
One of the most underestimated levers in a healthy product system is decision altitude โ where in the organization interpretive judgment actually lives.
The challenge for senior leaders is a genuine one. Visibility into teams working on ambiguous problems is limited. When something goes wrong, accountability flows upward. So it is entirely rational to want decisions reviewed at a level where risks can be weighed.
But this creates a structural trap.
When decisions rise toward certainty too quickly, teams learn โ quickly and accurately โ what the system actually rewards. They optimize for presentation over learning. They treat roadmaps as instruments of political alignment. Discovery becomes pre-work rather than ongoing capability.
The goal is not to remove leadership judgment from consequential decisions. It is to change when that judgment enters. A functioning product operating model keeps interpretation of evidence close to the problem space. Leadership sets direction and guardrails. Teams work within them, escalating only when the guardrails are genuinely in tension โ not as a default.
That shift asks something real of senior leaders: to stay engaged while resisting the pull to resolve ambiguity early. It is not a passive role. But the return โ teams that are genuinely curious, honest about uncertainty, and capable of learning โ is worth the discomfort.
UX Must Sit Inside Capital Allocation
One of the clearest signals of product maturity is where UX enters the financial conversation.
If research findings are presented after budgets are locked, they are decorative.
If discovery influences where capital flows, it becomes structural.
The tension here is familiar to any senior leader who has sat in a planning cycle. Annual budgets require commitments. Commitments require forecasts. Forecasts require assumptions that discovery, by definition, hasn’t yet resolved. The system seems to demand certainty before learning is complete โ so learning gets compressed or skipped.
The way through is not to abandon financial discipline, but to stage it differently.
In one enterprise setting we moved away from annual commitment toward staged funding tied to learning milestones โ not full venture logic, but directionally similar. Instead of approving a twelve-month roadmap, leadership approved a twelve-week learning mandate with explicit hypotheses.
Teams had to demonstrate one of three things to unlock continued funding:
- Evidence that the problem was real
- Evidence that the proposed approach had traction
- Evidence that the initiative should stop
The effect was immediate. Teams prioritized clarity over velocity. Executives asked better questions. Design research suddenly mattered โ not because more designers were hired, but because discovery had moved into the economic core of the operating model.
The ask of leadership in this model is to get comfortable treating “we stopped this initiative based on evidence” as a success, not a failure. That reframing is harder than it sounds. But it is what separates organizations that learn from organizations that only deliver.
AI Is Now a Stress Test for Product Systems
The recent wave of AI tooling is exposing weaknesses in product organizations at remarkable speed.
Teams can now generate prototypes, UI flows, content, and analysis almost instantly. Tools like Claude Code, ChatGPT, and rapid front-end generators make it possible for a single product team to produce what once required an entire design and engineering cycle.
But acceleration without insight is expensive.
AI does not automatically improve decision quality. It amplifies whatever behavior already exists inside the system.
If the organization prioritizes output, AI will produce more output. If it prioritizes learning, AI will accelerate learning.
This distinction is the most important thing senior leaders need to understand about AI adoption right now โ and it is largely invisible in most vendor conversations, which focus on productivity gains rather than on the decision quality that determines whether those gains create value.
A mature product system treats AI as a capability multiplier for discovery: faster experimentation, faster validation, faster iteration. An immature system uses it as a production engine. One leads to insight. The other leads to faster waste.
The strategic question is not “how much can we produce with AI?” It is “how much can we learn?”
Capability Emerges Through Practice
Another pattern I see repeatedly is the belief that transformation happens through methodology adoption.
New frameworks arrive. Training programs roll out. Playbooks appear. Scrum ceremonies are installed. Design thinking workshops are scheduled. Agile coaches move through the organization.
But capability does not emerge from training. It emerges from practice on real problems โ and this is worth taking seriously as a resourcing decision, not just a philosophical point.
The question is not whether people understand the methodology. It is whether the system gives them the conditions to practice it:
- Clear decision rights within a defined scope
- Protected discovery time, not squeezed alongside delivery
- Genuine access to users and evidence
- Staged funding tied to learning rather than output
When those conditions exist โ even in a single pilot team, even for a defined period โ something different begins to happen. People experience what good product work actually feels like. Belief spreads not through persuasion, but through competence.
One properly structured value stream pilot creates more behavioral change than two years of enterprise-wide transformation programs. The implication for senior leaders is that selective depth creates more leverage than broad rollout. Fewer teams, better conditions, real evidence.
A Case Study in PAK: Five Hundred Epics and No Way Forward
Let me make this concrete.
A few years ago I gave a talk in Aarhus on systematic design thinking โ specifically on a sprint structure I had developed called the Five Mindset Sprint. The audience included, as I discovered afterward, a small scouting group from one of Denmark’s largest toy manufacturers. They had been sent specifically to assess whether what I was describing could solve a problem their organization had quietly recognized as serious.
The problem was this.
They were running SAFe โ Scaled Agile Framework for Enterprises โ and their epic generation process had gone completely off the rails. Five hundred epics sat in a backlog with no meaningful prioritization, no shared understanding of what most of them actually meant, and no credible path to delivery. They had production capacity. They had engineering muscle. What they lacked was product discovery โ the upstream thinking that turns a pile of ideas into a coherent, sequenced, evidence-backed direction.
They had, in other words, the full apparatus of an operating model. What was missing was the behavior that makes an operating model work.
We agreed to run a series of Five Mindset Sprints. Each sprint followed the same weekly arc, deliberately structured to build capability through doing rather than teaching:
Monday โ Empathy. Not a workshop about empathy. Actual contact with the problem space: stakeholders, users, the people closest to the pain. The goal was to arrive at Tuesday with real questions, not inherited assumptions.
Tuesday โ Ideation. Systematic generation of responses to the questions Monday had surfaced. The discipline here was to separate generating from evaluating โ to resist the organizational gravity toward premature convergence.
Wednesday โ Filtering and Recombination. The ideas from Tuesday were not just ranked. They were combined, stress-tested against constraints, and shaped into solution frameworks. This was the day that typically surprised people โ because good solutions rarely looked like any single idea from Tuesday. They were composites.
Thursday โ Rapid Prototyping. Not full builds. Enough fidelity to make the solution tangible. Enough to be wrong in specific, useful ways.
Friday โ Storytelling. The hardest day, and the most important. The sprint team had to construct a coherent narrative that could travel through the organization โ one that earned alignment not through authority but through clarity of argument.
What emerged from those Fridays consistently surprised participants. The solutions were rarely purely digital. They were almost always a combination: an organizational adjustment here, a governance change there, a tooling remake as the third ingredient. The epic problem, for instance, turned out not to be a backlog management problem at its root. It was a prioritization mandate problem โ nobody had clear authority to say no โ wrapped around a shared language problem, where “epic” meant something different to product, to engineering, and to portfolio governance.
You cannot fix that with a better tool.
You fix it by giving someone the authority to decide, creating a shared vocabulary, and then โ and only then โ using tooling to operationalize the clarity you have created.
This is the PAK inversion.
Most organizations approach capability building through KAP: Knowledge first, then Application, then Practice โ if Practice ever arrives at all. Frameworks are introduced. Theory is taught. Case studies are studied. And then, months later, there is a hope that people will apply what they have learned to real situations.
The sequence sounds logical. In practice it fails reliably. Knowledge without context does not transfer. Application without stakes does not build confidence. And Practice โ the actual place where capability lives โ gets scheduled last, and often cancelled first.
PAK reverses the order.
Practice comes first. You work on a real problem, with real constraints, and real consequences. The framework is not introduced in a classroom โ it is experienced in the room.
Application follows. As the work unfolds, you begin to see where the methodology is operating beneath the surface. Patterns emerge. Language becomes useful because it names something you have already felt.
Knowledge consolidates last. Not as theory but as recognition โ the moment when someone says “that’s what you meant” and means it, because they have lived the thing the concept describes.
In that Aarhus-initiated engagement, we were not teaching design thinking. We were doing it, on a real problem, with real stakes, inside the actual operating constraints of the organization. The capability that emerged was not retained from a slide deck. It was built from practice.
The five hundred epics did not disappear overnight. But the organization developed something more durable than a prioritized backlog. It developed a shared method for deciding โ a repeatable behavior that did not require external facilitation to sustain.
That is what practice builds.
That is what training rarely does.
Operating Models Are Living Systems
Operating models rarely fail because they are poorly designed.
They fail because they are not lived.
A functioning product system is less like an organizational chart and more like a set of habits โ habits around evidence, decision-making, learning, and accountability. Structures can support those habits. But they cannot replace them.
The real transformation begins when senior leaders shift attention away from designing the container and toward cultivating the behaviors inside it. That means being visible in discovery conversations, not just in delivery reviews. It means asking “what did we learn?” before asking “what did we ship?” It means being willing to sit with uncertainty long enough for genuine learning to occur.
That is slower work. More subtle work. It asks more of leadership, not less.
But it is the difference between adopting a product operating model โ and actually becoming a product organization.uct operating model โ and actually becoming a product organization.
Leave a Reply