Service, product, service – service as product?

Does it make sense to describe product and service as the same, or views into the same thing? For example, what if your product is a service?

The next post in this series on the relationship between product and service was going to be about transfers of responsibility in a service/product chain. But before we get there, the previous post in the series, ‘Service, product, service – implications for architectures‘, triggered off quite a storm on LinkedIn – well over 6000 views so far, and more than a hundred comments. Some of the conversations there – particularly those with Nick Malik, Jan van Bon, Kevin Smith and Jordan Julien – are definitely worth preserving in more permanent form, because they do help to clarify and resolve some of the confusions that can arise. So I’ll do a brief side-series here, focussing on each of those four comment-threads, before going on with that exploration on responsibility. I’ll edit some of my replies from there for brevity and/or clarity, but essentially the questions and responses in each case are the same as in that original LinkedIn post.

In the previous posts in this side-thread, I first responded to a comment by Nick Malik about ‘product as a bridge between services’ being a novel concept; and then some questions from Jan van Bon on service-structure. This post starts from a question by Kevin Smith:

What if your product is a service?

On LinkedIn, my reply was that the whole point of this series is that ‘product’ and ‘service’ are different views into the same thing – in which case they’re the same anyway, and the distinction is moot. (Using the definitions in this series, that is – Your Mileage May Vary with other definitions, of course.)

To put it the other way round, yes, questions such as “What if your product is a service?” do arise with other definitions for Product and Service – yet although they’re valid concerns about confusions that arise when we use those definitions, the confusions themselves arise solely because of the limitations and ambiguities inherent in those definitions. If we want to avoid those unnecessary and unhelpful confusions, we need to use the definitions described in this series.

Kevin came back with this:

If they are views into the same thing, what is the thing (u assume anything) and what are the differences between the two views?

Short-answer on the ‘thing’ is that it’s a kind of quantum-like serviceproductservice, encompassing everything in this graphic, and more, as views into ‘value-change’ space:

On “what are the differences between the two views?” – that, along with more detail about the ‘thing’, is what’s described in the previous post in the main part of this series: ‘Service, product, service, simplified‘.

However, Kevin’s next comment that that still wasn’t clear:

Can u just give a simple definition? If we want to talk to management and they ask what is the difference, what answer would you give?

Fair enough – so I made another attempt to simplify this right down to a management-type level:

• 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.

There are (a lot of) further nuances, but that’s basically it.

I then asked Kevin if this was simple enough. His reply:

Yep. Enterprises produce products and/or services. But most people know that already. What point that you are making, am I missing?

What’s missing is that ‘product’ and ‘service’ are the same thing. That’s what makes this whole issue simpler.

At present product and service are most often treated as entirely different things, which adds huge complications to the methods we use to work on/with them – especially when products are usually embedded in services, and ‘services-in-stasis’ are often embedded in products.

Kevin’s next response was this:

Yep. Enterprises produce products and/or services. But most people know that already. What point other than that are making?

I am not trying to be annoying but I don’t think that essentially telling me what the difference is between a produce and a service is, is the point you are making because thats is so simple and I know if you say something is likely to be a lot more than simple. Hence Im digging.

I’m not saying that what you are saying is wrong, I am just trying to understand what you are saying (which I don’t believe is “a product and a service are different”…

He’s right, it isn’t the simplistic “a product and a service are different”. And he’s also right in that, if anyone is asking this kind of question, it’d be clear that I still hadn’t explained it in simple-enough form. Which would be my fault, not theirs… So, another try:

• What’s going on here is our means for making changes in (perceived) value. That’s done by what we call ‘services’ (see the definitions in my response to Jan van Bon elsewhere in this thread). A ‘process’ is any sequence of service-invocations to change value.
• In those definitions, a service is active, whereas a ‘product’ is static (hence the wave vs particle analogy). For a product to be static, it must be outside of any action – hence we must always perceive a product as being outside of any current service activity, and hence must in turn draw (arbitrary) boundaries to distinguish between ‘active’ (service) and ‘not-active’ (product).
• Because nothing is happening to a product whilst we see it as a product, a product is therefore a subset of service – no Events, for example, nor any Decisions.
• Although product is only a subset of a service (an Asset element, though some other elements of service such as Location and Capability may also apply), it’s different from service only in that a) nothing is happening and b) some elements are not in use. In that sense, it’s still sort-of ‘the same as’ service: it’s just a snapshot-view of a subset of a (usually broader-scope) service, not something that inherently different as such from service.
• Conversely, a ‘service’ that’s not in use is actually a product. For example, an app is a product of the process of software-development – it only delivers its services when it’s in use. So 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. We can sell it in either mode: the only difference is whether we sell it as potential for (use in) action (‘product’) or as action (‘service’).

There’s another whole mess of implications for product vs service that revolve around responsibility (or the evasion thereof…), but I’ll tackle those in the next post in the series.

Kevin said that that summary above was starting to make sense, but he still had further queries:

OK – mists are clearing a little. So how and who do we apply that? What are you advocating should be done, and who are you advocating should do it?

On “how and who do we apply that?”, my understanding at present is that we need to emphasise the overall value-web, rather than over-focus on any individual snapshot or stage as a ‘product’ or ‘service’.

What I’m advocating should be done is that in education on product- or service-design, we need to emphasise the importance of the overall context (value-web), the dependencies of each individual product or service on the entirety of that value-web, and responsibilities of each player within the value web for the viability of that value-web as a whole (not solely their own arbitrarily-bounded part).

On “who should do it?”, I’m doing my bit with posts like the one linked here, and responding to comments in this thread. In parallel, I’m working on other training-materials, videos and suchlike. I’ll also gladly engage in broader education efforts, if anyone else wants to be involved in this.

More broadly, I believe that it’s everyone’s responsibility to make this work. Again, I’ll gladly engage with others who want to make this happen.

Kevin then brought this back to enterprise architecture and design:

So what you are essentially advocating is bringing the tool and perspective of architecture to the design of the products and services an Enterprise produces (which is part of the business model)?

Short-answer: Yes.

Slightly longer answer: apply the same thinking not just to business-model and suchlike, but at every scale – right down into the detail-level of operations (e.g. ‘microservices’ and so on), and all the way up to the respective market as a whole, and more.

I’d emphasise that as a means to make sense of an organisation’s business-models and operations, I view this only as a way to do so, not ‘The Way’. If it’s useful, use it; if not, don’t. The nice thing about this approach, though, is that it makes everything a heck of a lot simpler: the core of it is always the same, everywhere, so the complications arise only in the local fine-detail for any given context.