The most consistent failure in moving from feature factory to empowered product teams is treating it as a practice gap rather than a structural one. Organisations run workshops on outcome based roadmapping, rewrite backlogs in OKR language, and adopt formats that describe bets rather than features. The vocabulary changes, but the behaviour doesn't. A product operating model does not respond to language, it was designed before the new vocabulary arrived, and it will reproduce itself long after. Understanding that failure requires understanding what an operating model governs and why structural conditions outlast every practice change.
What a product operating model governs
A product operating model is the structural system that determines how a product organisation makes decisions, runs discovery, prioritises work, and is held accountable. Six conditions constitute it, and the quality of the model depends on all six working together, not on any of them in isolation.
Why decision authority is the most predictive operating model variable
Decision authority (who holds the actual right to decide what gets built, what gets cut, and what gets deprioritised) is the single most reliable predictor of whether a product team behaves as a strategic unit or a request queue. In many organisations, the PM holds this authority on paper while a combination of the CEO, the head of sales, and whoever has the most urgency in a given week holds it in practice. That gap between declared and actual authority explains more about team behaviour than any process change can correct.
Discovery practices work the same way. The question is not whether teams run customer interviews or prototype testing, but whether the outputs are capable of changing a decision that leadership has already formed. Discovery that cannot change a decision is not discovery in any meaningful sense; it is a documentation exercise.
How prioritisation logic and measurement reveal the real operating model
The remaining conditions (prioritisation logic, roadmapping approach, team structure, and measurement) either reinforce the real authority structure or contradict it. A team told it owns outcomes but evaluated on delivery pace will optimise for delivery pace, because measurement defines what the organisation rewards in practice. Change the roadmap format without changing decision authority and the new format will be adopted in language and ignored in practice. Change measurement without changing discovery practices and teams will find ways to move metrics without understanding what is actually changing for customers. These conditions operate as a system. Changing one dimension without the others produces adaptation, not genuine change.
Why the feature factory is the structural default
Marty Cagan's term "feature factory" describes a product organisation reduced to an execution function: receiving requirements, translating them into specifications, and shipping on schedule, measured on what was built rather than on what changed as a result. Most discussions treat this as a failure of intention or culture. It is neither.
The feature factory is the natural outcome of how most organisations grow. Executives who once made product decisions directly hire PMs to handle volume as headcount scales, but authority stays with those who held it before, because delegating execution is far less threatening than delegating strategic decisions. Engineers need to stay productive, which means the backlog needs to stay full. Stakeholders learn that the fastest way to get their needs met is to specify what they want built rather than describe the problem they are trying to solve, because specification produces faster results than discovery. Fast delivery is rewarded. Disciplined discovery that might slow things down or challenge a plan already in motion is not.
In European companies, this pattern is structurally embedded in ways that US-centric product management literature rarely accounts for. Research from Atomico's State of European Tech shows that European companies hire their first product manager significantly later in their growth trajectory than US counterparts — often when engineering culture is established, authority patterns are fixed, and the PM role gets defined by the organisation it enters rather than the function it was designed to perform. The Vlerick Business School and Deloitte Rising Star Monitor 2025 gives that structural pattern a number: Belgian scaleups score 69 to 73 per cent on product excellence metrics but only 43 per cent on governance. The product practices exist in places. The governance structures that would make them sustainable largely do not.
The feature factory persists not because the people inside it are failing, but because the conditions sustain it and the incentives reward it.
The models most organisations operate on
Marty Cagan's Transformed (2024) provides the clearest taxonomy of how organisations operate in practice, distinct from how they describe themselves.
From IT model to feature team: the progression that does not solve the problem
The IT model treats product development as a cost centre responding to business requirements. PMs function as project managers; success is measured by delivery on time and within budget. The project model adds governance: investment boards, quarterly planning cycles, without changing the underlying relationship: the business decides, product executes. Most European scaleups have moved past both and now operate at the feature team level: organised around product areas, with genuine latitude over how they build, but not over what they build or why.
The feature team model can produce impressive output velocity. The problem is that the output is consistently aimed at the wrong things, because the teams with the closest customer knowledge do not hold the authority to act on what they learn. A product team with strong discovery capability inside a feature team model will surface customer insights, write them up, present them in reviews, and watch them be set aside for a sales commitment or an executive priority. The insight is real. The operating model is not designed to receive it.
What the empowered product team model requires that the others do not
The empowered product team model is qualitatively different. Teams are given a problem to solve or an outcome to achieve and trusted to determine how to get there. Discovery and delivery are integrated rather than sequential. The product trio (product management, design, and engineering working together during discovery rather than in handoff sequences) means design contributes to problem framing before any solution is fixed, and engineering's knowledge of technical constraints is available while choices are still open.
The defining characteristic is that decision authority sits with the team, within a strategic context set by leadership. Leadership retains which markets to serve and which bets to make; product teams retain which specific problems to solve and whether the assumptions underlying the strategy are holding up against actual customer behaviour. Each party holds the decisions that match where the relevant knowledge sits.
Why operating models absorb vocabulary and reproduce old behaviour
The most important thing to understand about operating model change is that the operating model is very good at surviving it.
When an organisation adopts outcomes language, OKR frameworks, and roadmap formats that describe bets rather than features, the operating model does not disappear. It adapts. Teams learn to write stakeholder feature requests in outcomes vocabulary. Roadmaps are rewritten to describe problems rather than features, then adjusted in the weekly executive review where the real roadmap decisions happen. The language of empowerment is adopted without any transfer of the authority that would make it real. Within six to twelve months, an organisation that ran a significant transformation programme is operating essentially as it did before — in different words.
The tell is always the authority structure. If the answer to "who decides what goes on the roadmap when a PM disagrees with a senior stakeholder?" involves escalation, a meeting with the CEO, or the senior stakeholder overriding the decision, the operating model is a feature team model regardless of what language surrounds it.
What transformation requires
Operating model change is not primarily a process change. It requires changing who holds authority, building the capability to use that authority well, redesigning what teams are measured on, and increasing the patience threshold of the leadership team, all at the same time. That is why most programmes produce vocabulary change and little else.
The four conditions that must hold simultaneously
Leadership must be genuinely willing to change which decisions they make directly. This is the hardest condition to meet, and the one most frequently assumed to be already present when it is not. A leadership team that believes it has delegated product authority but reviews and adjusts the roadmap every week has not yet met it.
The PM team must have the capability to handle greater decision authority: structured discovery, product decisions based on customer and business evidence, and stakeholder management that does not collapse into request management under pressure. That capability requires development time, and the development must precede the expectation that authority transfer will hold.
Team structure must create the conditions for good decisions: product trio composition, cadences that integrate discovery and delivery, and a clear connection between the strategy leadership sets and the outcomes individual teams work toward. These are structural requirements, not stylistic preferences.
Leadership must be patient with the development timeline. Organisations that expect delivery velocity to increase within six months of beginning an operating model change consistently pull back before structural changes have had time to produce anything different. The early phase of genuine operating model change often produces more slowdown than speed, because teams are learning to use authority they did not previously have. Treating that slowdown as evidence that the change is not working tends to restore the feature team model.
Why starting small with protected teams is the credibility move most programmes skip
An organisation at the feature team level cannot move to fully empowered teams in one change effort: programmes that attempt it tend to collapse under the weight of the existing operating logic. Starting with a small number of teams operating with genuine discovery and decision authority, protected from the standard escalation patterns and authority overrides while the rest of the organisation continues as before, generates credible internal proof of the model before it is extended. That proof is worth more to the broader change effort than any amount of external case studies about what good looks like.
dualoop's Shape engagement works at this level: operating model design covering decision authority, team composition, accountability design, and the governance changes that make genuinely different ways of working possible. It addresses structural conditions rather than surface practices.
How to assess where your organisation currently sits
Honest operating model assessment focuses on authority and accountability, because these are the dimensions organisations most consistently misrepresent to themselves because they are the hardest to observe clearly from inside.
The most reliable assessment questions are about the edges. Who decides what goes on the roadmap when a PM disagrees with a senior stakeholder, and what happens in practice when that disagreement arises? What is the PM team evaluated on, and does that match what it is told it owns? What happens when discovery findings conflict with a plan already in motion? The gap between the stated answers and what actually happens in the week before and after those situations reveals the operating model more reliably than any maturity survey.
dualoop's Snapshot is a three to six week structured diagnostic that maps where decision authority sits in practice, what the PM team is held accountable for, and what the specific structural gaps are between the current operating model and what the business needs from it. It produces a maturity picture and a prioritised set of recommendations grounded in actual operating conditions, not stated values. Internal assessments consistently overestimate discovery and measurement maturity; an external diagnostic can observe the gap between what teams describe in a structured session and what happens in the days around it.
Frequently asked questions
What is a product operating model?
A product operating model is the structural system that determines how a product organisation makes decisions, runs discovery, prioritises work, and is held accountable. It governs who holds decision authority over the roadmap in practice, whether discovery is treated as a genuine input to investment decisions, and how business strategy connects to the decisions teams make each day. It is the underlying condition that determines whether good product practices produce good outcomes or are absorbed and neutralised by the structure around them.
What is the difference between a product operating model and a product strategy?
A product strategy defines what outcomes you are trying to achieve and for which customers. A product operating model defines how your organisation is structured to make decisions, run discovery, and deliver against that strategy. You can have a clearly articulated strategy and a broken operating model, which is why many organisations with coherent product visions consistently fail to realise them. Strategy governs direction; the operating model governs whether the organisation can execute in that direction.
What is the feature factory and why do organisations end up in one?
The feature factory, a term from Marty Cagan, describes a product organisation reduced to an execution function: receiving requirements, translating them into specifications, and shipping on schedule, measured on what it builds rather than on what changes as a result. Organisations end up here not through bad intentions but through a rational growth process in which decision authority stays with executives as headcount scales, engineers need to stay productive, and the incentive structure rewards fast delivery over disciplined discovery. The feature factory is a structural outcome, not a cultural failure.
How long does it take to change a product operating model?
Meaningful operating model change in a company of 50 to 500 people typically takes 12 to 24 months to become durable. The first phase (diagnosis and designing the target state) usually takes three to six months. Piloting new ways of working with a small number of teams takes a further six to twelve months. Leadership behaviour change takes the longest to consolidate because it requires changing not just what leaders do but what they are rewarded for doing.
What does dualoop's Snapshot involve for operating model assessment?
The Snapshot is a three to six week structured diagnostic that maps how your organisation makes product decisions, what the PM team is accountable for in practice, and what specific structural gaps are preventing better product outcomes. It produces a maturity picture and a prioritised set of recommendations grounded in the actual operating conditions of the organisation rather than its stated values. Contact dualoop to discuss whether a Snapshot is the right starting point for your organisation.
Sources: Atomico State of European Tech · Vlerick Business School & Deloitte Rising Star Monitor 2025 · Marty Cagan, Transformed (2024)
