When Best Practice Becomes a Barrier
Having an MVP mindset and localised context for successful operational change
I’ve spent the better part of my career helping product teams figure out how to work better, both more efficiently and more meaningfully. The goal is always some version of the same thing; helping people collaborate in ways that are more aligned, more effective, and more grounded in what matters to the organisation.
Over the years, I’ve become increasingly wary of the promise of rigid operating models and frameworks that are passed around as if they were universally applicable to any organisation. We hear so much about “best practice,” yet I’ve come to see that term as often more harmful than helpful.
The real work begins when we let go of the illusion that there’s a single, correct way to run a product organisation. The truth is, no matter how shiny the slides, how popular the speaker, or how widely adopted the template, what works for one team can fail miserably in another team’s context.
Missing the Context
I’ve seen this play out time and again, sometimes in my own client engagements, and often in conversations with others doing similar work. And to be clear, the people sharing those slides and frameworks already know this, they’re not pushing a one-size-fits-all approach and they’re certainly not bad actors, trust me I am one of them!
The frameworks we share, whether on stage or in a workshop, are never meant to be strict instruction manuals. They’re a starting point, a shared language, a way to accelerate conversations and open up possibilities and not close them down. When these ideas get lifted out of context and passed around as gospel, it’s easy to lose the nuance.
Myself and
And a more recent chat with a fellow product consultant reaffirmed this. Adi Soesan Malishev had been embedded in a legacy organisation where even the phrase “product operating model” triggered anxiety.
Simply using it seemed to suggest that the work people had been doing for years was wrong. That they needed to change, to re-train, or to get out of the way. Of course, that wasn’t the intention but in organisations with strong roots in project-based thinking or service delivery even a subtle shift in language can feel like a threat to people’s identity and stability.
Adi’s approach was to quietly remove the phrase altogether. Rather than pushing a product operating model into the organisation, she introduced it as simply “a new way of thinking.” And by reframing it not as a critique of the past but as an evolution, they were able to make good progress towards being more product thinking.
Change is Emotional, Before it’s Operational
I’ve been in similar situations where the most difficult barrier to overcome wasn’t capability or strategy, but fear. Fear of what a new model might mean, fear of being left behind, fear of being exposed.
Cultural friction is real and too often underestimated. When we push a model before understanding the emotional landscape of a team, we set ourselves up to be rejected, regardless of the logic or evidence behind our approach.
What I’ve learned is that adaptability isn’t just a trait of good operating models; it’s a necessary approach for anyone trying to introduce change. Operating models need to be shaped by clear principles and capabilities, not directives.
Strategic alignment, clarity of purpose, continuous feedback, these are ideas that few people will object to in theory. But when we translate them directly into rigid frameworks and processes, we lose people.
Instead, we need to start where they are. What does alignment look like here? How is feedback currently gathered in this place? What small shift would make a difference today?
Start Simple, Then Evolve
That brings me to the importance of true MVP thinking and experimental approaches, something that feels lacking in the industry overall. These aren’t just product development concepts, they should be used when introducing any any kind of operational change too.
Sometimes you can introduce change with a very simple and iterative approach. Which is exactly what the Agile principles aimed to achieved. This isn’t a new or exciting concept, it’s just not cool to talk about Agile anymore. Agile software engineering was introduced 24 years ago with this purpose, a reframing of teams onto customer value and delivering iteratively.
One example from a previous client of mine was the introduction of a new product opportunity intake and management process for cross-business alignment. After introducing the concept, the reason why it was important for strategic alignment and where key people would be involved, we simply rolled out a lean process with a form and a spreadsheet. No fancy tools, no high-concept frameworks, it was designed to break in time and that was the point.
It created just enough structure to surface where things were working and where they weren’t. Within a few months, people began talking to each other more, identifying gaps, collaborating in new ways.
This wasn’t because they were directed to, but because the system nudged them toward it. The process didn’t need to be perfect, it just needed to exist. Once it was in place, it could be tested, evolved, and eventually replaced. And that evolution happened with the team, not to them. It also gave the Product Ops team some breathing space to figure out a longer term and more sustainable plan.
Too often, the instinct is to wait until we’ve got the full model figured out, to whiteboard our way to a complete process immediately without considering the constraints fully, to build the polished deck before we’ve tested a single thing. But process doesn’t need to be perfect to be powerful. It needs to be lived in, iterated on, and shaped in partnership with the people doing the work.
That’s where progress and momentum comes from, the confidence that grows when teams see even small improvements working in their specific world, not just the theory alone.
Adaptive Operations
The best operating models I’ve seen aren’t lifted and shifted, they’re adapted to the context of the organisation. They begin as principles and become practice through trial, error, feedback, and trust. This thoughtful tailoring is the work that sits behind the introduction and iteration of any successful framework.
What really matters is helping teams and leaders feel empowered to own their approach. That might mean easing in gradually, reframing the language, or starting small with something imperfect. And if that sounds less glossy than a slide deck, that’s because it is, but it’s also far more durable.
Because when people see themselves in the way their organisation works, they’re far more likely to engage with it, evolve it, and make it stick.