Escaping the Product Operating Model Trap
Help for leaders whose product operating model has stalled
Escaping the Product Operating Model Trap, for Digital Leaders
The conversation often begins the same way. A slide appears in a leadership meeting, with a title reading something like “Our Product Operating Model.”
Next there’s often a slide showing a pair of roller skates becoming a skateboard, becoming a bicycle, becoming a motorbike, becoming a car.
Then there’s a diagram showing a sequence for product development, with lots of circular arrows showing feedback loops. The diagram usually looks reassuringly neat and discovery loops and delivery cycles sit in harmonious balance.
The implication is rarely stated outright, but everyone in the room understands it: ‘if we were truly serious about product, we would reorganise the organisation around this model.’ Teams should be organised in tidy structures, product managers should be empowered. We need new roles, new reporting lines, and new ways of working. There’s a promise of simplicity and clarity.
The trouble is, this assumes something unrealistic: that an organisations can wipe the slate clean and rebuild itself around a single philosophy, and establish a new mono-culture with Digital and a product operating model at its heart. And that ain’t gonna happen.
Most organisations cannot wipe the slate clean and start again, or instil a singular culture. And more importantly, they don’t need to. So, as a digital leader, we’re trapped. We’re in front of a huge transformation programme that’s stalled, in an organisation that doesn’t care about the product operating model slide deck.
So – if you’re in a large, complex organisation with many internal cultures – and your product operating model has stalled – here’s how you reintroduce pragmatism and take your next, best step.
The Moment These Ideas Came From
It’s worth remembering that many of the ideas behind the current myth of ‘the product operating model’ emerged in a specific moment. During the 2010s — particularly in fast-growing technology companies — product-led operating models were genuinely powerful. They helped organisations move away from rigid project structures and towards continuous learning and delivery. In those environments, the model made sense: they had a mono-culture where everything was geared around growth. Teams were small and authority was clear. These organisations were built around products from the start.
Over time the model travelled. Leaders in larger, older, more complex organisations saw it and wanted it bring it into their world. As it travelled, it gradually acquired a kind of mythic status. Presented not as one successful pattern among many, but as the universal blueprint for modern organisations. That’s where many organisations started to run into trouble.
Transformation Diagrams and Organisational Reality
One reviewer of my book told me that the famous slide (a pair of roller skates becoming a skateboard, becoming a bicycle, becoming a motorbike, becoming a car) had acquired a nickname in their organisation, people called it “that @*cking skateboard slide.”
It had been presented so many times as the explanation for how agile or product transformation should work that it became a symbol of something bigger: the gap between transformation diagrams and the reality of a big, messy organisation.
The diagram itself can be seen here. It’s by Henrik Kniberg and he said that it’s simply intended as a visual metaphor for incremental product development – and that it’s been so popular due to its simplicity that it’s been taken out of context and misinterpreted.
A myth has emerged from the diagram, which is that it’s about building and delivering quicker faster.
The truth is that it’s about ‘minimum viable product’ – which is about testing assumptions. Everyone is either under-confident or over-confident when making decisions. ‘Minimum viable product’ is a metaphor for ‘testing our assumptions before making a decision’. It’s about running experiments to manage risk.
If people are under-confident you get analysis-paralysis. That means we need we can’t get any more useful data in the abstract. The only way to get more useful data to inform our decision is to do something for real. To run an experiment.
If people are over-confident you build things people don’t need. That means we waste money creating things without real value. Sometimes the only way to slow this momentum is to find the smallest work possible to do something for real that exposes how poor the outcomes of the thing are. To run an experiment.
The idea behind the skateboard slide isn’t wrong, building value incrementally is a good principle. But real organisations rarely change in neat sequences. Managing risk by having experiments at the heart of our culture is the thing we need to take away from this . . . but that’s not such a compelling slide.
Importing Operating Models
A consultant once told me about a large organisation that had hired their agency to “implement the Marty Cagan model.” The brief was clear: install the structures and practices associated with modern product management. But once the team arrived they discovered something predictable: the organisation wasn’t ready for that model.
The Digital directorate had limited authority in the broader organisation. The surrounding organisation still worked through traditional structures. Digital itself was small inside a vast system and as soon as their work crossed organisational boundaries (which was essential), the model collapsed under the weight of the existing environment.
Not because the model itself was wrong. If you read Marty Cagan’s writing (which is well worth doing) it’s different from the myth and industry that has emerged around it. It’s this mythical, over-simplified operating model that’s packaged and sold as a neat solution by many organisations that is the problem, not the original influences on it.
These neat, simple product operating models rarely survive contact with environments that were never designed to support them.
Operating Models Don’t Arrive Fully Formed
In practice, operating models rarely appear all at once. They emerge gradually through practice — through hundreds of small and incremental decisions about how teams work, learn and improve together. Through experiments that work and experiments that don’t. And through teams learning how to make decisions together.
Real operating models are less like buildings designed in advance, and more like landscapes that emerge through cultivation over time. Slides can describe the aspiration. But the real thing only appears once people begin working differently.
All the models, frameworks, books, training, and roles descriptions are useful input but they are not the truth. It’s our pragmatism, expertise, and judgement as leaders that brings this to life in a way that works in our reality. And the pragmatism, expertise, and judgement of the folks in our teams, who are normally up for doing things in a better way in order to do right by our users . . . as long as they are part of the improvements, and as long as they feel more valued than the deck of product operating model slides.
There Is a Product Mindset
None of this means product thinking isn’t valuable. In fact, the opposite is true. Over the past decade, the spread of product thinking has improved how many organisations approach problems.
At its heart, the product mindset is relatively simple.
Aim. Know what matters and stay radically focused on it.
Experiment. Work like a scientist inside a messy organisation.
Be decisive. Decisions are a unit of delivery.
1. Aim. This is about knowing what matters and staying radically focused on it.
We should start with the outcome we want, not the thing we want to build. If we can’t say who this will help, why this is the best way to help them, and how much it will help them – then why are we doing it?
As leaders we can model this and radiate it outwards: being absolutely clear on the outcomes we need, and asking our teams to define the best opportunities to achieve this outcome. And that’s the easy part.
Saying ‘yes’ to an opportunity is relatively easy, it’s saying ‘no’ to all the other ones that’s the hard part. A lot of ‘aiming’ is about protecting focus against everything that tries to dilute it. All of the other opportunities, asks, requirements, and pet projects. It’s not enough to aim, we have to radically focus on that aim.
2. Experiment. This is about thinking like a scientist when working in ambiguity.
A while ago I dug into the backgrounds of the Lead Product Managers I’d recruited and managed over the years. It wasn’t software engineering or design, it was science. Forensic science. Pharmaceutical science. Research science. At the time I thought this was just a quirk and didn’t think anything of it but as the years have gone by this has made more sense. These are people who know how to enter ambiguity, set up small experiments, manage risk step by step.
This is how we tackle the bias towards under-confidence or over-confidence that I mentioned earlier. Once again, we can model this as leaders and radiate it outwards, showing our teams how to use small experiments to set big initiatives up for success and to course-correct them when they hit the reality of our organisations and our users.
3. De decisive. This is about delivering decisions amongst ambiguity and complexity.
In organisations where there’s no clear strategy, decision-making is distributed, goals are ambiguous, and motivations compete with one another . . . negotiating a decision that creates movement in the right direction is a big part of the product mindset.
Understanding users and technology is the price of entry, and is hugely important. And if we want that to lead to something useful, we need to understand our messy organisations, how our we and our colleagues show up and make decisions (which is not rational and logical). We need to understand our organisation’s social systems just as much as we understand our users and technology. An opportunity that looks good on paper, on its own terms, might not thrive in the reality of our organisation. And we need to factor this into the opportunities we decide to pursue.
Being ‘correct’ is not enough. Some skills around negotiation, mediation, conflict resolution, coaching, ‘selling’, and storytelling are essential.
—
I’ve uncovered and developed this mindset over many years. You don’t have to take mine and use it as is, it’s preferable to treat it as an input to creating your own. The important thing to note is that a product mindset is not the same thing as a product operating model.
A mindset travels well, off the shelf operating models rarely do. You need to develop a mindset that works in the reality of your organisation and allows you and your teams to navigate complex situations.
The Many Traditions of Product Management
Part of the confusion with product operating models comes from the fact that product management has never been a single thing. Different organisations developed the role in different ways and several conflicting myths exist about the role.
There’s not one ‘true’ version of product management but I do see four flavours of product management needed in large, complex organisations. Part of the product operating model traps comes when organisations assume there is only one way to do the role, and bake this in as their sole way of working.
Four Flavours of Product Management
In practice, most product managers end up playing some combination of four roles.
1. The Engineering Manager
This flavour sees product/digital teams function primarily as delivering software. It might look and feel a bit like Scrum. It’s about backlog clarity, requirements, and helping engineering teams move work forward. The strength of this role is delivery discipline. The risk is that teams ship efficiently without always being clear about why.
I think it probable that this flavour was influenced by Microsoft in the 1980s–90s. The Program Manager emerged inside the “Dev–Test–PM” triad. Joel Spolsky (an ex-Microsoft PM) described it like this: “Program managers at Microsoft gather requirements, figure out what the code is supposed to do, and write the specs.” (Joel on Software, 2000). The product manager in this context was the person who shaped coherence, turning engineering brilliance into usable product, and writing the map that everyone else builds from.
2. Opportunity and Vison-Led
This flavour focuses on discovering and shaping opportunities. It might look and feel like working on Policy development, shaping a new programme, or exploring use of AI. Their work is centred on research, experimentation and insight. The strength of this role is preventing teams from building the wrong thing. The risk is that discovery becomes disconnected from the organisation’s ability to act on it.
I think it probable that this flavour was influenced by Google in the 2000s. The Associate Product Manager programme, started by Marissa Mayer, recruited bright graduates and groomed them as product visionaries. The Google PM was imagined as obsessed with users, spotting new horizons, shaping products that millions might adopt. Not carrying P&L, but carrying vision.
3. The Value-stream Manager
This flavour sees a team owning an end to end product, service experience, capability or process, possibly including non-digital elements. They are responsible for defining the problem, aligning the team, and delivering outcomes. The strength of this role is ownership. The risk is that organisations adopt the language of ownership without actually granting the authority required to make those decisions.
I think it probable that this flavour was influenced by Amazon,where the “single-threaded leader” model was developed. As Bill Carr and Colin Bryar describe in Working Backwards, single-threaded leaders own a problem end-to-end: drafting the press release before building, aligning teams across functions, carrying customer metrics, and often commercial accountability.
4. The Transformer
This flavour sees one or more digital leader – often including a Lead Product Manager or Head of Product – focused on driving organisational change. It’s possible to that digital transformation has been achieved, and in a post-digital world we are left with organisations full of silos and disconnected work, technologies, and teams. In this space, new work simply adds more complexity. Invention is no longer the mission, it’s integration. The strength of this work is that it gets more from what we already have. The risk is that it’s poorly understood and often undervalued.
This flavour is emergent and something that I’ve named. I’ve worked with and interviewed dozens of product leaders in the last couple of years and seen this flavour emerge as maybe their default mode. Product and digital leaders in large, complex organisations often find themselves here, and my work typically takes me to this space eventually.
These Are Modes, Not Ideologies
I’m not presenting the above as an accurate history of each flavour, and I doubt that my description was the lived reality of the people working in Microsoft, Google, and Amazon at those times. But I am presenting the first three flavours as myths that have emerged about what a product way of working is. Product operating models can tend to take one of those myths and turn them into a single way of working . . . or take all three and turn them into a kind of product soup.
But they are better understood as modes of work. In truth, a single team may need all four on a single day. One flavour alone doesn’t give us everything we need. Different situations require different capabilities. As digital leaders we need to range across all four of them, and we must let our teams go where they need to. Real work isn’t like that sequential product operating model diagram.
If You Feel Stuck, You’re Not Alone
If your organisation has already attempted to introduce a “product operating model” and it hasn’t quite landed, you’re not alone. Many leaders are caught in the same trap. The language of product is present, the intentions were good, but the model hasn’t landed.
That doesn’t mean the work has failed. In practice, much of the work I do with organisations is exactly this: helping teams reconnect with the useful parts of product thinking and adapt them to the realities of their environment. You can do this too. If you take a pragmatic approach and use your judgement, that product operating model can cease to be viewed as ‘the truth’ and more like an input to start you off. Your real operating model will emerge one improvement at a time, evolving through practice.
Connect on LinkedIn — buy my book ‘Product in Service’
Most timely as I consider how to shape our product community