Product and service
What’s the difference between product and service? And in what ways does that difference affect the various aspects of enterprise-architectures?
This question came up as a follow-on to an unusually-good LinkedIn discussion, started on The Enterprise Architecture Network list by Michael Clarkson, on the question “What’s the difference between a business capability, a business function, a business process and a service?”
I gave my usual answers:
- capability: the ability or potential to do something
- function: an interface through which capability may be accessed to do something
- service: the delivery of something that is ‘of service’, in accordance with a service-contract, service-level agreement or some equivalent quality-promise
- process: an aggregation that links services together, in sequence and/or in parallel, in structured and/or unstructured form, to deliver a composite-service
Some people liked that, some people didn’t – which is fine, of course. But whilst we were still on the original questions of definitions, the conversation drifted briefly onto product versus service, and then drifted away again, without any conclusion. So it seems worthwhile bringing a bit of focus back onto that question, because it has a lot of implications in enterprise-architectures.
The two terms – product and service – are often posed as opposites, but there’s a lot of confusion about which is which, and what each of them actually is. Which to me is not surprising, because, the way I understand them, product and service are actually the same. Product and service are not inherently different: the apparent difference is much more about how we choose to see them, rather than an attribute of the entity itself.
Probably the closest analogy is with how we use our understanding of light. One of the more obvious questions would be “Does light consist of waves or particles?” But it’s not as simple a question as it sounds, because there’s what’s known as the wave-particle duality. JJ Thompson won the Nobel Prize in 1906 for proving that light is particles; yet somewhat bizarrely, his son Walter Paget Thompson won the same prize in 1937 for proving that the particles are also waves. Hence the short answer is ‘Both, therefore neither’. Which is kinda awkward…
Light is waves and particles – at the same time. The usual way to describe this is that if we regard light as a particle, we can tell where it is, but not where it’s going; as a wave, we can tell where it’s going, but not where it is. The catch, though, is that the two views are ultimately incompatible with each other, because a wave consisting of just one particle cannot make sense. Yet it also doesn’t make sense to ask which view is true, because both are true – sort-of. The key point, though, is that the different views allow us to do different things: if we describe light as particles (photons), we can explain photoelectricity and suchlike; if we describe light as waves, we can explain phenomena such as refraction and transparency. In other words, it can be useful to choose one view or the other, even though in a strict technical sense neither is ‘true’.
Both views are sort-of true, and sort-of not-true. But they can both be useful, as long as we remember that each view represents a way that we’ve chosen to understand the behaviour of light – and not that it defines what light is.
So too with product versus service. We can summarise them in much the same way as particle versus wave:
- product: particle-like, static, a ‘thing’, represents ‘potential’ rather than ‘actual’
- service: wave-like, active, dynamic, in the midst of change, ‘potential-realised’
Hence, for example, an insurance product represents potential for service, a promise of service if and when needed at some future time.
We can also note that:
- product aligns with asset, in the sense that it tends to be static, in-potential, ‘thing’-like
- service aligns with process, in the sense that (as above), process is active, a compound-action, often changing one or more products over time
And there’s another important distinction, around responsibility:
- most responsibilities for a product, and the future, current or past use of that product, reside with and are transferred to the current holder of the product
- responsibilities for a service are shared between all parties involved in the service, especially those involved in the active realisation of that service
Being cynical, we could suggest that this is one reason why banks and insurers have been so keen to rebadge most of their services as ‘products’…
We could also note that service is sometimes provided in ‘product-like’ form – as something that happens without active engagement of the end-recipient of the service – such as is to often the case with cleaning-services, for example. In those cases, responsibility is often reinterpreted more in the sense of ‘exclusive other-blame’ – the owner of the place being cleaned claims the purported ‘right‘ to blame the cleaners for poor service, regardless of the owners’ responsibilities to make the service-delivery possible. In that context, it might be more accurate to use the term servitude rather than service… 🙁
Implications for enterprise-architecture
In essence, ‘product’ and ‘service’ are different views into the same entity: the creation and delivery (potential and/or actual) of value, usually associated with some form of asset – in turn typically as associated with some notion of ‘value-proposition‘.
Product in effect represents a ‘proto-service’ – the potentiality to deliver service.
A ‘product’ orientation will often seem ‘easier’ to work with, in part because it’s sometimes possible for the ‘producer’ to (attempt to) ignore responsibility in terms of relationships or of use of the product itself. The absence of responsibility for final service-delivery also translates to some relinquishing of ‘control’ – which, interestingly, can sometimes enable a much broader range of affordances.
A ‘service’ orientation builds engagement and commitment, through the requirement for co-creation of the end-result.
Allowing services to to be interpreted through a ‘servitude’ view is really bad news for everyone involved, especially over the longer term: it’s extremely important to construct service-structures and service-delivery in such a way as to prevent or dissuade any fallback to ‘servitude’.
In my own architecture work, I use the view that everything in the enterprise is or represents a service. This makes practical sense because the way in which products can be interpreted as proto-services. It’s important to note, though, that it’s merely a convenience to help in creating consistency across the architecture: think of ‘everything is a service’ as an ‘as-if true’, not ‘is true’.
For most purposes, it doesn’t make practical sense to do it the other way round – to attempt to structure an architecture around a notion of ‘everything in the enterprise is or represents a product’. If we do so, we lose the ability to describe process-flows or any of the dynamics of interaction across the enterprise.
Tom
Thanks for the insights into seeing product and service as two different perspectives of the same dynamic.
I had not seen it this way, and I am not sure that I am “fully convinced” yet! So, here is some push-back, testing and/or an alternative perspective on this dimension of enterprise modeling (I prefer that term – architecture is not the appropriate term given the ecosystem perspectives that bring added value to our sort of work).
Firstly, I couch my perspective in the context of considering product and perspective from an external customer perspective, leaving internal considerations for later.
If we consider how a customer uses a product versus a service, I think we see a number of different dimensions. For a product (eg the pencil that I purchase), it is a one-time transaction. I engage with a variety of enterprises offering products to suit my needs, and select one on the basis of my evaluation, quality, price, etc.
When I purchase a service, as you have indicated, there is a greater degree of engagement over a varying degree of time, depending on the nature of the service. This engagement is likely to prompt a series of interactions, each of which could be considered as a sub-product within a broader service interaction / value chain and would be reflected in a process model which takes account of customer responses to sub-products such that the service journey varies and is just as much customer selected as provider determined.
So, I can see my way through this in terms of both a product or service perspective. The end result of the service engagement will be that the client or client environment is in a changed state as a result of the service interaction. It entails, in my mind, a combination of attention to product, process and service.
Equally, I can see how a product could be seen as a service – an example would be seeing the purchase of a car as being the participant in a car design / configuration service where the result is a car (product) that more readily meets my needs and requirements.
To me, therefore, there is value in appreciating the nature of the output as it will require me to attend to business capabilities in different ways. I am not sure that seeing a product as a service improves the quality of my EA work or whether it just makes it seem simpler?
Appreciate further insights and perspectives you have to offer in light of this “view of the EA world”.
Peter – many thanks – and I would be worried if you were ‘fully convinced’! 🙂 Much of this is, of necessity, still very exploratory, and what you’ve written above is a very necessary and very useful critique and reflection on that.
One of the points I see that comes up from what you’ve said is that the common notion that there is a single ‘the product’ or ‘the service’ is very misleading. In practice there’s a lot of layering, with products containing products containing services containing products containing other services, and so on. And we do see a lot of that layering or recursion in explicit form in some types of business – particularly telecoms, banking and insurance. Hence trying to describe things in terms of explicit distinctions between products versus services will tend to get horribly tangled…
Hence what I find more useful is to focus more on the value-exchange and/or value-creation (and for whom and by whom that value is created, and in what sense of ‘value’, for example). ‘Service’ and ‘product’ are then just ways of interpreting or seeing some aspect(s) of that value-exchange – a kind of encapsulation or snapshot in time, with ‘product’ more static than ‘service’, but both still only a slice or subset of the whole.
Dunno if that makes sense? – and yes, I’ll admit that a lot of this is still ‘a work in progress’, hence many thanks again for your help in progressing this further.
From my simple consumer point of view: the product is something I want to use and the service is something I have to use (often at inconvenient times).
E.g. when I choose to buy something new I’m feeling happy. But when it breaks I’m feeling sad/angry. So my state of mind is very different when I’ve to deal with a business or enterprise.
I think it is relative easy to design a good product but very hard or even impossible to design a good service…
Peter B: good point about “service is something I have to use (often at inconvenient times)” – though in a sense that also reinforces my comment about ‘product as proto-service’, a component for self-delivery of service at some other (more-convenient?) time.
Likewise good point about ‘state of mind’ – hence why marketing makes it (relatively) easy to sell product, but not so easy to sell service.
Which seques nicely into your last point about “I think it is relative easy to design a good product but very hard or even impossible to design a good service”. Yet if we take the view that ‘everything is a service’, what that does is force us to surface the real underlying issues that we were able to avoid when we viewed it only as product, perhaps? 🙂
Like the Peters, I’m not entirely convinced either. Are you not adopting an enterprise-centric view here? They are very different from a customer perspective. If a company goes out of business or the customer dies a product remains, but a service disappears. Think CDs versus iTunes libraries, for example.
@Sally: “Are you not adopting an enterprise-centric view here?”
Uh… possibly, yes… (shuffles feet in embarrassment…)
(Assuming that by ‘the enterprise’ you mean ‘the company’ or product/service provider (i.e. the client of EA) rather than ‘extended-enterprise’ (the context-space in which the company, the customer and all other stakeholders interact?))
You’re right, there are some very significant implications depending on whose view we choose – especially over time. I’d still suggest that it’s best to see all of these as views into what is in essence the same value-entity, rather than treating them as separate things.
Something we definitely need to discuss more, though – many thanks for bringing it up, and perhaps help me with it a bit more somewhen?
Some thoughts:
First is that it doesn’t appear to be much of a stretch to realize that, if nothing else, the provisioning of the product is a service.
Second, between warranties and general litigiousness, I’m not sure there’s as much responsibility transferred to the product purchaser.
Third is that some of the comments assume a more long-lasting nature to products than may be the case (e.g. fresh produce from a grocery store). There also seems to be an assumption of a more transient nature to the relationship than may be the case (e.g. warranty service for vehicles). Both aspects seem to be ranges rather than boolean values.
Thanks, Gene –
“the provisioning of the product is a service”
Yep – and that’s how e.g. eTOM/Frameworx describes it, too.
And likewise the provisioning of a service typically involves/requires products, or the use of products. It’s wildly recursive etc: we can go a long way down the rabbit-hole if we’re not careful here! 🙂
“I’m not sure there’s as much responsibility transferred to the product purchaser”
I meant responsibility in the sense of ‘ability to respond’ – in other words, make choices as to how the entity is used in the present and/or future.
The other meaning – responsibility in the sense of blame, after the event, such as represented in “litigiousness” etc – well, yeah, that’s another whole ball-game, ain’t it? 😐 (Though one we do need to consider, in our roles as enterprise-architects, business-architects, service/product-designers etc.)
“more long-lasting nature… Both aspects seem to be ranges rather than boolean values.”
Yes, definitely. (Hence yet more themes to add to the now rapidly-growing pile of additional questions brought up from this concept of ‘product and service as views into the same value-entity’! 🙂 )
For some people the difference is simply that a product is tangible (a good) and a service is not.
For the TeleManagement Forum in their Information Framework (formerly SID) the distinction is rather commercial. A product is a thing which has been sold and consists of one or more services, which themselves can consist of both physical and virtual “resources”. The services are what is delivered and are in general continuous rather than one off. Where you regard product as a proto-service, they talk about product offerings, of which a product is an instance.
The point of the above story is not that any version is correct but rather that there are other, well structured sets of relationships defined between objects with these names and that the challenge for the enterprise architect is often ensuring that we can convey the same meaning across multiple taxonomies. As it happens, product and service are the ones where I’ve most often been confronted with incomprehension – willful or otherwise.
Does that make any sense?
Stuart: eTOM/SID and telecoms is where I started with a lot of this, perhaps a bit more than a decade ago, so I do have some understanding of what you mean about the detail there! 🙂
What’s interesting is that, much as with insurance, most telecom ‘products’ aren’t tangible either – they’re bundles of non-tangible telecom-services. It gets real tangled there real quick if we try to hold rigid separation between ‘product’ and ‘service’: a lot easier, architecturally-speaking – as well as in general sanity-maintenance – if we use this idea that ‘product’ and ‘service’ are somewhat arbitrary views into value-provision or ‘value-space’.
“The point of the above story is not that any version is correct but rather that there are other, well structured sets of relationships defined between objects with these names and that the challenge for the enterprise architect is often ensuring that we can convey the same meaning across multiple taxonomies.”
Yes, exactly. It’s not the case that either or neither of ‘product’ versus ‘service’ is ‘correct‘ as such: it’s a choice, a ‘way of seeing’. Which means that there’s real work to do to surface all the assumptions and hidden-choices that people hold about ‘product’ versus ‘service’ and ‘value’ (or, for that matter, ‘price’ and all that related mess). Which is a very valuable role for architects and the like. Much as I said some while back about process, the process of identifying the meaning of terms is itself part of the overall process (and service, and product) of identifying value.
The top half of the above comment got lost. It was just saying that the important part of your post is the story that you told to explain your use of the terms, rather than the question of whether the usage was the only correct one.
Stuart: yep, agreed. And as you say, the ‘storying’ is important: using story (and analogy, and metaphor, and so on) to explain the meaning(s) of the terms is a crucial part of the sensemaking and decision-making for ‘product’ and ‘service’.
Further reflection on what distinctions exist or are being made when considering product or service as an output of an enterprise has led me to the following considerations.
If one views an enterprise as a black box that transforms inputs to outputs, the differences that I see between a product and service (at least in the way I use the terms and observe others doing similarly) is that:
For a product, the enterprise transforms inputs to outputs, the enterprise has ownership and responsibility for the product and the product quality, the purchase of the product results in a transfer of ownership of the product from supplier to customer, and the customer (largely) has no direct input to the product and therefore is not a “supplier” of inputs to the enterprise.
For a service, the enterprise transforms a customer owned or controlled asset from one state to another, the enterprise does not own the object(s) being transformed, no transfer of ownership occurs, and the customer is both customer and one of the suppliers. With the progression of co-creation, co-development, etc, the customer is becoming more intimately involved in the process of transformation, and customer inputs during the course of the transformation process may change the ultimate output and nature of the transformation.
Does that make sense? Is there something at the heart of this that is distinctly different? Or is it just two different perspectives on what is essentially the same thing (as per Tom’s comparison with light as particle and/or wave)?
Peter: thanks for this – good points all.
From your description I’d still continue to maintain that the ‘product and service are views into value’ notion still holds. The catch is that we can go a long way down the rabbit-hole if we’re not careful: the ‘Just Enough Detail’ rule should still prevail here.
For example, the shift in the aero-engine industry from selling engines (and service-contracts on the side) to a full service-based model (hours of in-flight thrust) straddles kind of halfway between your descriptions of ‘product’ and ‘service’. The engine-manufacturer owns the engines, but the aircraft-operator owns the airframe on which the engines are mounted, and neither makes sense – is capable of delivering a complete usable service – on its own. From the perspective of the end-customer for the aircraft-operator – the passenger or freight-forwarder, the service that they receive should be the same, whichever model applies for the aero-engine/operator relationship. And so on, and so on – all manner of different business-models and business-relationships interweaving with and interdependent on each other. Tricky, sometimes… but that’s our job to make sense of it, isn’t it? 🙂
Tom said: “Tricky, sometimes… but that’s our job to make sense of it, isn’t it?”
It is our job to help our audience to make sense of it and as I said before: I never used much more than three simple mapping concepts and feedback from my audience to achieve that 🙂
One of my most embarrassing moments… 🙂
I “failed”* to solve the Monk and the Mountain problem at http://bredemeyer.com/RequisiteVariety/?p=154 because I decided not to use my basic point, line and area concepts.
*I had the right answer but it was not the most simple/obvious solution
I had a go at the same problem too. At first glance it looked easy and obvious: by definition the two paths must intersect somewhere, regardless of any variations in speed of travel. But then I read it again, and noticed the other requirement about “at the same of day” – and suddenly it wasn’t so obvious at all. To be honest, I haven’t found a solution yet – by any means, graphic or otherwise. Oh well. 🙁 🙂
Just came across the various discussions there – very interesting indeed. Small hint for the monk problem: just operate a time translation to align the two departures, and you’ll see that they will undoubtedly bump into each other at some point…
Tom said: “In my own architecture work, I use the view that everything in the enterprise is or represents a service. ”
In my my architecture & mapping work I use the view that everything is a point, a line or an area and I never have discussions in my daily work with my audience or fellow architects about definitions 🙂
The biggest advantage is that I make it very easy for my audience to counter-map my map which leads to better insights (and more empathy between the different stakeholders).
@Peter: “I use the view that everything is a point, a line or an area”
So you never discuss product, or service, or capability, or anything like that? And your clients etc never bring those terms up with you, or ever need to clarify between them what each of them mean?
I know your work with mapping is interesting and important, yet I’ll admit I’m puzzled by what you’ve said above. I don’t see how you can get to a usable, implementable design without ever defining terms… Explain more, please? (Perhaps best in your own blog-post, so that others can see it, rather than buried away down here?
Hi Tom,
The explanation is the subject of my book-in-slow progress 🙂
I do discuss all kind of things with my audiences and I listen to them when they discuss things or counter-map things I show. But still the bottom-line is that I only need a few basic mapping concepts. You can compare it with drawing: if you can draw 4 simple shapes you can draw almost anything*. And people will discuss about the drawing (or the purpose of the drawing) but never discuss about the used 4 basic drawing concepts.
(I hope this make some sense for now)
* e.g. see the sphere, cylinder, cone and cube example on http://www.painters-online.co.uk/Features/Top-tips-for-learning-to-draw-with-Linda-Birch/_ft278_cat4_tp59_mg12
Peter B: yes, nice (and reminds me of the too-many years I spent at art-college and still never really learnt how to draw! 🙁 ) – yet how do you link from there to the concrete detail needed for design and implementation? Or do you solely act as a visual-facilitator, and get everyone else to sort it out between themselves? There’s something I’m missing there in your explanation, and I don’t quite know what it is…
Tom, I think it is ok to call me a participating visual-facilitator who wants to create a broadly supported, polder-modeled, design.
I’ve done a good job if everybody thinks that they have sorted it out by themselves 🙂
The question about Product vs Service definition is really interesting, and I really appreciate the analogy to light =)..
These definitions has been causing trouble within every organization I have been working in. To me, a lot of the misunderstandings is because of lack of insight/knowledge in (what I assume is) the fundamental definition used by academic authorities/bodies, and mentioned in several literature and whitepapers; Product = a Good or Service or a combination of both.
Was this intentionally excluded/included in some other points in this discussion? Or just too obvious? 🙂
@Andreas: “Product = a Good or Service or a combination of both. Was this intentionally excluded/included in some other points in this discussion? Or just too obvious?”
Uh… (raises his hand with guilty expression) – it’s probably because of my “lack of insight/knowledge [about] the fundamental definition used by academic authorities/bodies”?
If you really need an excuse from Mr Missed-It here 🙂 , reality is that I have a useful but (I will admit) occasionally bad habit of always going back to first-principles, and working things out for myself from there. From long and often painful study and experience, I’ve learnt to become very wary of any self-styled ‘academic authorities’, because they’re often so busy quoting each other that they never get round to looking at the real world. (The entire discipline of ‘economics’? – I rest my case…)
Hence, yes, I’ll admit that just plain forgot the old notion of ‘Goods and Services’, and the common correlation of those to tangible versus non-tangible. That’s another intersecting thread to this, another interpretation that needs to be brought to bear. I just haven’t done it yet.
Blunt fact is that (shock horror! 🙂 ) I don’t know everything, I don’t have all the right answers, and I ain’t perfect. Not by a long shot. Sorry! 🙂 I do what I can, and hope that it helps: that’s probably the best that any of us can do, I think?
Wow, lots of activity here and on LinkedIn! Turn your back for a couple of days, and look what happens!
In interests of catching up, let me first say that my own view of this topic is that, agreeing with Tom, service is the more fundamental concept. I think that what we usually call a “product” can be seen as a way of attempting to provide a service remotely in terms of time and distance.
So, a humble example: I can hire someone to break up the surface of some garden soil, and remove any weeds — clearly a service. Or, I can buy a hoe to use in providing the same service to my garden through my own efforts. Both involve my participation, in a co-production of value. I would also suggest that the hoe provides a capability, which with my effort. enables the service to be performed.
Looking at things this way makes it easier to invoke the services mindset, which starts from an understanding of the desires of the recipient of the service. Does the hoe provide the ergonomics that a person like me would be looking for? In fact, I think this is the way successful businesses generally operate, so that in the architecture of such businesses, the customer, client, user has a dominant role, and the business designs product/service offerings based on deep understanding of those desires.
In the last sentence when I said “architecture” I meant the intrinsic architecture, regardless of how that came to exist. The business/enterprise architect plays the role of understanding that intrinsic architecture, from desire to realization, reflecting this back to other people in the business through various architectural models and communications, such that the implicit is made explicit. It is helpful to maintain the service mindset, so that the architect can ask the right questions and look in the right places to understand how the business is trying to serve people’s desires through product/service configurations (deeply recursive as they may be).
People who make a good hoe, probably also make a good shovel. This is an architectural prediction 🙂
Nice example with the gardening-hoe, Doug – thanks.
Strongly agree that service-orientation – when done properly – creates a stronger engagement on both sides, and hence potentially a more committed business-relationship over the longer term. Beyond that, well, yes, there’s a lot of study and observation and experiment to see how best to tackle what happens next.
It seems to me that my conceptual separation of product and service derives from a strong dose of public sector background in procuring goods vs services. So, on that basis I am prepared to constrain my discomfort.
I do know that one of the major consulting firms works with their clients to define their key outputs and classifies them as product or service – I hope to enquire as to the rationale and value they see in doing so.
Peter: “I hope to enquire as to the rationale and value they see in [classifying outputs as product or service].”
Yes, please do – would be very interesting to hear the response. Thanks!
Further reflection on product and service, in part, prompted by your posts on value and my reflections on discussions of value proposition as they pertain to the consulting enterprise with which I am associated.
In defining our services, we have adopted a taxonomy as follows:
Service line (eg. Strategy, Planning & Architecture Services) comprises
Service offering (eg. Enteprise Architecture) comprises
Product (eg. Business Architecture)
(Interesting that we have defined a product as the base component of a service, but not my primary point)
For each product, we sought to describe the value proposition for the product. It was in doing this, that we discovered a distinction between the value proposition for the product as opposed to the value proposition for the service.
For existing, well known products – eg a business case – there was no need for a value proposition for the product – we knew that our clients understood the value of a business case ie. why they valued or needed a business case – to secure funding approval for the investment necessary to make a defined business change. But, if it was a new product or a product that a client had not used eg. business architecture, then we did need to explain why they might want this, what it was, and how they would use it.
Complementary to this, we knew we also need to convey – why us? Why was their value in engaging us over other service providers to work with them on the development of a business case or business architecture. This was about the value offered by having an external entity assist in creating the product, and the differentiators in the value that we might bring versus a competitor.
So, from this I draw the view that when engaged to deliver a business case, there is both service that we deliver and product that is created, and that there is a distinction between the two. In this case, the service has a beginning and end in time, and an evolving product (as they may well see progressive development of content) but simply a product at the end. It is, in fact, a co-designed and co-developed product – that is the nature of the service.
If, however, it has been developed internally, there would still have been an internal service, combined with a co-designed and co-developed product.
For me, the interesting element is in the difference in value proposition
– for product, the question is about how the product will be used (ie. to support a decision) and why the product is needed
– for service, the question is about the service provider and who will create / deliver / co-design and co-develop the product, and the relative merits of different service providers (internal, or external competitors)
@Peter: “service line … service … product”
Yes, useful distinctions and interesting layering – especially that point about the base-level being product. The way I’d interpret that from an ‘everything is a service’ perspective is, again, that product provides a means for someone else to deliver an end-service. It’s also a lot easier to see an product as a deliverable, because it’s something that’s typically both tangible and static, whereas services are often neither.
@Peter: “For me, the interesting element is in the difference in value proposition”
This point about value-proposition suggests I need to look into this quite a bit more – many thanks! (I think… 🙁 🙂 ) What I get from this so far is as follows:
— there are three perspectives here on value-proposition: yours (because this is work you want to do, and can do); the client’s (because it something that they [eventually?] perceive that they need); and the enterprise as a whole (because the product/service assists toward the overall shared-enterprise, greater than both you and the client)
— the value-proposition(s) also incorporate a responsibility-focus: e.g. “how the product will be used” (client-responsibility/action) versus “create / deliver / co-design / co-develop the product … relative merits” (shared responsibility/action)
As I interpret it, from what you’ve said above, ‘service’ is what you do, or together with your clients, whereas ‘product’ is where you hand over to someone else. Yet the value – and hence the value-proposition – continues onward from there: in fact the continuance and expansion of value is the whole point of doing the work.
Lots of ‘Hmm… yes…’ and interesting little insight-flashes arising from all of that – many thanks!
Another reason I tend to think in terms of product is probably because my own work always results in a “deliverable” or several deliverables – so that predisposes me to think in terms of a product not a service.
Yep, understood. The idea of ‘everything is a service’ is only a convenience, after all: if it’s not convenient, don’t use it! 🙂
Discussion on the value deriving from EA in LinkedIn drew my attention back to previous discussions with my team about the value proposition associated with our work, and to an interesting (and important) distinction between service and product.
As we discussed the value proposition associated with our work, we realised that our clients have two different questions:
a) why should we engage a consultant or this particular consultant to do this work / prepare this report
b) why should we have this report prepared
The first is the value proposition for the service being offered and is dependent on the service provider and their capabilities.
The second is the value proposition for the product. For well known products (eg a business case or a requirements document) the client typically already understands why the document is needed and what is the value of the document, but for new products that they have never used before (eg a business capability heatmap), there is need to convey the purpose, rationale and justification for investing in the product itself.
So, for business capabilities where there are people involved, there is potentially a significant difference in the sourcing considerations for the service and associated capability. Similarly for a technical product different suppliers may offer different features and value.
These aspects, however, may be more of a consideration at the project planning and execution levels, than at the program planning level – something requiring further thought!
Food for thought – I am not yet certain as to whether it has any implications for the positioning of “consider everything as a service”??
Good example, Peter, and great questions.
To your a) versus b), I’d apply that idea of ‘product as proto-service’, an item to be used for later self-delivery of service. Your a) is therefore a ‘service’, whereas your b) is a ‘proto-service’. The value-propositions in the sense that I think you mean it (I’d describe ‘value-proposition’ rather differently – see http://weblog.tetradian.com/2013/01/23/what-is-a-value-proposition/ ) therefore relate to the service to be delivered (your ‘a)’ ) versus the usefulness/relevance of the proto-service (your ‘b)’ ) in the service that will be self-delivered at some point in the future: hence the latter can only make sense in relation to the value-proposition for that future service.
Hope that makes sense?
Tom
I am afraid I haven’t got my head around “proto-service” yet! Will need to check out this concept and how to integrate it into my current mental models!
Oops – my apologies… needs a better explanation from me than just that one phrase…
The ‘everything is a service’ mantra is a tactic to make it simpler to make sense of the architecture as a unified whole: it’s a choice to view it that way, not a purported ‘the truth’. (Or, perhaps more accurately, we view the architecture as if everything is a service – which is not the same as saying that it is ‘the truth’ that everything is a service.)
Once we say that ‘everything is a service’, we then have to do a slight kludge around ‘product’. The way round it is that service is dynamic – implies an action – whereas product is static – it’s typically a ‘thing’ that sits on the shelf until someone wants to us it. Although this product may be combined with other products, which in turn could be combined into other products, and so on, ultimately, what the product is used in is the delivery of a service. In that sense, a product is a precursor to a service: it represents the potential for future delivery of a service. Hence, in that sense, a ‘proto-service’.
I’ll admit it’s a bit of kludge: I don’t pretend it’s anything more than that. But if we take the view that ‘product = proto-service’ in this way, then we can simplify the architecture right down to a fully service-oriented view.
In Enterprise Canvas, a product is either a ‘proto-service’ in this sense – in effect, a representation or encapsulation of capability – or else may be (part of) an Exchange that is passed between Service entities.
I hope that makes a bit more sense now? If not, please yell…? 🙂