Service design for product managers
Service Design is a buzzy concept that has often gotten mixed with Customer Journey maps, Design Thinking and other UX concepts. Outside of tech, service design has always been something that marketing did — centered around the customer touchpoints of a traditional brick and mortar (or online) store or service. Inside of tech, it’s treated more like “how your app interacts with customers” — and often, not the other way around. Whether it’s push notifications or churn-preventing emails, most technology is looking to interact with customers, but in a selfish way. As a product person, you’re thinking about “your” metrics — what is the feature going to do for engagement? For sales? For upgrades? To create a stickier and more valuable experience, product managers need to be thinking about their technology’s service design holistically to understand better what the meaningful interactions are.
Since service design has mostly been something handled by the marketing team or user experience architects, product managers haven’t paid much attention to it. So this is an overview of the concept, an outline of how to do a mapping exercise, and some suggestions for building better touchpoints, aimed at product managers in tech companies. Your mileage may vary if you’re in a different role or a different type of firm!
Go talk to people
Service design starts with attempting to understand all the current customer touchpoints with your product and/or service. But likely, the very first step is to conduct some interviews. PMs usually focus on research and discovery around jobs-to-be-done and customer needs — the difference with the service design process is that you’re looking holistically at behavior, not just potential app/tech use cases. You’ll want to focus on the activities that take place in between app interactions, since your in-app interactions are probably well understood.
You can start by talking to your coworkers in Customer Success, Support, and Sales to properly capture all the interactions they have — is there an initial sales pitch? A regular monthly touchpoint? What about the unplanned things — support calls or plan upgrades? Are there any non-people-based touchpoints pre-sale, like automated free trial engagement emails? It can be really helpful to see app notifications, emails, and personal touchpoints in the same view, to understand if you’re contacting your customers too much or not enough.
When you’re done talking about the known touchpoints, you should try to connect with customers to see what they’re doing outside of the technology/app. We know they are accessing the tool weekly, but what are they doing in their job outside of that? This can expose your gaps of understanding about what the customer is really doing (and identifying more potential Jobs To Be Done that you weren’t aware of!). Interviewing your customers and having them walk you through their day to day workflow is a normal part of the PM process, but if you haven’t done this conversation, now is a great time!
At this point, if you find that you have any gaps where you don’t know what happens, you can highlight those unknowns for more research. It’s always ok to have a research backlog!
At this point, you’re ready to make a service blueprint. This document shows the handoffs and activities that occur in a swimlane/process flow type format. Service blueprints are very helpful for getting the rest of your product development team to understand how your work fits into your customers overall goals/activities.
So how do you create a service blueprint?
First, start by documenting all the activities that happen for “front of house” and “back of house”. You’ve likely heard those terms in connection to restaurants, but they work well for technology (and any business!) too. “Front of house” is every piece of technology that the customer interacts with, while “back of house” is any of the support process that aren’t visible (for example, logging or db calls). Miro has a very nice service blueprint template available to get you started.
Here’s an example, also from Miro:
Let’s break down the horizontal swimlanes -
- Support Process — these are any process that provides infrastructure for the customer journey, such as receiving inventory and updating stock information in traditional business. In tech, this could be an automatic Slack message that gets posted, or logging to the database, or adding the customer inquiry to your CRM.
- Invisible — these are things that happen that the customer is totally unaware of. For example, this could be assigning a SDR to the customer, adding their info to your marketing email list, or notifying the other end of the 2-sided-marketplace about interest the customer expressed (“someone looked at your listing!”).
- On Stage — these are things that the customer can see and experience clearly, like all the screens in the app or a direct interaction via phone or email or chatbot.
- Customer — these are all the actions that the customer takes both on and off app, including different paths and use cases. Examples include the customer pressing the buy button, engaging the chatbot, leaving a review on the app store.
- Physical Evidence — any physical touchpoint, like an automated welcome email, the product arriving in the mail, or your website or app. These boxes go along the top and correspond to a step — they connect the service action to a physical act/thing.
Now what?
Now that you have everything in your process flow, you can start to identify issues or gaps. Do you see areas where you aren’t clear on what happens exactly? Maybe your customer downloaded a report — what are they doing with it now? That’s a good place to dig in for more details. You can also highlight the points of friction from this view. Are there too many post-purchase emails/notifications? Do your customers have to go through a lot of phone calls before they can sign up for a trial? Highlight these areas for further exploration and conversations with your colleagues and customers.
As a PM, you now have a nice document exposing weaknesses and potential issues that your customer is encountering. If you were looking for focus areas for your roadmap, you have just struck gold. Start thinking about what you could do to solve for the situations you’ve identified. Prioritize the friction points — which are the worst, and start there. Friction points can usually be associated with a metric, like sales conversion or unsubscribes, so you’ll be able to immediately track if you’re making progress. In my experience, these points of friction that you can solve with building or removing features (like popups!) are easy things to add to your roadmap. And the service blueprint can create a compelling argument for making your updates! Sharing the blueprint with your teams will also help create more awareness across the organization of who is doing what — especially when you’re growing, this can be invaluable!
Big thank you to Prof Valarie Zeithaml of UNC’s Kenan-Flagler Business School for her excellent class and the source material for this post!
