Service, product, service – start with product

If service and product are different views into a continuous sequence of value-creation, what can we learn if we start the sequence from product rather than service?

In the earlier parts of this series – such as ‘Service, product, service, simplified‘, ‘Service, product, service – implications for architectures‘ and ‘Service, product, service – responsibilities‘ – I’d always taken a service-oriented perspective. In practice, though, many people would prefer to start from a focus on product. So let’s do that here.

A quick recap of the themes in this series:

• Service and product are not fundamentally different, but instead are merely different ways to take a snapshot-view into some part of a continuous process of value-creation.
• If our snapshot focusses on some set of activities over some period of time, we would describe it as a service; if the snapshot is of the statue or status of value-creation at a single frozen moment, we would describe it as a product.
• For products, the key criterion is where we draw the service-boundary: a product is identifiable as ‘product’ only if it is outside of any respective service-boundary. (When inside a service-boundary, it is merely another asset that’s currently in use by the respective service.)
• Wherever a gap or transition occurs between any two services – a change in location, responsibility, delay and suchlike – then at least one product must exist to act as a bridge to provide continuity across that transition or gap.
• When viewed in active form as a service, that segment of value-creation must include all of the elements of service-content – assets, functions, locations, capabilities, events and decisions.
• When viewed in static form as a product, that segment of value-creation can include only assets, though in any combination of asset-dimensions (physical ‘thing’, virtual data, person-to-person relation, and/or person-to-abstract such as purpose or brand).
• Fractality applies: services may ‘contain’ other services and/or products (as ‘assets’ or ‘resources’); products may contain other products and/or services (the latter in temporarily-‘frozen’ form).
• In short, the only key distinction between ‘service’ and ‘product’ relates to how and where we choose to draw the respective service-boundaries.

So far, I’ve always shown the chain of views as starting from a service:

Or, optionally, looking inside a service that has a broader scope (otherwise known as a ‘white-box’ view of that service):

Yet in principle it’s just a chain of views, so there’s no reason why we can’t start the same chain from a product instead:

However, there are disadvantages of doing so. The first of these is that whilst we always know the parent-service for a product, we don’t necessarily know the service in which a given product will be used. The only time when we can have some degree of certainty on this is when we draw a service-boundary broader than the scope of the respective product (as in the example in that previous graphic above), and also have full control of everything that happens inside that broader-scoped service – which we usually don’t have when a product is released out ‘into the wild’.

If we don’t have full-control, such as via a hard-wired linkage from service to product to service, then the product may be used in any service that can accept that product – otherwise known as an affordance relationship between a given product and potential services. For example, many cyber-attacks depend on using a data-record (or some other product of a previous data-service) in a different service from one for which that the record was intended – a service that is instead under the attacker’s control.

Or, to give a more tangible example, here’s a tin of beans:

But whilst we might show an example-usage – in this case, combined with other products to provide the service of a meal:

… the product itself doesn’t actually mandate its own usage. If we want the beans to be part of a meal, we could use it with almost any possible combination of other products. We could use just the beans themselves as the sole content for the meal. We could pour them out onto a plate, or eat them direct from the tin. We could heat the beans first, or eat them as-is at room-temperature. To help in eating the content, we could use a fork, a spoon, chopsticks, or no utensil at all. Or we might not even open the tin, and instead use the tin itself as a paperweight, a hammer, a door-stop, a roller to help move a piece of furniture, or a projectile to hurl at a midnight-caterwauling cat. Or, for that matter, never use the product at all, other than leaving it in the stores-cupboard until the end of time.

The product may not be intended for use in those other ways, and may not work well for those other purposes, either. But there’s not much to prevent the product from being used in that way. Which is when ‘product liability’ can become an interesting challenge… This is where instruction-manuals, warranties and the like act as metadata, to help guide the usage of a product towards services for which it was actually intended, and warn of possible consequences if it’s used in a service for which it was not intended.

Remember, too, that software is usually packaged as a product – an app, for example. It’s only when it’s in use, in action, that we would view it as an actual service. The danger here, again, is that our static software-product may be used to deliver a different service than the one for which it was intended – not necessarily because of bugs, or from cyberattack, but often simply because its usage is combined with other software-products in unexpected ways. This often arises because the software-designer has thought only about the ‘happy-path’ – where the product connects to the expected user-service – and failed to consider other affordances that may actually exist.

We also need to note that a service may output any number of products. These would include not just the obvious ones that we would describe as ‘the product’, but all manner of others, such as action-records, metadata, ‘waste-product’ and many more. In a well-designed system, each of those other products should have identifiable services in which they too would be used, moving onward in their own chains of value; in a badly-designed system, we often have little to no idea as to where those other products may end up, and hence potential or actual value lost or even destroyed.

So if we do choose to take a product-oriented or ‘product-first’ view of value-creation, note that:

• we (should) always know which service a product comes from
• it may not always be clear which service a product should go to
• every product has a context defined by the boundaries of a broader-scoped service

In the next post in this series, we’ll explore how this plays out in a sales-context. In the meantime, any comments so far on this? Over to you…