Delivery, Service and Organisation: what each layer means and why it matters.

Written By george sheldrake

In practice, I keep seeing large organisations adopt the product operating model (POM) while their understanding of service and organisational design is not keeping pace.

 My last post argued that the POM is one layer of three. It is Marty Cagan’s term for the way strong product companies work. Adopted without the organisational conditions and service purpose around it, it produces well-run product teams inside services that can still fail, and organisational structures that act as barriers.

The three layers are delivery (which includes product and operations), service and organisation. These three books describe them well:

  • Delivery Product: Marty Cagan’s Transformed sets out how empowered product teams deliver and what is needed for product success.

  • Service :‍ ‍Kate Tarling’s The Service Organization defines what an organisation exists to deliver, starting from what people are trying to achieve.

  • Organisation: Adam Maddison’s The Intelligence Era Organisation describes the organisational conditions that make good delivery possible.

Each book describes its own layer in depth and touches on the others. This post sets out how I see the three layers. The next compares what the three books say about them.

How I see the three layers 

Terms do not mean the same thing to everyone. Tarling notes that “people often misunderstand or aren’t in agreement about what a service is” (p. 10), and that ‘product’ means “different things to different people in different sectors” (p. 30). 

“...the tech industry is not great when it comes to standardization of terms. We often have different terms for the same concept and, in some cases, different definitions of the same term.”‍ ‍Marty Cagan, Transformed

Cagan treats a ‘platform service’ as a type of product (p. 8), while Tarling treats products as parts of a service. To work around this, I encourage people to describe things by their qualities and emphasise the importance of visuals to bring them together. I explore this for service in How to define ‘service’? Much of what product, architecture, service design and business teams discuss is similar thinking under a different name.

Before I bring together themes across the three books, I want to be clear about how I use the terms. This is my position, and I have drawn on other voices to bring it together. I see three layers: delivery, service and organisation. They differ mainly in how tightly they are defined, starting in delivery and working up. I include operations in delivery, but this post covers only the digital side.

Delivery layer: How products and operations are built and run

A product is a discrete capability or tool, digital or physical. It enables a user to complete a task, step, transaction or output within a wider service. Good products are designed for users or customers, meet business needs and use technology well. Tero Väänänen, then Head of Design at NHS England, describes a product as ‘tangible’, something that delivers outputs (2022).

A product needs a defined scope. A team can build, iterate, own and measure it on its own terms, without being asked to do everything. It may be an app, a booking system, a results portal or a backend call management tool. It is a component of the whole experience, not all of it. Because a product has an edge, it needs a tight enough definition to be successfully delivered.

At scale, the delivery layer covers how products and operations are run and managed, and the teams, capabilities and people involved. This is where the POM lives, as a set of principles for good product practice (p. 114).

“The product operating model is not a process, or even a single way of working. It is a conceptual model based on a set of first principles that strong product companies believe to be true.” Marty Cagan, Transformed

In What is a Product? (2019), Marty Cagan writes “Product = Customer x Business x Technology”, an equation he credits to a former engineering manager. A gap in any one means the product will fail.

Service layer: what the delivery is for

Coming from a service design background, I have been surprised by how poorly this layer can be understood. I spend more time on it here for readers who know business or product framing better.

Service adds intent, outcome and policy to Cagan’s equation, and treats the operations behind the product as part of the same system. A product cannot do everything for everyone. Service is the next level up on a scale of abstraction. It treats everything needed to reach an intended outcome or goal, for all customers and the business, as one system.

A service helps someone achieve an outcome. It includes every step the person takes and everything the organisations involved in delivery do to enable it. Every product, human interaction, physical touchpoint, backend system and organisational process involved. Tarling describes this as an ‘outside in’ approach “starting with what users are trying to do, and including everything that’s involved in using or delivering the service” (p. 24). This means everything, intended or not — the parts that work and the parts that fail.

Goals and outcomes in service

  • On Goals:  Lou Downe defines a service from the user’s point of view: “A service to a user is something that helps them to do something” (Downe, p. 19). Tarling points to Downe’s work and adds the organisation’s own outcome. I would add one more thing. Sometimes the goal comes from how organisations or governments want people to behave. For example, if I am planning a holiday abroad, I only ‘need’ a valid passport because it is a government requirement for travel and so I use the service to renew it. The user’s goal is the holiday. The government’s goal is a valid passport. The service sits between the two.

  • On Outcomes: In healthcare, a person managing a long-term condition may have no ‘direct’ goal to reach. Their medical team will be working toward the best possible health outcome for them and their needs. Preventative health screening may help individuals, but it is also driven by the government’s need to reduce poor health outcomes at scale. Framing a service by outcome helps in these tricky scenarios.

This is also why products and services differ. Väänänen puts it this way, “Products deliver outputs, services deliver outcomes” (2022). His example is booking an appointment. The confirmation is an output, but the outcome is the person attending. If a team only measures confirmations, he says, “we miss the point”. Cagan and the POM also talk about outcomes, and that product teams are held to them. My reading is that a product team can only measure the part it controls, while a service outcome spans every step, including the connected steps no product team owns. Again this is a good example of people saying similar things, but using different language to make their point. 

Väänänen frames outcomes as the user’s goal. I would widen that, as the box above shows . A service is malleable. It can be achieved in many ways, and as long as the outcome happens the service is working. I have seen this work well in a ‘lean’ approach, leaving the outcome fixed and quickly iterating the delivery to meet it.

A product is more specific and must be deliverable. A service is described by its intent and the qualities that make it up (think of these as tags). I first mapped services by their qualities in 2014 at the UK Ministry of Justice. I have since extended this in How to define ‘service’? (2022) and How to understand ‘services’ as a tool for your whole organisation (2025). My 2014 maps relied on  end-to-end journeys. Later work in healthcare showed the limits of that view and shifted to the notion of ‘whole service’.

At scale, the service layer covers every service the organisation offers, and how they come together across channels, from front to back, and across digital and physical, as one connected system. Large services are often too big for one team to own. They are made up of many products across multiple stages, and the teams behind them share systems, standards and reusable components. Responsibility for a whole service is shared.

“Just because you don’t provide the whole service, doesn’t mean you’re not responsible for the outcome”, Lou Downe, What is a service? 

Book an appointment as a service offer

Organisation layer: the structure around both

Organisation is the structure that houses both delivery and service. Think of it as the body. If there are blockages, breakages or badly designed communication, the other two layers suffer. How a service is delivered is never separate from how the organisation delivering it is managed.

A well-known reference here is Conway’s Law (Melvin Conway, 1968) ‘organisations that design systems produce designs that mirror their own communication structures’. Tarling addresses it directly, “to break from Conway’s law, orient organizations around their users, services and outcomes rather than around their existing internal structures” (p. 238).  Maddison describes these influences as systemic conditions. Conway’s Law is one of many such conditions, and each can be addressed directly. 

“To succeed, we must stop looking for the next quick fix and start addressing the systemic conditions that allow innovation to take root.” Maddison, The Intelligence Era Organisation

Moving from a ‘project to product’ mindset sits with the organisation. Cagan covers this in Transformed, including the role of the CEO and of finance. The shift depends on budgeting, funding models, procurement, governance, capability and workforce. Where an organisation does not change these, Maddison calls the result ‘performative change’, where activity “becomes a substitute for substance” (p. 34)

Conclusions and my next post

Delivery needs a tight definition. Service needs intent, outcome and qualities. Organisation sets the conditions for both. The POM is a strong answer for the delivery layer, and Cagan is clear that it needs wider change to work. What I see in practice is the POM adopted without the service purpose and organisational conditions around it. That is how well-run product teams end up inside services that still fail.

In my next post I look at what the three books share. The authors write for different audiences and from different disciplines, yet they return to similar principles, each in its own terms. Read together, they show what is needed at every layer.

References

george sheldrake
Next

Alone, the product operating model is not enough. Three authors that explain why.