How products and services work together

What’s the difference between a product and a service? Do we all need to become more service-focused? If so, what can we do about it?

We get a lot of questions about the difference between what makes a ‘product’ vs what makes a ‘service’ here at the School.

Whilst it’s tempting to be puritanical about the definition of words that mean so much to us, the question of how you define the difference between a ‘product’ and a ‘service’ is about much more than just semantics.

When an organisation says it is ‘product-centric’ what it usually means is that it has made a deliberate move away from (or avoided entirely) running large, waterfall programs of work with one-off outsourced digital delivery, to small, permanently embedded digital ‘product’ teams that are often working in a much more agile iterative way.

To be ‘product-focused’ or have a ‘product mindset’ is about more than a way of working, it's an aspirational culture - one that is fast-moving, ‘modern’, agile and responsive to user needs and market demands. It is commercially focussed, ‘lean’ start-up thinking for the internet age and it is hugely attractive to most organisations. 

There are lots of books that will tell you that to survive in the modern world, your organisation has to become product-focused, and whole industries devoted to scaling agile product delivery as an antidote to sluggish change. But like any idea, ‘product centricity’ causes problems if we take it to extremes and think solely about products without thinking about how those products work as part of a service.

Sadly being product-focused has come to mean an over-focus on technology, delivery speeds and targets, rather than an ability to move quickly to meet user needs as many organisations had hoped.

So, before we dive into what those issues are (and how we overcome them), let's look at what products and services actually are, beyond their association to agile, ‘modernity’ or faster ways of working. 

The difference between a product and a service

A service is something that helps someone to do something, like opening a bank account or buying a house. Services often involve multiple smaller tasks or interactions along the way to achieve that goal, like checking if you are eligible to open an account and receiving your debit card in the post.

This is where products and services interact. While services help our user achieve an end goal, products are how we organise ourselves to deliver that goal.

For example, the service of ‘opening a bank account’ might need a ‘credit checking’ product,  an ‘account’ product and a ‘card printing and postage’ product to help a user reach their end goal. All of these products are different from one another and require different technology, systems and most importantly skills to be able to run them, so it makes sense to organise ourselves around them and deliver them separately as product teams to manage the pace of change needed to deliver them.

If you’re struggling to define your service, take a look at this blog post on ‘What is a Service?’ before you read the rest of this.

Why products and services are different things 

While services are solely concerned with the outcome a user is trying to achieve, a product might have to support multiple different services at once. 

For example, the ‘account’ product in a bank will not just be part of ‘opening a bank account’ but will be part of ‘checking your bank balance’ and possibly even ‘closing an account’.

Both the service and the product have slightly different objectives, the service cares just about opening a bank account, the product cares about everything you need to do to administrate the account, from opening it, paying bills to closing it too.

Products and services need each other

It’s important that products are designed well individually, but it’s also important that they work together as part of a service that helps our user to achieve their end goal.

If we were to just think about products without thinking about services, we would make mistakes in the way these individual products work, and work together in helping our user to achieve their goal. 

For example, suppose we didn’t consider the service of ‘opening a bank account’ when designing our bank account product. In that case, we might not think about helping people to orientate themselves when they first arrive at their account or helping them to import direct debits from somewhere else when that person wants to move their account from another bank.  Equally, we might not consider how the bank account works with other products, so when someone wants to query a payment or report fraud, they might have to exit the account to do that somewhere else giving their details repeatedly to each person they interact with along the way.

In an entirely product-focused organisation, we see our products as an island, where people mysteriously arrive from somewhere to do a wide variety of often unrelated activities, and just as mysteriously leave to do something else elsewhere. If this sounds familiar, it’s because an over-focus on products is by far the most common version of this imbalance between product and service thinking.

If we just thought about services, the picture isn't any more rosy though. Focusing solely on services could mean building a bank account that only works properly for people who are using it for the first time as part of ‘opening a bank account’ and not for someone who’s closing their account or checking their balance.

At its extreme, it could mean duplicated effort and difficulty scaling the service as we build completely separate service journeys that duplicate key ‘product’ features like ‘account management’. 

If either of these scenarios sound familiar, you are not alone.

Most organizations that we work with come to us with some form of imbalance between their focus on products and services respectively creating a whole host of issues from siloed services to an inability to scale.

Being user-centric means finding a balance between products and services

The challenge with balancing a product and service focus is that they are both inherently pulling in different directions.  

Organisations with a sole focus on products will often struggle to get permission to work across product areas and join up service journeys. Likewise, extremely service-oriented organisations might struggle to build shared capabilities that would enable each service to be more efficient and scale to a wider user-group.

The solution isn’t a simple one to fix over-night, and there are often deep-rooted reasons why we’ve ended up where we are that need to be unpicked, but there are some ideas to try if you find yourself with an imbalance between product and service thinking in your organisation

What to do if you’re too focused on products

In a product-heavy organisation, we need to think about how we create connections between our products so that we can allow them to be designed with consideration of the service(s) they will be used as part of.

Organisations will often use service designers as the glue to stitch these things together, but without any additional support or incentive for teams to work together - either through shared objectives, key performance indicators (KPIs), funding or prioritisation we may as well be sticking those products together with pritt-stick. We might end up with better results than if we had no service design input, but it comes with the heavy cost of burning out our service designers and then frustration all round.

To solve this issue we need to think about creating more robust supportive structures that actively encourage service-thinking that don’t rely on one individual and their energy to pull them together

We can activate a number of informal and formal ways to do this, some formal ‘structural’ changes that require permission to do, and others that don’t;

Steward services through service ownership

At its most formal, creating ‘service ownership’ roles that encompass multiple services can help (so long as the roles and responsibilities and relationship are clear between product and service owners).

If we don’t have the permission to create new roles or change existing ones though, we can make a start by adding service ownership responsibilities and pivoting our current roles to cover what a service owner might be responsible for. If even this feels a little too difficult, another less formal intervention you can make is to establish service communities, or groups of people across different product teams who can come together to work on shared services by sharing user research, journeys or insight.

Create shared objectives and share measurement efforts

We can formally set shared objectives or metrics to incentivise teams to work together. This might look like incentivising three different teams to work together to deliver a metric like meeting an end goal or outcome for a user.

Agreeing to take on or share the data collection and measurement effort for teams might support collaboration across silos, reducing effort for everyone but formalising a need for collaboration. 

Encourage knowledge-sharing networks

Show and tell’s or communities of practice meetings also form an important part of sharing and collaboration and are the kind of thing that you won't know you’re missing until you start doing them. When they are in place, many people realise how much faster those intangible connections between products become.

Bake in time to reflect after product sprints

Allowing time after your product sprints as a so-called ‘fire break’ that allows teams to work on shared projects across product areas can help, or, if you can, incorporating active encouragement of this discovery of shared problems and opportunities by allowing a set amount of the working week to work on ‘side projects’ shared across the organisation.

Working across siloed products takes time, and as Melvin Conway said when he was discovering conway's Law, it's our ability to have quality conversations across our organisational silos that matters, not what shape or structure those siloes are, so our approach should be as much about linking stuff up where we can as it is about creating the environment for those collaborations to happen in the long term.

Remember, collaboration doesn’t come for free and takes nurturing so, you need to find ways at an individual, team, department and org level to bake in the resources people need to enable this. Starting small is ok, but as the need for collaboration scales, formalise it into job descriptions, schedules and governance.

What to do if you’re too focused on services

Organisations in this situation tend to have very expensive, bespoke services that are very human-to-human based in sectors where user needs might be complex and variable like healthcare, emergency response services, drug treatment or philanthropy. They focus on services to the extent that the data and systems they use to deliver those services are sometimes almost inconsequential.

At its most extreme, organisations in this space will struggle to even think strategically beyond immediate delivery and become unable to step back from a cycle of delivery to spot shared problems or long-term strategic issues.

Switching to having an equal focus on the ‘products’ needed to deliver those services when we might have a very small team delivering a hugely variable set of services isn’t going to work. But, we do need to find ways to work together to identify the shared capabilities needed to improve our services and scale them to a wider group of people

In a heavily service-only or focused organisation, we need to think beyond the boundaries of our service to look for patterns in what we do, where our services deliver similar activities, using similar systems or relying on data that we could utilise to make our service more reliable, effective or efficient. 

This is important as we are usually missing out on providing a service to a larger group of users, as our services struggle to scale beyond the individuals who provide that very bespoke aspect of our service. Or, we are less efficient in how we deliver those services, with staff often taking more time to deliver services, repeating elements of service delivery that could probably be made easier/quicker by a product supporting the delivery. 

Organisations that work in this way tend to outsource their products to third-party suppliers, but doing this on a siloed service-by-service basis, often makes it impossible to join products like ‘case management’ or ‘data analytics’ up later to enhance how they deliver their services.

So what can we do?

Understand what shared capabilities we need

Solving this issue means understanding what shared capabilities we need, highlighting the importance of those capabilities in underpinning our services so that when we do buy something like a ‘case management’ product we do this well, and we can share the benefit of these products between services.

In this situation, we should focus on finding similarities and common activities across our services, spotting patterns in the activities we have, data we need or ways we need to work.

Map our services and user activities, identifying shared activities 

We can only do this by mapping all of the activities and systems that are used in our services, so the first task is always to map all of our services and the activities that are required. It’s important that we do this from a user’s perspective otherwise we may end up with activities that aren’t needed by assuming the way we do things now is the right way of doing it. Needless to say, this takes time.

Next we can check, are there any shared activities like, ‘accessing or updating a customer record’, ‘placing an order’ or ‘paying money’ that we might be able to group as a product? Likewise, are there any services that work in such a similar way that we could create a service pattern to allow all of those services to be well-designed more quickly?

Understand our user’s data and how it is used to deliver outcomes  

In this scenario we should also turn our attention to data, especially our customer data. How and where we collect it, where is it stored and can we share it readily across different services so that we can stop asking our user’s for their information at multiple points? If we can't, why not? Do we need to look at creating data standards or bringing in some expertise to help us rationalise where we’re recording and keeping all of our customer data?

It’s likely organisations in this situation will have limited budget or people to dedicate to building and designing any of these products in-house, so once we have a good idea of what products we need, we’ll need to turn our attention to how our organisation buys these products and make friends with our procurement team. 

Take a look at our existing tech contracts, are they long and not serving us? Do we have the expertise we need to assess our contracts or buy technology effectively? What does the market out there have that we might use or adapt to fit our purpose? Again, this is not an overnight activity but is vital to do with the insight of someone with a design, technical and data mindset.

NOTE: If your services are too small

Sometimes we can get the scope of our service wrong and our services support just a small part of a user’s journey to do something. If you think this is you, keep your eyes peeled shortly for a blog post on defining what a service is.

Sometimes, services that are too small and narrowly defined can lead to just as much siloed thinking as it does in a product space as individual services struggle to work together to help a user who might interact with multiple services.

For example, a local authority or city council that struggles to join up their ‘social housing’ service with their ‘care’ service, might find that they have young people exiting the care system in need of housing who aren’t able to get it fast enough but because these two services do not work together.

In this situation, we need to make sure that we can focus on those larger connecting journeys that join smaller services together like ‘leaving care’. If we find out services are too small, go back to the advice for product-heavy organisations and start with the advice listed there.

TLDR;

The intrinsic connection between products and services is the foundation of service design as a discipline. Many of the early pioneers of service design were first and foremost physical product designers who spent their time wondering why we weren’t all thinking about the marketing, repair and replacement of the vacuum cleaners, radio sets and cars they were designing. 

The journey that many digital product organisations are now on to think beyond their products to the services they are part of is the same as the journey many manufacturing organisations went on 20 years ago. What we learned then is something we should remember now - products and services are not mutually exclusive, you can not have services without products, nor products without services.

If your organisation is on a journey to balance its approach to products and services, and you’d like some help moving your team or organisation in that direction, get in touch.