Service, product, service – everything for hire?

Are goods and services ‘products’ because they can be hired? Is ‘product’ a term that applies only to a commercial context?

I’d intended that the next post in this series on the relationship between product and service would be about transfers of responsibility in a service/product chain. But the previous post in the series, ‘Service, product, service – implications for architectures‘, triggered off a veritable storm on LinkedIn – several thousand views, and more than a hundred comments. Some of the conversations there – particularly those with Nick Malik, Jan van Bon, Kevin Smith and Jordan Julien – seem worth preserving in more permanent form, because they do help to clarify and resolve some of the confusions that can arise. So I’m doing 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; some questions from Jan van Bon on service-structure; and then, from Kevin Smith, further questions on the relationships between product and service:

This final post in the side-thread starts from a comment from Jordan Julien, setting out a business-oriented perspective on products and service that I’d not come across before:

Products are hired by users. Goods and services are usually products because they can be hired; it’s rare to encounter a good or service that can’t be hired.

I can hire a coffee mug to help me drink coffee, I can hire coffee to help me feel more alert, I can hire a cafe to save me the time required to make a coffee. Conversely, products can also be fired. If my coffee mug is too small I’ll hire a different mug competing for my business. If my coffee isn’t waking me up, I’ll switch to a coffee or maybe an energy drink. If my cafe doesn’t offer good service, I’ll find a different cafe.

Enterprises don’t create products and/or services, they create products that can either be a good, service or hybrid. A mug is a good, a cafe is a service, a website is a hybrid – but they’re all products because they can all be hired.

Sort-of agreed for a business-oriented perspective, though it tends to break down once we start to apply those definitions for detail-level descriptions of services (such as protocol-level services in an IT operating-system), and will definitely break down if we try to apply them for non-commercial contexts such as biochemistry interactions in the internal whole-of-context services in a forest ecosystem.

I’d have to say that, to me, that definition of ‘product’ as ‘something that can be hired’ is a bit odd, to say the least. Sure, it applies to some if not many products, though not all: for instance, that example of “I can hire coffee to help me feel more alert” is a usage of ‘hire’ that I’ve never heard in any business-context, let alone anywhere else. That definition would be specific to only a certain subset even of a commercial context (e.g. lease versus outright-sale), and a commercial context itself is a subset of what’s usually considered to be the overall scope of services. In that sense, we’d risk trying to apply to the whole a definition that’s relevant only to a subset-of-a-subset – which may not be a wise move.

Jordan didn’t agree:

Except I said the definition applies to a product, and services aren’t always products (as you point out). And I think the definition holds true for most “commercial” scenarios; not a subset of a subset. Users hire a product to do a job, regardless of how they pay for it. Sale v lease has nothing to do with whether a user can hire a product or not. I guess we’re just in two different industries because I’ve rarely heard anyone refer to IT services or ecosystem services as a product. Products are almost always referenced in a “commercial” context. Oh well, agree to disagree. Always value your POV though.

On “…and services aren’t always products (as you point out)”, the short-answer is no, that’s actually almost the exact opposite of what I’d said.

What I did say was that what we see as ‘service’ or ‘product’ are, in reality, arbitrary views into/of what is actually a broader ‘thing’ of value-creation or value-change. When we see this ‘thing’ in action, we call it a service; when we see this thing in stasis, we call it a product; but in both cases it’s still the same thing. Which also indicates that this whatever-it-is thing is not only product and service, but also neither product nor service.

The exact analogy is that question about whether light is waves (dynamic) or particles (static): the factual answer turns out to be ‘Yes, therefore No’. In physics we resolve that paradox with the concept of the quantum; we don’t yet seem to have a term for the equivalent service-and-product-and-whatever thing.

A product presents as a subset of service because key elements get ‘frozen’: for example, by definition, there can be no service-relevant Events when it’s in stasis. Why this matters for service- or product-design is that there are huge implications around responsibility, liability and suchlike, that are often hidden or ignored but can come back to bite big-time in the longer term. (More on that in the next post in the main part of this series.)

On “Products are almost always referenced in a ‘commercial’ context”, I can’t agree with that assertion. ‘Product’ occurs in many other types of contexts: in coding, as the product of a function, for example, or the product of an equation in mathematics. In a more social context, we might talk about the product of a mistake; or increased satisfaction as the product of some intervention. If we arbitrarily narrow the discussion down to commercial contexts only, then yes, it would possibly be true to assert that “In a commercial context, a product [as a static ‘thing’ pushed out from a service] is almost always referenced as a Product of a commercial context” – but that’s essentially a tautology, and doesn’t really tell us anything useful. What is useful is to understand that as soon as we draw a boundary around a service, and hence create gap between that service and other services, there will need to be a static ‘something’ that exists to bridge across that gap: and the common term for that ‘something’ – whatever the context – is ‘product’.


The above completes my replies to those four sets of comments, from Nick Malik, Jan van Bon, Kevin Smith, and Jordan Julien – and thanks again to all of those for engaging with me on this.

One other note I ought to add, about comments in general to that (still-ongoing) series of posts: it’s been striking, and more than a bit disappointing, to see how often people came back with responses that did not engage with any of the questions that I’d posed. The common of these was to present a list of arbitrary definitions about service or product that came from a single domain (usually ‘the business’), and that explicitly assumed that service and product are fundamentally different – when the whole point of this series was to explore the possibility that they’re not. Again, it does indeed seem that Nick Malik is right in suggesting that this is still a ‘novel concept’ for most people: yet even if so, then given that these are people whose work supposedly focusses on innovation and the like, it’s more than a bit disappointing, to say the least. Oh well…

My fault, of course: if I’ve failed to communicate, then ultimately that failure is my mine, not that of others. I just hope I can do better with the rest of this series.

Anyway, it’s time to end this side-series and return to the main theme, with the next post on practical implications about boundaries and responsibility – or, all too often, evasions of responsibility. Onward!

2 Comments on “Service, product, service – everything for hire?

Leave a Reply

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

*