Service, product, service – a novel concept?
Blog: Tom Graves / Tetradian
Service and product as different views into the same space – is that a novel concept? If so, what does that imply for enterprise-architecture and the like?
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 – and I promise that I will get back to that as soon as I can! But the previous post in the series, ‘Service, product, service – implications for architectures‘, triggered off such 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 the original LinkedIn post linked above.
We’ll start with two important points from Nick Malik, the first which was laid out as a kind of book-end at each end of his comment:
“I found the idea intriguing that a product is a bridge from one service to another. … Your recognition of the product as a connector of one service to another is novel.”
I’ll admit that his description of that as ‘novel’ was a bit of a shock for me, because it implies there’s a crucially important point that I’d missed. I’d always thought of “product as a connector of one service to another” as obvious and self-evident – as in this nearly-decade-old diagram of mine that I’d referenced in my post:
But if Nick is right – and a lot of the comments on LinkedIn and elsewhere now do seem to suggest that he is – then my failure to realise that it wasn’t obvious was a huge mistake for me to make. From what Nick was saying there, I need to go back and do a full step-by-step reasoning on that part first – otherwise much of what I’ve been describing about the implications of the linkage would perhaps never make sense to others. Oops… If anyone has any suggestions as to a best way to do that step-by-step, please let me know?
Nick’s other point – or rather, my response to it – may take a bit more explaining. This part of his comment (which I’ve shortened a bit here) was:
The iPod changed all that [mess of MP3 players and loader-apps] with iTunes. Because the iPod had a service at one end.
Now we have iTunes and the iPhone and we can put a service at the other end as well, with our apps. We no longer think of the iPhone as a product. It’s part of the service of connected voice/video/internet/community.
In terms of what I was saying in the post, this isn’t quite correct – or rather, it depends where we choose to draw the boundaries. If we draw the boundary as “the service of connected voice/video/internet/community”, then yes, the iPod or iPhone would be seen as part of that service. But if we look at the iPhone itself, it’s a product: a static container for services. And the apps on that iPhone are products too – and sold as such, as well. It’s only when the app is in use that it becomes an active container for services. The services run through the product that is the app and, as a container, the iPhone. Even the data that pass into and out of the app and action the services are themselves products – literally, ‘that which is produced’, and then consumed, in a service. But whenever we draw a service-boundary, we render invisible any products within it – they would be seen merely as ‘part of the service’. Which is why an iPhone seems to be just part of “the service of connected voice/video/internet/community” – but to make sense of what’s really going on, we also need to understand it as a product in its own right.
Product is service is product is service… It’s tricky…
That’s why I’d argue that the only way we can make sense of this is 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 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.
To be blunt, we need to be a bit more honest about those boundaries, and how we choose to draw them… But that’s the topic for the next post in the main part of this series: for now, back to those comments on that previous post, with a sub-thread on the structure of a service.
Comments (1)
Leave a Comment
You must be logged in to post a comment.
Tom,
you’re still standing with one foot in the Goods-Dominant logic. We’re living the service age now. Forget about the presumed distinction between service and product. That’s old thinking. If the service IS the product (which is obviously has become for all organizations), you should focus on the nature of that service and how it is exchanged. Once that is clear, your ability to walk the depth of architecture can contribute to coherent system approach to services. But first please get rid of the old product paradigm.
Cheers,
Jan van Bon,
chair SURVUZ Foundation