Service, product, service – responsibilities

What’s the difference between products and services? One of the key differences, perhaps, is in how we view the respective responsibilities…

The core theme in this series of posts on the relationships between product and service, and the follow-on implications for architectures, is that service and product are not different things, but merely different views into the same overall flow and change of value across an enterprise. When something’s happening, to change some form value, we call it ‘service’; when we take a static snapshot of some part of overall value, we’d call that ‘a product’, but in effect it’s actually just another aspect of service in temporarily-‘frozen’ form.

To me that’s been obvious for decades. Yet from the responses to those posts, it’s become clear that for many people, maybe even most, this is not ‘obvious’ at all – in fact not merely a novel concept, but one that triggers all manner of still-unresolved doubts around structure, differentiation and economics-issues.

Which, to me, is really odd, because this ‘quantum-like’ approach – service as dynamic, product as static – makes everything much, much simpler. For example, at a commercial level, it helps us identify who does the work:

• Your business presents an ‘offering’ – an offer to deliver something of value to the customer.
• If you expect that your business (or its agents) will do the work of that offering, you’d probably describe it as a service.
• If you expect that the customer will do the work of that offering, you’d probably describe it as a product.
• Either way, you are legally liable for whatever happens with that offering.

Or, to paraphrase somewhat a comment on LinkedIn by Casimir Artmann:

If you are responsible for delivery over time, it’s a service, otherwise it’s a product.
Rent a car, or buy a car.

There are (a lot of) further nuances, but that’s basically it. In any case, hugely simpler than the impenetrable morass of special-cases and arbitrary definitions that so often arise from the classic concepts of product and service.

One of the ways in which it makes things simpler is by making it easier to understand the role of service-boundaries, which in turn helps to clarify responsibilities – commercial, personal, legal and otherwise.

Again, the usual way to look at this is to regard service and product as fundamentally different things. As above, if we’re going to do the work – assign ourselves the responsibility for the work – then we’d call it a service:

Or, alternatively, we create a thing – a product – that we provide to the customer, and they then have the responsibility to do any requisite work with that product:

Which at first glance seems straightforward enough. To use the classic example, if the customer wants a hole drilled in a wall, we can either sell the service of drilling a hole for them, or sell them a drill so that they can do it themselves.

Yet that simple model breaks down when the ‘product’ is anything other than straight physical, or straightforward data such as a video-stream. For example, an ‘insurance product’ is basically a documented-promise about future service – that services and/or products will be provided somewhen in the future if a certain kind of event occurs.

And whilst that usual service/product split looks simple on the surface, the reality can be a lot more complicated. This becomes immediately evident once we start doing any decomposition of those services or products: for example, services often embed products that are used within the service (such as the oil provided in your oil-change service), and products can also embed implied-services (such as the warranty provided with the drill). The simple product/service split works well enough at the abstract level – but as soon as we touch the real-world, it gets real messy, real fast…

The way out of that mess is to reframe both service and product in terms of boundaries and responsibilities.

To start, we first lift the view wider, looking at value-change as a whole – such as in a supply-chain or a value-web. In the classic model, products and services would be framed as nodes of interaction within that overall view – the overall chain or web:

Yet what is it that delineates those nodes within that broader whole? The short-answer is boundaries, and other discontinuities:

• change of responsibility – transition from service-provider to service-consumer, change of organisation, change of business-unit etc
• change of agent – transition between person and IT, transition between units in a production-line etc
• discontinuities in space or time – change in location, delay, timeout etc

The simplest way to understand this is that wherever there is a boundary or gap between services, one or more products must exist to bridge that gap; and, in turn, wherever we see a product, there must be a service that produced it, and there must be at least one service that can use it as an input:

Which also tells us that if we don’t see a product between two seemingly-linked services, or at least one follow-on service for each product, we’re likely to be missing something that could be important…

Which is where we come back to that point about responsibilities. In the classic view, our responsibilities begin and end at our service-boundary: whatever happens outside of that boundary – and perhaps especially anything that happens with our products – is always Somebody Else’s Problem. To counter that comforting fantasy, though, there’s that pesky legal concept of ‘product liability’ – enforcing responsibilities not only for the use of our products, but also for testing and verifying that the products we use are fit-for-purpose. And these responsibilities can continue echoing onward throughout all of the players, services and products in the entire supply-chain and value-web, and outward into every other interaction within the respective shared-enterprise:

…or, generically, in fractal form, for every service and its relationships – each of which implies one or more products to connect across the respective boundaries:

So how much do those responsibilities change over time? And how long do those responsibilities last? The short-answer would be “A lot longer than most people seem to realise”. For example, in the post ‘Service-design: How long is a service?‘, I talked about a memorable meal at an upmarket restaurant for a key family occasion – my grandmother’s eightieth birthday. From the restaurant’s perspective, the service-boundaries in time were quite short: measured in days for the booking, and then a matter of hours for the preparation for the meal and the service-delivery of the meal itself. Yet from the customers’ side, the effective start-point of the service was when my parents first thought of doing some kind of celebration for the birthday, some weeks, or maybe months, before they first contacted the restaurant; and the effective end-point for the service still hasn’t happened yet, almost fifty years later, because we still remember the quality of service that the restaurant gave us.

And the same applies to products – even when there’s no explicit mechanism to enforce those responsibilities, such as a product-warranty.

To give a literally pain-filled example of this, consider the very real problem of unexploded munitions that still lie scattered all around the world. These are a class of product whose intended purpose for future service – if that’s the right word – is to cause damage to an intended target at an intended place and time. In military terms, that would indeed be considered a service. But what happens if the product doesn’t deliver its intended service, by exploding on target at the intended place and time?

The short-answer is that it sits around indefinitely, waiting for a suitable alternative signal to wake up and deliver its designed-in service. Or, more likely, its disservice, because it’s no longer the intended target – in fact more often not an appropriate target at all, as I’ve described in previous posts here, such as ‘Product, service and trust‘, and ‘Landmines on legs‘. Not A Good Idea…?

The reason this kind of mess happens is because there’s often an assumption that whilst services are our responsibility, the responsibilities cease as soon as there’s a transition over any kind of boundary, to a product, or to someone else’s service. We might accept that we have some responsibilities for Our Product, but none at all for Their Service.

Yet those convenient assumptions fall apart once we realise that, as described in my post ‘What is the boundary of a service?‘, every boundary we draw is a choice. One of the most immediate ways to discover this is when we shift from selling products to selling services – such as Casimir Artmann’s example above, of shifting from selling cars as products to selling the service of transport via car. The moment we put a new boundary around around that broader service, we suddenly become responsible – and liable – for everything that happens with every product that’s now inside that service-boundary:

Transition from product-orientation to service-orientation can create some, uh, interesting challenges in previously-ignored parts of the business-model. For example, when Interface Inc were selling carpet as product, it was in their commercial interest for customers to be wasteful as possible, because they would then buy more product than they actually needed. But when the company shifted over to selling carpeting as a service, suddenly it was now in their interest for their customers to be least wasteful as possible – because it was now the company, not the customer, who carried all of the costs for the waste. Which in turn meant that they now had a business need to educate their customers on how to minimise the waste. Hence, in turn, the company’s current strong emphasis on sustainability, not for some abstract reason of ‘corporate social responsibility’, but as an urgent, active business matter.

This shift can out in other ways that can be even more challenging from a business perspective. To again use Casimir’s car example, look at what happens when we start to sell self-driving cars as a service: our organisation suddenly acquires legal liability for most things that ordinary drivers could do wrong. Parking fine? Speeding ticket? Collision? Injury? Death? That’s not the driver’s liability any more – because if we’re providing the service of driving, we’re now the driver. It’s at this point that that otherwise so-convenient fiction of ‘corporate person’ can take on a rather different edge, when people start to ask serious questions about whether the company itself should go to jail for dangerous-driving and the like…

The same also applies with service-to-service boundaries – of which the classic is outsourcing. Outsourcing always seems so much easier than insourcing: less to manage, lower cost (we hope), and we’ve outsourced all of the responsibilities too. But as I noted in the post ‘Boundary of identity, boundary of control‘, what we’ve actually done in outsourcing is that we’ve placed the outsourced activities outside of our control, but they’re still inside our ‘boundary of identity’ – what others see and experience as ‘us’:

Which means that whilst we might believe that our responsibilities end at the parts that we alone provide – our boundary of control – our customers and others won’t see it that way. From their perspective, our organisation’s responsibilities extend at the least to our boundary of identity, and often beyond – and they’d be right to think that, too. If the organisation doesn’t manage that boundary-issue well, it can lead to all manner of seemingly-‘unpredictable’ problems for the organisation – such as in a first-hand example of a clash with a clueless outsourced-service security guard in a supermarket, described in my post ‘The cyclist-shopper’s tale‘, that cost that company many, many thousands of pounds in lost sales and lost reputation.

Again, the key clue here is that every boundary we draw is in part of choice: and as explained in my post ‘More on boundary of identity versus purpose‘, we’re not the only ones who can draw those boundaries. And responsibilities follow along those boundaries, too – especially on any boundaries that set up distinctions between ‘service’ and ‘product’. Yet whilst we might set up specific boundaries to partition the responsibilities in ways that seem more favourable to us, anyone else can challenge those boundaries. Whether it’s our customers or suppliers, the regulators and lawmakers, or lawyers a’plenty, they can all declare our boundaries different to what we might think they are – and shift the respective responsibilities back onto us, whether we like it or not. Ouch…

So no, these issues are not trivial at all; and nor are they either abstract or ‘academic’, for they can be incredibly expensive – in many, many different senses of ‘expensive’ – for any organisation that fails to get it right. Understanding how those boundaries work, and how those distinctions between ‘service’ and ‘product’ are largely artefacts or outcomes of the boundaries themselves: those are crucially important for enterprise-architecture, business-architecture, service- or product-design, and much more besides.

For the final post in this series, we’ll summarise everything we’ve explored here into a simple checklist that can be used whenever we need to assess anything about how we work with products or services. More on that in the next post: in the meantime, though, over to you for any comments or questions you might have so far on this?