A stakeholder, user, and customer walk into a bar… but what do they order?

Stakeholders, users, and customers are three distinct roles.
Many workplaces that I have been to have used the words stakeholder, user, and customer as if they had the same meaning. I get confused when someone uses the three words interchangeably because they are very different, and for a reason.

The purpose of this article is to share my view of the differences between the three roles. To do this, let’s meet Mark, Lloyd, Roger, and Phil from Healthstudio, a private healthcare company that is well known for its outstanding customer service.

Meet Mark, the manager for Healthstudio’s call center.
At Healthstudio Mark leads the call center that handles everything from making doctor’s appointments to payment issues to prescribing medications and much more. Over anything else Mark’s priority is that the call center provides the best service possible to all customers that call Healthstudio.

Meet Lloyd, Healthstudio’s product owner.
Healthstudio has one development team that consists of six developers and Lloyd the product owner. Healthstudio’s executive group meets once per quarter to decide the high level priorities for the development team. In the latest prioritization meeting the executives decided that the development team should help make it easier for call center agents to provide world class support to Healthstudio’s customers.

Use stakeholders to connect you with users and customers!
Although Lloyd has been asked to help Mark and the call center, Lloyd does not know what Mark and the agents need. As a first step Lloyd reaches out to Mark to understand his context. Mark explains how the call center is organized, what processes they follow, and how many people work there. Mark also shares the history of the department and his vision. Lloyd asks Mark “What does world class support mean to you and look like to you?” and notes down the answer.

Once Mark has finished sharing the focus shifts to Lloyd and his team. Lloyd shares how they normally work, what help he needs, and what his current plan is. Lloyd asks Mark if it is ok for him and his team to sit in and listen to the calls that the agents get. Lloyd thinks this will give them a better understanding of the call center agents’ everyday lives. Mark says yes!

Get to know your users, even if it costs you short term velocity!
Mark and Lloyd arrange for the whole development team to sit with the call center agents the next day. During this “field trip” the developers learn the agents’ context i.e. what requests they receive, what problems they face, and so on. All observations that the development team makes, and the data that they gather from their interactions with the agents, will allow them to make better decisions about features and implementation.

Another positive outcome from the “field trip” is that the developers establish relationships with the agents. Two of the agents, Roger and Phil. have offered to participate in the teams planning sessions, demos and to acceptance test features once development starts. Having agents that are available for the development team will lead to faster feedback.

The agents are very important to Lloyd and the development team because they are the users.

While the team listens to incoming calls, Lloyd interviews agents. Lloyd also wants to understand the agents’ context. Lloyd asks the agents:

1. “What are the 5 most common requests you receive?”
2. “How do you describe the typical customer calling in?”
3. “What do you like most about the systems today?”
4. “If you could only change one thing, what would that be?”

One of the most important findings of the day is that the agents use four different applications to serve customers out of which one is slow and unpredictable. This is useful information for the development team and will allow them to define and prioritize their backlog.

You might not need to engage customers.
Lloyd is a bit concerned about how to involve the customers. This whole initiative is about improving customer satisfaction but Lloyd does not know the customers or how to reach them. Mark informs Lloyd that the agents regularly solicits feedback from customers via surveys and at the end of all service requests. In addition to this the agents daily receives praise and critique from customers. The agents note down all feedback that they receive in a customer feedback list that’s kept updated. While Lloyd wants to engage the customers he thinks that this information is sufficient for him and the development team to get started.

All three roles carry different pieces of the puzzle.
In the story above Mark is Lloyd’s stakeholder, Roger and Phil are the users, and they all have different priorities!

• Roger wants to be able to see the next available free doctor in order to book a new appointment for a customer, fast.
• Phil wants to see a list of customers current appointments, so that he can change them fast.
• Mark wants a daily report generated with the number of calls made, served, and lost, the average call length and other data.

What do stakeholders and users care about?
Stakeholders care about the systems in relation to their goals. In the story above, Mark cares that the call center agents can provide world class support to their customers. Mark also cares that Healthstudio’s customers have the best self-service features on the market, but he doesn’t know which specific features will lead there. This is an indicator of a stakeholder such as Mark–he cares about high level goals, not about implementation details.

The users care about how the system helps them do their job which is to serve customers. The system should not get in Roger’s or Phil’s way, it should make their jobs easier. Roger and Phil care a lot about how the development team implements features, and their word carries a lot of weight. Users are also often interested in partaking in defining high level goals, but it is up to the stakeholder and product owner to decide.

If by now you are saying “Hey, isn’t Mark a user too?” you are correct. Mark is the user of the daily report because he will be the one reading it, acting on it, and redistributing the information in it. Therefore whenever the development team wants feedback on this specific feature they should contact Mark. In all other cases they know that they should contact Roger or Phil.

Ok, so what does the customer care about?
Imagine for a moment calling Healthstudio to make an appointment with a doctor. Your main goal is to make an appointment as quickly as possible. Do you care about the agents? Do you care about their system? No. You care about your appointment and you’d better get one fast.

The customers care little about the call center agents or about Mark. The customers care about their own problems and goals. They care that it is easy to achieve their goal.

Why should I care about who is who?
Before you develop a product or system you need to understand that the stakeholder, user, and customer are not the same role. You need to know what the three roles represent, what they need from you, and what you need from them.

The most common changes I see happening once a product owner or team understands the differences are that:

1. (other and additional) people start being invited to planning meetings, backlog grooming, demos, and user testings etc.
2. meetings are completed faster and people are in agreement more than before.
3. the users are delighted over the features that are delivered.
4. retention increases and the customer base grows.

Are you asking the right questions to the right people?
If Lloyd had asked Mark about specific features for the call center application Mark would not have been able to answer, and even if he would have answered, feedback from agents would be more valuable for Lloyd because the agents are the users. On the other hand if Lloyd had asked Phil what outcome he would like to see from this project, Phil’s answer would not be appropriate because Phil is not responsible for the call center.

As the story above shows the discussions that you should have with your stakeholders differ from the discussions that you should have with your users and with your customers.

Please take a moment and consider:

1. What could have happened if Lloyd had only spoken to Mark?
2. What could have happened if Lloyd had only spoken to Roger and Phil?
3. What could have happened if Lloyd had only spoken to the customers?

Summary
Failing to understand the difference between a stakeholder, a user, and a customer means that you might be engaging the wrong people. This translates to high risk of building the wrong features/system/product, or that it takes a longer time than necessary to build to the right thing.

Depending on your role and project you might decide to not interact with any of the roles and as long as this is a conscious decision, that’s fine. As a rule of thumb though, the more roles you can interact with the more likely it is that you will have the information you need to implement the right features in the right way.

I’d like to leave you with the following three questions to contemplate:

1. Which of the three roles are you engaging with?
2. Which of the roles are you not engaging with?
3. Why is that?

Thanks for reading! :)

Addition

After I had written and published this article I realized that I want to be even more explicit about the differences between a user and a customer. I prefer to publish clarifications or additions at the bottom of my articles without editing the main article. I do this because I want to maintain the integrity of my original articles.

Further clarification on the difference between a user and a customer
One significant difference is that customers pay for your service or product and users do not. And although I wish that that was the only difference, it’s not as simple as that.

In this day and age we have freemium services which means that there are people using services without paying for them. If your company offers freemium services and you want to call everyone a user that’s fine as long as you remember distinguish among the users. Here are a few example of what that distinction could look like: free users, paying user, primary user, secondary user, internal user, and external user and so forth.

If you decide to go with the “user” terminology for all it is important to have your definitions clear. When all comes around the important part is the meaning behind the word, not the word itself. A free user and paying user expect different features and levels of service. The same goes for internal user of your tools and paying users of your company’s service, they are two very different target audiences and as a result they need to be treated differently.

You will create better products by just acknowledging the difference between stakeholders, users, and customers. But remember that this is the starting point, there are many more roles that you should acknowledge and approach different from others.