From product to service

What’s the relationship between product and service? How does that relationship work in practice, within a service-oriented enterprise-architecture?

What started this one off was this much-referenced comparison:

(My apologies, I don’t know who to credit for this image – perhaps let me know?)

It’s a great comparison, yet we can take it a couple of steps further, by linking it to a service-oriented approach to enterprise-architecture and process, and to the relationships between product and service, and between experience and service.

First, take a look at a previous post of mine: ‘Product, service and trust‘. From that, and from the other work on modelling with Enterprise Canvas, we pick out two assertions:

Everything in the enterprise is or represents or implies a service.


A product represents the promise of future delivery of (self)-service, via use of that product.

The keyword in that second assertion is future – “a promise of future delivery of service”. A product literally ‘leads towards’ that future service: it delivers (almost) nothing now. That distinction is rather important…

Another way of reframing a product is as a capability: the ability to do something, but without necessarily actually doing that ‘something’ right now. It’s kind of like a service, or part of a service, that’s been frozen in time: potential, not actual.

A service is active: it does something.

A product is static: it just sits there, waiting for something to happen.

A process, or process-flow, is a sequence of links between services, one set of actions-on-things leading to another set of actions-on-things, and so on, indefinitely, between arbitrarily-chosen start- and end-points for what we could ‘the process’.

In effect, a product sits between services, as a kind of interlude within a process, to allow links between services to take place asynchronously. We could visualise this as happening in-line along the process-flow:

Or as kind of attached or appended to that process-flow:

Which way we model it doesn’t really matter all that much – it’s more a matter of style or sense than anything else. But this then allows us to model, for example, a ‘multi-client’ relationship, perhaps delivering different products to different types of clients:

Or a ‘multi-supply’ relationship, with different suppliers providing what is nominally the same product to be used within the next stage of the process-flow:

Yet in each case we can see that a product sits between services, as an output from one service, or as an input to another. Hence some useful questions on product and service, for business-architects and others:

  • At what point does a product cease being static, and transition to become active, as (part of) a service?
  • At what point does the product deliver on its promise of service?
  • What are the events that trigger off this type of transition?
  • What are the services that arise from this product?

That last question becomes particularly interesting when we consider a product-type such as a smartphone, where the feel and the overall appearance represent ‘non-functional’ or qualitative services in their own right – much like an item of jewellery – separate and distinct from the ‘functional’ services such as communications and applications.

There’s also the key distinction indicated in that ‘product versus experience’ image with which we started above – an orientation towards the static between-services ‘product’, or more to the active in-service ‘experience’. Classically, this distinction tends to line up strongly with a question of perspective – ‘inside-out’, a provider-oriented view, or ‘outside-in’, a customer-oriented view:

In essence, experience is an outcome of service-delivery within that interaction-journey, and of product-usage in that service-delivery. One of the problems that we see from the above is that user-experience is all but invisible if we only take an inside-out view – and particularly if we assume that engagement ends with the delivery of the product. To make sense of user-experience, we need both views – inside-out, and outside-in – and a careful balance between them.

The ‘product’-type ketchup-bottle – with the cap at the top – is what we’d expect from an inside-out viewpoint. We could describe it as an outcome of an unbalanced view between inside-out and outside-in. It’s very much built from the provider’s perspective: ease of manufacture, ease of packaging, ease of transport, ease of display. The orientation is backward down the supply-chain, an output of the previous service. And the product itself represents the end-point of what the manufacturer considers as their own responsibility: what happens beyond that point is Somebody Else’s Problem – an assertion often emphasised in some of the small-print on the label of the product itself…

The ‘experience’-type ketchup-bottle – with the cap at the base – is what we’d expect from a better balance between inside-out and outside-in viewpoints. It’s built with an awareness of how the product would be used – how it would deliver on its promise of service. The only catch here is that an overemphasis on outside-in can perhaps conceal other affordances – other uses, other services – for the same product.

Useful, I hope? Comments, anyone?

3 Comments on “From product to service

  1. Tom, thank you for this fantastic post. And very comprehensive, too. I’m amazed by the many important aspects you manage to touch upon in a single blog post.

    You state that we need to have (a careful balance) of both the inside-out and the outside-in views to make sense of user experience. Could you please explain your thinking here briefly?

    I’ve been chewing on the role of products in service design, marketing and delivery for quite a while (shameless plugs to and I’m amazed by the strong focus of service-centric industries on physical products, e.g. in the mobile phone and game console areas.

    Selling a mobile phone with an added communications service subscription seems to make things simpler — alas, in my experience, that is only true at the surface. Aligning the company with the service(s) at its core would yield much better results.

    • Many thanks for this, Oliver – much appreciated.

      There’s a follow-on post I’m brewing about also going the opposite direction – or completing the cycle, rather – by looking at what happens when we go from service to product. Should be out in the next few days, I hope.

    • @Oliver: “You state that we need to have (a careful balance) of both the inside-out and the outside-in views to make sense of user experience. Could you please explain your thinking here briefly?”

      My apologies, I missed this question earlier.

      The boundary between inside-out and outside-in also represents the focal-point for the interaction-journey for user-experience – from both sides of that boundary. Both sides bring expectations and assumptions about what will happen in that interaction-journey; and if we consider only the assumptions from one side of that journey are valid – as in the classic ‘organisation-centric’ view of product- or service-design, or a ‘the customer is always right’ perspective – then we’re likely to end up with a messy user-experience that’s probably going to be an unhappy one from both sides.

      A classic example of a poorly-designed user-experience is when the organisation’s customer-support systems are built around the organisation’s own internal silos: the result is that, to get the outcomes they need, the customer will need to know how to navigate and integrate across all of those organisational boundaries – eventually often with a better understanding of the organisation’s structure than of those within the organisation itself. (There’s a first-hand example of that, in a bank, in the post ‘Enterprise-architecture: which way forward?‘ – a good example of what happens where the required ‘single view of customer’ does not exist.)

      To get a better outcome for both sides of the user-experience, we need to explore the expectations, assumptions and needs on both (or all) sides of that interaction-journey.

      I hope that makes reasonable sense? – if not, yell? 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *