Service, product, service – summary and checklists
Blog: Tom Graves / Tetradian
How do we describe ‘service’ and ‘product’ in the same way for every scope and scale, every type of context and content? That’s the theme for this series of posts.
In ‘Service, product, service, simplified‘, I aimed to simplify the relationship between product and service by describing them not as different types of elements, but as merely different ways to choose to look into an overall flow of value as it undergoes change:
Using an analogy from quantum-physics, it’s like the difference between wave and particle. When it’s active, like a wave – when we see something happening to or in that flow – we’d describe it as a service. But when we choose to focus on status – a static snapshot, like a particle – we’d describe it as a product. But these are just different ways to view what is actually the same overall flow: the flow itself is still the same.
The reason why we might see ‘service’ and ‘product’ as distinct relates to how we choose to draw boundaries. If it’s inside of where we draw the service-boundary, we say it’s a service, whereas if it’s outside of where we draw the service-boundary, we say it’s a product. This also tells us that products exist between services: products are outputs from services (hence ‘product’ – literally ‘that which is lead from’), and products are inputs to other services (hence affordances etc).
Note that we choose where to place those boundaries: even right down to the atomic level, any boundaries we draw are still just a choice. And those boundaries may be layered or fractal: services may contain other services (decomposition and aggregation), and products may contain other products (components and assemblies).
Yet note also that if products exist ‘between’ services, then. services may contain products between their ‘child’-services. Note also that those ‘contained’ services and products are made invisible whenever we set the service-boundary around the containing service (‘black-box’). Or, conversely, those ‘contained’ products become visible only when we look inside the containing service (‘white-box’). In a specific sense, the inverse can also be true, that products may contain services within themselves or within their ‘child’-products. And those ‘contained’ services become visible only when look for them as ‘services-in-stasis’ hidden within the product.
On the relationship between them, a product may be used as input for many different types of services; a service may use as input many different types of product; and a service may output many different types of product.
On ‘architectural completeness’, a service is ‘architecturally complete’ – by definition, it must incorporate all types of service-content (assets, functions, locations, capabilities, events, decisions), because it represents activity that takes place in the ‘Now’. By contrast, a product is always ‘architecturally incomplete’ – it consists of a packet of one or more assets (in any combination of asset-dimensions). A product may be associated with a location or any of the other activity-related service-content elements, but they’re not inherent to the product itself – an important distinction.
As a simple summary for all of the above:
- ‘service’ and ‘product’ are different views into the same overall value-flow – a service represents activity, whereas a product is a snapshot of state or status
- a product is also always a subset of some service – specifically, an ‘asset’ element within a broader service
- we make a product ‘visible’ by drawing boundaries that will seem to place that product-asset ‘outside’ of any service
- drawing a service-boundary always renders some service-elements invisible
- any boundary that we draw – defining inside versus outside, or service versus product – is always arbitrary, and always a choice
Next, from the post ‘Service, product, service – implications for architectures‘, on practical implications, we ended up with this checklist:
- What is the product?
- What services does the product connect?
- What are the boundaries and gaps that the product must bridge across?
- What ‘frozen services’, if any, are embedded in the product?
- How does the product indicate the service(s) it is intended to connect with?
- What other services could the product connect with?
- How well does the product connect with and support the intended overall outcomes?
We then had a kind of side-series of posts responding to specific questions that arose from those first two posts. The first of these, ‘Service, product, service – a novel concept?‘, addressed a comment from Nick Malik where he suggested that the notion of services and products as views into value-flow would be a ‘novel concept‘ for many. In the post, I suggested, that ‘novel’ or not, the only way we can make sense of value-flow is to understand that product isn’t something separate and distinct from service: the whole notion of ‘product’ is an artefact of how we choose to draw service-boundaries. And likewise, ‘service’ is an artefact of, again, how we choose to draw boundaries across the overall flow of value undergoing change – with those boundaries most often arising from how we perceive apparent gaps in time or place, or apparent change in responsibility.
The next in that side-series, ‘Service, product, service – a question of structure?‘, addressed a question by Jan van Bon on service structure. My answer there was to point to some of my previous posts on service-content, such as ‘Services and Enterprise Canvas review – 5: Service-content‘ and ‘Fractals, naming and enterprise architecture‘.
Next was ‘Service, product, service – service as product?‘, in reply to a question by Kevin Smith, asking about the case where a service is described as product, or vice versa. My summary there was that if we ask “Is the app a product or a service?”, the accurate answer is ‘Yes, therefore No’. A more useful question is “When is the app a product or a service?” – the answer there is that it’s a product when it’s static, and a service when it’s active.
Last in that side-series, ‘Service, product, service – everything for hire?‘, my response to Jordan Julien’s assertion that ‘products are hired by users’. My summary there was that this represented a special case – a subset of sales-context, which itself was a subset of of service/product contexts – and that we need to to be careful not to apply a special-case as if it’s the whole.
Returning to the main series, the next post, ‘Service, product, service – responsibilities‘, explored the question of responsibilities in relation to product and service. The usual assumption seems to be that service is our responsibility, whereas product is someone else’s responsibility – but as indicated by the need for warranties and the legal challenges around product-liability and the like, it doesn’t work that way in practice. In particular, we need to beware of responsibility-avoidance games, because these can have huge consequences for anticlient-creation, and for kurtosis-risks that can damage or destroy an entire industry. This also has major implications for any shift from product-orientation (‘selling product’) to service-orientation (‘selling service’), because responsibilities that may have been previously ignored will immediately return to the service-provider.
The next post, ‘Service, product, service – start with product‘, examines what happens if we start the chain from a product-perspective. The key challenge here is that whilst we always know the parent-service for a product, we don’t necessarily know the service in which a given product will be used (hence affordances etc). And every product has a context defined by the boundaries of a broader-scoped service. So if we do choose to take a product-oriented or ‘product-first’ view of value-creation, note that although we (should) always know which service a product comes from, it may not always be clear which service a product should go to. We need to find ways to make that choice as clear and ‘self-evident’ as possible.
The last post in the series, ‘Service, product, service – promise and product‘, explores how all of this plays out in the sales-context. The quick-summary here is that the only thing actually sold is a promise of future value. Services take action towards that promise; products are the outcomes of that action and/or records or confirmations of what we did towards that promise. So whether we’re nominally selling ‘service’ or ‘product’, what we actually sell is a promise: we then have to deliver on that promise. In terms of the structure we’ve been exploring in this series of posts, that relationship would look something like this:
We can summarise the relationships – before, during, after – in terms of the Service-Cycle:
Before we make the promise, we must verify shared-purpose and context, and verify the parties, their relationships and scope. We can then establish the agreement(s) for action – the promise itself.
During the actions on that promise, we must set up the required service; run the requisite service; and complete the action, verifying any products from the service.
And after we’ve done those actions on the promise itself, we need to ensure a series of completions: we complete for the agreement, we complete for the relationship, and we complete for the shared-enterprise.
So for a sales-type context, what we actually sell is a promise – a commitment to deliver a specific service and, optionally, one or more specific products. When the promise is accepted and (maybe later) actioned, it triggers a service, to deliver on the promise. Any product is an outcome or output from the service, becoming visible and accessible once it moves outside of the nominal boundaries of that service. And in addition to ‘the service’ or ‘the product’ that are the nominal focus of the sale, further services and products will be needed to verify compliance of service and product to the promise.
Finally, a quick recap of the themes in this series:
- Service and product are not fundamentally different, but instead are merely different ways to take a snapshot-view into some part of a continuous process of value-creation.
- If our snapshot focusses on some set of activities over some period of time, we would describe it as a service; if the snapshot is of the statue or status of value-creation at a single frozen moment, we would describe it as a product.
- For products, the key criterion is where we draw the service-boundary: a product is identifiable as ‘product’ only if it is outside of any respective service-boundary. (When inside a service-boundary, it is merely another asset that’s currently in use by the respective service.)
- Wherever a gap or transition occurs between any two services – a change in location, responsibility, delay and suchlike – then at least one product must exist to act as a bridge to provide continuity across that transition or gap.
- When viewed in active form as a service, that segment of value-creation must include all of the elements of service-content – assets, functions, locations, capabilities, events and decisions.
- When viewed in static form as a product, that segment of value-creation can include only assets, though in any combination of asset-dimensions (physical ‘thing’, virtual data, person-to-person relation, and/or person-to-abstract such as purpose or brand).
- Fractality applies: services may ‘contain’ other services and/or products (as ‘assets’ or ‘resources’); products may contain other products and/or services (the latter in temporarily-‘frozen’ form).
- In short, the only key distinction between ‘service’ and ‘product’ relates to how and where we choose to draw the respective service-boundaries.
- We can start the chain from either service or product – but note that whilst we always know which service a product comes from, we don’t always know what service a product will go to.
- In sales, what we really sell is a promise – any subsequent services or products are merely a means to achieve that promise.
And as a bonus-item, some links to older posts that may be relevant here:
- ‘Product and service‘
- ‘Product, service and trust‘
- ‘From product to service‘
- ‘From service to product‘
- ‘Service, product, service‘
- ‘What is the boundary of a service?‘
- ‘Service, product and architecture terminology‘
- ‘Services and Enterprise Canvas review – 2: Supplier and customer‘
- ‘Services and Enterprise Canvas review – 5: Service-content‘
- ‘Services and Enterprise Canvas review – 6: Exchanges‘
- ‘Fractals, naming and enterprise architecture‘
- ‘Declaring the assumptions‘
- ‘On ‘shared-enterprise’‘
- ‘Organisation and enterprise‘
- ‘Organisation and enterprise as ‘how’ and ‘why’‘
That’s it for now on all of this: over to you for your comments, if you wish.
Leave a Comment
You must be logged in to post a comment.
