Link: http://weblog.tetradian.com/2014/09/16/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.
and
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?