Alone, the product operating model is not enough — three authors and layers explain why
I started writing this a while back, but teaching and a few other things meant it sat on hold for a while. Coming back to it with fresh eyes helped me refocus a bit on what matters most.
I have found three layers come into play when modernising or adapting a business. The more we design intentionally across all of them, the less we leave to chance. This means intentionally seeing all the layers that affect our intended delivery outcomes as interconnected.
If we are modernising digital products then how the organisation works to support this is important in enabling product team success. So too is being strategic about service offers and intent. There is little point in over investing in the wrong offer, dialing up the wrong product area first or duplicating effort.
If you do not consider upstream layers as necessary conditions around your ‘product’ investment you are making a business design decision to leave its conditional success ‘undesigned’. And this can be a costly and risky way to work.
All the layers matter
So if we think of the conditions as upstream and downstream layers they look a bit like this:
The wider landscape: The business, policy, market, and regulatory environment within which any organisation operates. Transformation is harder where this context works against it and easier where it actively enables change. While we will not dive deep into this it helps to set our frame of reference, this space can be especially relevant to some sectors like trade or government.
The organisation layer: The culture, leadership, governance, and funding conditions that determine whether any delivery model can succeed. This is not the service itself. It is the environment that makes delivering the service possible. Without the right conditions, any framework adopted within it will produce the appearance of change rather than the substance.
The service layer: The business offer, what the organisation exists to deliver. Defined from the user's perspective rather than the organisation's own. This is the strategic intent made real. Within the service, two mechanisms of delivery work alongside each other: operational delivery, which includes the human, physical, and process infrastructure that serves users directly; and digital products, the discrete capabilities and tools that enable users to complete tasks. Neither sits above the other. Both serve the service.
The delivery (product and operations):
Product: The discrete digital capabilities and tools that sit within the service alongside operational delivery. A product enables a user to complete a task. It is a component of the service, not a substitute for it. Powerful when the levels above are resolved. Expensive and directionless when they are not.
A note on operations: This post focuses on digital products, but the same layered thinking applies to physical operational design. Technology and products are levers for wider business change. Thinking in outcomes lets you measure what is actually achieved, rather than treating digital as a like-for-like replacement for physical processes.
Visualisation of each layer you should consider
Why does this matter at all?
Thinking in layers forces a realistic view of how change actually happens. A business with thousands of employees, multiple service lines, digital products, and frontline staff is a connected chain. It is too big to change all at once.
The best examples I have seen account for this scale, finding ways to link the organisation and its services before expanding. Starting small works, but only if the conditions that made it possible are protected and then scaled by design. A project-based approach will not cut it if you want what you are delivering to live beyond your project budget.
Big programmes regularly fail to retain capability and practice change because investment goes into delivery while applied capability, service design, strategy and organisational design are treated as optional or as documentation. A strategy document will not make people change, especially when it is the next one in a very long line.
The best tool is an applied approach that shows outcomes and is designed. What I love about all three books is that they see this as an important reality, they explain in detail for their respective layers and provide tangible, real-world examples.
On thing to consider is that even our mental models for each layer are different so when we change say the ‘product operating model’, the layers above may not naturally link without careful consideration and articulation of how they successfully connect. (You can see some sketches of this below).
Great reads to help you
These three books address each layer in depth, with practical examples, clear recommendations, and descriptions that connect directly to real organisations.
Organisation: The Intelligence Era Organisation, by Adam Maddison, https://public.digital/pd-books/pd-book-creating-the-conditions-to-thrive-in-the-age-of-ai
Service: The Service Organization, by Kate Tarling, https://www.theserviceorg.com/
Product: Transformed: Moving to the product operating model, by Marty Cagan https://www.svpg.com/books/transformed-moving-to-the-product-operating-model/
Each of these books has deep insight into each layer of the business where change needs to happen and speaks plainly about risks with actions and examples. My focus here has largely been digital I think of it really as a lever for wider change. So if you think about physical operational change its connected in the same way digital is, so many of the same practices can be used here that you might see in product or service design.
Reflections on layers
In my experience working in design delivery and strategy over the years I have hit barriers at each level. You can have inspired leadership, talented teams and still not have the conditions for success. Making change needs to happen at multiple levels in a way that creates conditions for the other levels to succeed. Throwing things over the fence never works well for anyone!
The easiest example to describe is a product team working to find and solve problems within a hierarchical organisation that has none of the structures set up to allow the team to act on their own findings and recommendations. Without enabling this to happen within the organisational structural realities (eg. governance, service design, processes…) behaviours and mental models will work to prevent any change. If making modern product teams is your goal you also need the business around them to adapt too.
When organisations omit this wider frame from their digital product change, they risk keeping traditional command and control business structures and business-led strategy intact. This creates a real disconnect as they expect the new product teams to deliver customer-centred autonomous product work inside what already exists. If the organisational conditions and strategic intent needed to support the model are left unaddressed those people and teams will struggle to deliver effectively or burn out trying.
This places the burden of that mismatch on delivery teams. Small autonomous teams find themselves cycling through the same unresolved barriers: structural and operational constraints, financial and governance hurdles, and leadership that does not yet understand that transformation requires change above the product layer as well as within it.
Why these books?
Cagan, Tarling, and Maddison each address the detail within their layer. To my mind they have independently come to similar conclusions which means as a set they sit well together. (I am still working on my next piece on the themes.
Organisation layer: Maddison in the Intelligence Era Organisation
Maddison’s work highlights the organisational practice, behaviour and conditions that need to be created. He identifies five core conditions that high-performing organisations share: a focus on customer or user outcomes, fast iterative feedback loops, frictionless data access, empowered teams given problems to solve rather than outputs to deliver, and trust as the foundational condition that makes all the others possible.
These are not seen as ‘cultural aspirations’, they are structural requirements for success. Without them any framework, change or technology adopted within the organisation will ‘amplify’ whatever is already there rather than changing it.
"If your organisation is a mess of silos, handoffs and theatrical governance, AI will make you an extraordinary mess, faster." Tom Loosemore, Foreward: The Intelligence Era Organisation
Maddison is direct about AI as an amplifier to whatever conditions already exist. In good organisational conditions it amplifies success, in poor ones dysfunction.
Service layer: Tarling in the Service Organization
Tarling explains what is needed to position the business from the customer or user perspective, rather than from how the business processes its own work. She defines a service through four qualities rather than a single definition.
A service describes what someone would actually want to do: drive a car, go on holiday, get a mortgage. Not a transaction or a touchpoint. It has a desired outcome for the organisation, which is the way in which it believes it can deliver on its purpose or generate value. It includes everything between the user, the provider, and all other actors involved, including the parts that fail and the workarounds people use. And it includes everything involved in delivering it: the technology, the people, the culture, the commercial decisions, and the relationships.
"A service helps someone to do something or to bring about something, where an organisation has a desired outcome it wishes to achieve." Kate Tarling, The Service Organisation
Critically, Tarling is explicit that products sit inside services as components of capabilities, not the other way around. A product is a sub-layer of the service. Without the service frame, products have no coherent container and no clear measure of success beyond their own metrics.
The Product Layer: Cagan in Transformed
Lastly, Cagan gives the perspective of what is needed to operate as a product-led business. He is explicit from the outset that the product operating model is not a framework or a process. It is a conceptual model based on a set of first principles about how the best technology product companies operate. This distinction matters because most organisations adopting it are treating it as a framework. Rolling it out as a set of rituals, job titles, and team structures without making the cultural and decision-making shift that makes those things meaningful.
The failure mode he names for this is the ‘feature factory’. Teams follow a stakeholder-driven roadmap, shipping features to a plan, with no empowerment to question whether those features are solving the right problems.
"Most product roadmaps are actually a list of outputs. Rather than problems to solve, they are features to build." Marty Cagan, Transformed
The product operating model exists to replace that with empowered teams given problems to solve and the authority to find solutions. But it only works when the conditions and the service frame above it are already in place. Without them, you get better-titled feature factories producing the wrong thing more efficiently.
These books together cover more of what you need!
Each author gives context to what their layer needs from the others. Together they cover more ground than any one of them does alone. If you have the time, read all three. If you are implementing the product operating model I would recommend you also look at Tarlings work especially for government and large organisations with physical business. For older traditional businesses whose structure has been the same for a long while take a read of Maddison.
Maddison is the shortest and a good place to start. If the service layer is newer to you, Tarling's book is the clearest introduction to its value.
—-
I am working on pulling together the themes that run across all three books, seen from different levels of the same system. I will share this when it is done!
