Sharks, Cakes and Kebabs
We welcomed John Cutler, self-proclaimed optimistic pragmatic sceptic today, to share his perspective on product operating models, team topology, governance and how to focus efforts for success.
With participants tuning in from both Melbourne and Sydney, John shared a wealth of insights, drawn from his experience working with companies of all sizes. His anecdotes and practical advice are invaluable for anyone embarking on or deepening their product-led journey.
The tension between the ideal and the reality
John started by noting the importance of acknowledging the reality of your organisation when considering how you move to a product operating model. The principles we read in books about "the best" manifest differently depending on the context. Many of those companies that we put on a pedestal, were actually “born” as product-led organisations, while others — think banks and insurance companies with high levels of regulation — have deeply ingrained centralised IT functions and historical ways of working.
Transformation isn’t about copying what works at top-tier tech companies; it’s about adapting those principles and lessons to the specific context of your business.
"It's like a teenager growing up by the beach and being able to surf. It is very different than when I arrived in Santa Barbara never having surfed. I'm supposed to just go in the water? It's not going to go so well for me. I'm scared of sharks"
Team topologies
A service blueprint of customer journey is a good place to start, combined with understanding the capabilities needed as the customer moves through various touchpoints.
"What are our stable parts of our business? What do we need to be extensible? What doesn't need to be extensible. How are customers navigating our product surface area differently now than they did 5 years ago?"
Try to take into account collaboration needs and leave room to flex.
"It's better to have a somewhat fungible org chart initially."
Companies sometimes pile on architecture or processes without considering how well they integrate, much like stacking kebabs on layers of cake. The shift to becoming a platform team takes time, as teams migrate services and refine the architecture.
"I joke with enterprise architects. They all have that one slide that looks like the kebab on top of the cake."
Labelling a team a "platform team" doesn't make it true. Platform capabilities should emerge organically as the company scales and recognises the need for shared services.
Different work, different governance
Not all work is the same, and it helps to recognise different shapes of work. Whether it’s highly incremental tasks, heavy governance efforts, or innovative greenfield projects, each type of work demands a tailored approach. As John put it, “you need to name it to tame it.”
In practice, this means not applying a one-size-fits-all framework across every project. Some efforts may require close oversight, heavy dependencies, and legal involvement, while others can be left to run autonomously.
Outcomes v outputs
When shifting to a product operating model, one of the first concepts companies encounter is the shift from outputs to outcomes. However, be careful about becoming too “religious” about outcomes over outputs. In the real world, outputs (what you ship) still matter. After all, you can’t create value if you aren’t delivering anything.
"you can only make the shots that you take"
Overall, there were lots of great reminders about where to start in your Product model journey, how to think pragmatically about outcomes over output, the art and science of defining the optimum team topology and thinking about the right model for your company. Be cautious about taking lessons from FAANG companies as they all have their OWN version of a product operating model and each are vastly different to each other.
