The realities of moving to the product operating model (part two)
Over the last 18 months, we've been pleasantly surprised by the increase in demand from organisations that are taking the Product Operating Model seriously and trying to translate theory into practice.
We hosted a similar panel discussion at Leeds Digital Festival. At that event, we invited organisations such as the FCA, eBay, Awaze and the BBC and co-author of Team Topologies, Matthew Skelton (check out Matthew’s write-up). At that stage, it still felt early.
This time, the discussion moved from why organisations make the shift to how they sustain it. We covered the funding and governance structures that either enable or harm outcome-driven teams, the qualitative signals that show whether change is happening, and why more mature teams are beginning to focus on product strategy.
The panel:
👉 Mahmoud El-Azzeh, VP of Product at OneFootball: “I've been in product management for around 15 years, so I've seen the discipline evolve from the very beginning. Back then there weren't product schools or courses. I learned product management at the school of hard knocks”.
👉 Martin Eriksson, Author of The Decision Stack: “I've been in product for about 30 years now. I've worked everywhere from large enterprises to scale-ups and startups. Along the way I've co-founded Mind the Product, and recently published The Decision Stack, and now spend my time advising and coaching companies”.
👉 Holly Donohue, Chief Product Officer at Genio: “I've been in product leadership for around ten years, with about fifteen years in product overall. I also used to organise Product Tank Manchester”.
👉 Chris Barker, Director of Digital Products at Travel Counsellors: “I actually came into product relatively late in my career. I'm not a technologist by background. Before moving into product about five years ago, my career was almost entirely in digital marketing and digital customer experience”.
Key-takeaways (TL;DR):
- Most organisations don't set out to adopt a textbook product operating model. Instead, they gradually adopt core principles in response to slow delivery, weak strategy, and poor outcomes.
- Funding teams instead of projects creates the conditions to empower teams to deliver better outcomes for users and the business. Whether teams are actually empowered depends on how decisions are made. Leaders still set direction, but teams need the autonomy to decide how outcomes are achieved.
- Organisations further along the journey are discovering that once product teams are empowered, strategy becomes the mechanism that keeps them aligned. Communicating that strategy requires patience, repetition, and far more communication than leaders expect.
- Quantitative metrics alone can’t tell you whether the model is working. Activation, retention, and story points can all be gamed once people know they're being judged on them. What holds up over time is more qualitative: whether people understand the strategy, feel empowered, and believe they can influence decisions.
- Over the years, the product profession has matured under increasing commercial scrutiny. That evolution has left product leaders uniquely equipped to help shape strategy using the same evidence-based disciplines they already apply to product development.
Questions:
Below we share the key takeaways. We’ve chosen not to name who said what in this summary. Instead, we’ve focused on surfacing the strongest ideas that came up across the conversation.
>1. What does a product operating model actually mean?
How the product operating model gets defined depends heavily on where an organisation is starting from. In fact, leadership may never use the phrase "product operating model" at all; the question that matters to them is what results are being achieved.
Whilst the exact terminology matters far less to leadership, product teams adopting the product operating model strive to consistently deliver outcomes, and not just build features for their own sake. Once outcomes are measured properly, teams start asking better questions, gathering evidence, and understanding what customers actually need.
For a business moving out of a traditional IT or project-based model, the single biggest shift is funding durable teams instead of funding projects. This shift also changes how commercial outcomes get treated. Durable teams stay close to customers and data, and stay empowered to keep solving problems over time. Features stop being built just because they sit on a roadmap, and continuous improvement becomes the point.
>2. Why are organisations taking this more seriously now?
Over the last five to eight years, we've seen the emergence of hugely successful product-led companies. Entrepreneurs, executives and investors have looked at those businesses and asked, "How are they achieving this?"
But whilst the visible success of major technology companies and unicorns has encouraged others to move in the same direction, the change is only worth making if it improves commercial outcomes.
The economics have changed:
Tougher investment and growth conditions have forced organisations to become more commercially focused generally, which has matured product as a discipline. The expectations placed on product teams today are very different from what they were even a few years ago.
Cheap capital is gone, so organisations now have to justify investment far more rigorously. That scrutiny naturally produces harder questions about what value an investment is expected to create and how that value will be measured. Failing to answer those value questions usually signals that an organisation is still thinking in projects rather than in products.
Product-centricity is going mainstream:
Many companies believe product-led growth can be a more efficient route to revenue than traditional sales or marketing-led growth. People look at the major technology companies and unicorns and naturally think "that must be the direction we should be moving in". This pushes organisations to change culture and bring in experienced product leadership.
What's expected of product leaders has also shifted accordingly. Leaders have evolved from writing user stories or translating requirements towards owning commercial outcomes and asking difficult business questions.
>3. Where are organisations on the journey, and how do they make the transition?
Very few organisations run a textbook product operating model; most are strong in some areas and still developing others. Some organisations are naturally product-minded before any formal change begins, already practising much of what the model describes. But more likely, organisations either claim to be adopting a product operating model without fully understanding what that means, or aren't aware of the concept at all.
Few organisations approach change by asking directly for a product operating model; most describe symptoms instead such as slow shipping, weak delivery, unproductive engineering. Digging into those symptoms usually surfaces different underlying issues: lack of focus, weak strategy, trying to do too much at once, and reacting to every customer or sales request. That means it's common to find organisations adopting practices gradually without ever formally naming the change, leaving some parts of the business working traditionally while others operate much more like product teams.
The principles behind a product operating model are therefore less about adopting a named model and more about asking better questions on alignment, measurement, and focus.
Credibility matters:
Prioritising outcomes over delivery dates, and commercial impact over shipping features, marks out the more mature organisations. Even so, credibility does matter. If product teams can consistently deliver value and build trust, the rest of the business becomes more willing to grant them the autonomy they need to feel empowered to chase outcomes.
The goal of product delivery isn't to go faster; it's to deliver more value, in the same way a better-designed bus carries more people reliably, rather than simply being wished into moving faster.
The transition is hard:
Founder-led companies present a particular challenge when founders have never worked inside another technology organisation and default to top-down decision-making, leaving both product managers and the founders themselves frustrated, despite both wanting more empowerment.
One of the hardest parts of this transition is helping such founders get comfortable with a product team making decisions differently from how they personally would.
The conversation becomes far more constructive when it moves away from "you're doing this wrong" and towards "we can achieve your vision more effectively this way".
In long-established organisations, changing the product function on its own isn't enough. The wider business has to adapt too, or one part of the company ends up working differently while everything around it stays the same.
>4. Where does the model go next?
Keeping product strategy and company strategy tightly aligned is becoming the model's next major evolution. For those who have spent time on operating models, empowered teams, priorities, and focus, conversations then shift towards strategy itself.
Giving teams autonomy without giving them strategic context is incomplete; the model needs to equip teams with both. Empowered teams can each believe they're solving the most valuable problem while collectively pulling the company in different directions, which is why re-establishing alignment becomes necessary.
The best outcomes come when product managers are genuinely invested in the company's vision, while still being encouraged to challenge assumptions using their closeness to customers.
AI also raises new strategic questions about where it helps and where it threatens a business, or specific parts of a product. Even before AI, empowered teams could drift apart without a clear strategic context; AI's acceleration of delivery makes that risk greater still.
Product's own tools (hypothesis testing, assumption-testing, experimentation, and discovery) apply just as well to shaping company strategy as they do to building products, which means product should help shape strategy rather than simply receive it.
>5. What are the biggest barriers to adopting a product operating model?
This can vary enormously from company to company, and no single product operating model fits every organisation; the model has to be shaped to the realities of the business it serves.
Funding and governance are big barriers:
Governance and funding are among the biggest barriers in larger organisations, where teams funded as time-bound projects are expected to deliver exactly what was agreed at the outset, making it hard to change direction as they learn. An outcome-driven approach is undermined directly when teams are judged against a business case approved months earlier, regardless of what's since been learned. This eventually puts a ceiling on how far an outcome-driven approach can go.
Funding durable product teams rather than individual projects addresses that barrier at its root.
Priorities shouldn’t keep moving:
Leadership pulls focus away from agreed outcomes by repeatedly introducing new priorities from conversations with shareholders, customers, or other executives, a pattern sometimes called the "idea of the week".
To counter that pull, the role of product leaders is to gently and repeatedly steer stakeholders back to the single most important agreed problem. Remind people: "Let's stay focused on the thing we agreed was most important".
Sometimes leaders simply don't feel they're getting results quickly enough. They want more with less. That's where patience becomes really important. You have to keep asking: "What's the single most important problem we're trying to solve?"
Realistic expectations matter early:
Meaningful organisational change of this kind takes years, not months, and trying to change culture, governance, decision-making, and ways of working all at once only stretches that timeline further; setting realistic expectations early matters.
Impatience for fast results and pressure to deliver more with less work directly against the patience the model requires.
For example, OKRs are frequently misread as execution plans, when they work best as expressions of strategy that may take several different initiatives to achieve.
Longer planning cycles like six-month OKRs rather than quarterly ones give teams enough time to complete discovery, build, and measure impact properly, since a quarter is often too short for all three stages.
On the other hand, another panellist favours frequent, six-weekly checkpoints on progress and assumptions without changing the underlying goal itself. Strategic goals should stay stable even while the tactics used to reach them get reviewed regularly.
Other barriers that exist:
Legacy technology, including large monoliths or heavily coupled systems, can block continuous deployment and other practices central to the model until the underlying platform is modernised.
Some customers can't absorb constant change, particularly where a release requires retraining or significant operational adjustment, which in turn limits how often software can realistically ship.
>6. How should funding work to support a product operating model?
Funding tends to be a bigger issue in large organisations than in smaller ones. A practical way to build the credibility that funding conversations depend on is starting small and expanding only as trust is earned through demonstrated delivery.
Outsourcing driven by cost-reduction is a bad signal:
A common question is simply whether engineering sits in-house or is outsourced. Outsourcing itself isn't necessarily a problem: an external team embedded closely alongside product and engineering can work well, though handing requirements over a wall can revert the whole thing to waterfall.
Outsourcing driven mainly by cost reduction often signals that engineering is being treated as a delivery function rather than as a collaborative problem-solving partner.
Leadership buy-in makes the difference:
In larger organisations, budgets approved one to three years in advance with predefined deliverables mean teams get judged against their original commitments rather than the value they end up creating.
Funding durable teams, rather than fixed projects, lets the work itself evolve as the team learns. This is essential to sustaining the model. But empowerment without accountability doesn't work; the two need to be paired.
Genuine buy-in from the CEO, and especially the CFO, is what makes productive conversations about funding and capital allocation possible in the first place.
High-level company goals around revenue, profitability, or growth need to be broken down into product outcomes that individual teams can genuinely influence, rather than holding a team accountable for something it doesn't directly control, like overall company revenue.
Transparency from empowered teams (surfacing problems early and explaining shifts in priority) is what lets leadership trust the model instead of feeling kept in the dark.
>7. How should organisations measure whether their product operating model is working?
The operating model should be judged by whether the organisation behaves differently, not by how many user stories or OKRs it has produced.
Tracking how many teams are actually using a new practice properly helps reveal whether new behaviours are becoming embedded rather than merely adopted on paper.
Metrics need stress-testing periodically:
Product-led growth metrics like activation, retention, and engagement are valuable, but the definitions behind them need challenging periodically to make sure they still measure the right behaviours.
A basic activation metric may not actually predict long-term retention. Testing which behaviours genuinely predict retention can reveal that a different, less obvious threshold matters more. Metrics that once seemed reasonable can quietly stop representing the outcome they were meant to track, which is why they need revisiting regularly.
Any metric can eventually be gamed once people know they're being judged on it. For example, teams once measured on volume delivered started inflating story points. This tends to happen without anyone deliberately cheating.
Qualitative measures matter:
Measuring the operating model itself is inherently more qualitative than measuring product performance, because culture, not process, is what matters. Also, qualitative measures are generally harder to game than quantitative ones, which is one reason to lean on them.
A checklist of completed practices doesn't, on its own, establish that a genuine product operating model exists.
Useful qualitative questions include whether people understand the company strategy, whether teams feel empowered, whether they understand the outcomes they're accountable for, and whether they believe they can influence decisions.
Establishing a baseline and repeating those qualitative questions periodically shows whether the organisation is actually evolving over time.
Lead time and cycle time complement outcome metrics:
Lead time and cycle time aren't value metrics in themselves, but alongside outcome metrics they help identify where work is getting stuck. Measuring cycle time can extend beyond engineering delivery to cover the full lead time from idea to release, exposing bottlenecks such as a discovery stage that consistently runs too long.
Long lead times are often caused by excessive context switching or by building large pieces of functionality instead of smaller increments. Ideas that trace back to XP, Lean and Six Sigma remain highly relevant to improving an operating model.
A further lens on organisational change comes from measuring how embedded AI is becoming in everyday work, and how embedded experimentation is becoming more broadly, even though these measures stay imperfect.
>8. What approaches to change and communication actually help adoption?
Different audiences absorb information differently, and communicating something once is rarely enough. Leaders consistently underestimate how much repetition a message needs before it truly lands, an idea marketing captures in the "Rule of Seven".
Leaders should expect to repeat strategy so often that it becomes tiresome to say, because that repetition is what helps make it stick for everyone else.
More conversations, and more chances to ask questions, all reinforce a message and help build a culture around it.
Build support incrementally:
A coalition that eases adoption later is built by identifying early adopters first (people naturally open to new ideas who can influence others) and refining a proposal based on their feedback before it reaches the wider organisation.
Adoption becomes far more likely when a proposal is framed as the solution to the problem each stakeholder is actually trying to solve.
Not everyone will be convinced, but building support incrementally can bring the large majority along regardless.
Meet stakeholders where they are:
Trying to prove a stakeholder wrong by piling up evidence against their idea rarely works and tends to trigger defensiveness instead.
A trust that pays off in harder conversations later is built by meeting stakeholders where they are, taking their idea seriously, and using discovery to improve it together.
Influencing people and understanding their perspective is a legitimate and necessary part of product leadership, whatever negative connotation the word "politics" usually carries.
Get leadership in-front of customers:
Stronger alignment often comes from bringing leadership directly into customer conversations, so they hear customers first-hand, rather than from arguing a point in a meeting.
What next?
This was the second event on the topic of the product operating model. If you’d like to revisit the takeaways from the first event, you can do so here: The realities of moving to the product operating model.
If you’d like to read a practical guide to the product operating model, written from our point of view, you can do so here.
You can also check out this write up of the event, written by one of the attendees.
If you’d like to attend our next event, you can sign up to our newsletter or follow us on LinkedIn.
