How To Find Your Stakeholders?

Create a Stakeholder Map to identify your stakeholders and how you involve them to create valuable products

Christiaan Verwijs
Published in
7 min readJan 11, 2021

--

You can download this exercise as a free and nicely formatted PDF here.

Scrum teams exist to deliver value to their stakeholders. It's a bit of a platitude, right? What is value? And who are the stakeholders? In this post, we share a practice called a “Stakeholder Map”. It's designed to create transparency around who your stakeholders are, and how to most effectively involve them to determine what is valuable.

Without stakeholders, it’s hard to know what is valuable. The best Sprint Reviews have your real stakeholders present.

Who Are Your Stakeholders?

In a previous post, we explored the difference between a stakeholder and someone who only has an opinion about your product. A useful stakeholder is someone who has at least some “skin in the game”. When your product succeeds, they benefit from it. When it fails, they share the pain with you.

When people have nothing to lose when your product fails to deliver, they simply don’t have a “stake” in it. They’re not a “stakeholder” when they don’t lose a second of sleep when your product, or a part of your product, doesn’t deliver. Instead, they are your “audience”. While it's still useful to listen to their opinions, your attention should focus on the people that have skin in the game. Opinions are easy when people don’t share the consequences of those opinions. So your most natural stakeholders are likely customers (they pay for developing the product) and/or frequent users (they rely on your product for their work).

If you’re like most Scrum teams, you’ll likely have more ideas and possibilities than you have time and money for. So a stakeholder is useful to help you balance what is valuable for your product with the resources that you have for developing it.

“A stakeholder is useful to help you balance what is valuable for your product with the resources you have for developing it.”

The Challenge Of Managing Stakeholders

Scrum teams vary in how many stakeholders they have. While some only have a handful, others have access to hundreds. Managing the needs of these stakeholders, as well as involving them and interacting with them as needed, is a significant challenge for Scrum teams.

One of the practices we’ve always liked is to create a “Stakeholder Map”. We didn’t invent it, only modify it for our practice (p.s. if you know who invented it, please let me know so we can give credit). Although it is a simplified version of reality, the map creates focus and triggers powerful conversations within Scrum teams.

The Stakeholder Map is based on the premise that stakeholders vary in both their stake in the product as well as their influence over it. We’ve already covered what we mean by “Stake”. “Influence”, in this case, refers to the power that someone outside the team has to direct the work of the Scrum team in a certain direction. This power doesn’t need to be exercised; it's enough to simply be there as a potential. Influence can be direct, in that you’re simply told what to do, or indirect, in that others influence the opinion of the product in such a way that you have to follow. Either way, some people have more influence— like a CEO, a board of directors, a social influencer, or a key customer — than others. When you plot both dimensions onto a map, you get the following:

The Stakeholder Map is based on the premise that stakeholders vary in both their stake in the product as well as their influence over it. Download a free high-resolution poster & worksheet here.

Based on their distribution, stakeholders end up in different quadrants. Each quadrant suggests which kinds of strategies are most helpful:

  • Promoters are people that have a significant stake in the product and a lot of influence over its shape. For example, they could be key customers, big investors, or vocal and important users. These are the people that you want to involve extensively, for example by inviting them to Sprint Reviews and Refinement sessions or by meeting with them frequently to identify new needs and validate assumptions.
  • Defenders are people that have a significant stake in the product and a moderate or low influence over it. For example, they could be frequent users of your product or people that made smaller investments (e.g on Kickstarter). “Defenders” tend to be regular users of your product, so you do well to invite a selection of them to your Sprint Reviews. In general, keep them up-to-date on your progress with videos, newsletters, and feedback surveys. They’ll be happy to support you.
  • Latents are people that have significant influence over your product but don’t have a significant stake in it. For example, this can be a department manager that the Scrum team reports to but isn’t investing his or her own budget into development. Or an enterprise architect whose technical decisions must be followed by the team. Or an important customer of other products of your company. Although Latents don’t have an immediate stake in your product, you want to keep them satisfied nonetheless. When you do a good job, they may eventually become “Promoters”.
  • Your audience is the group of people that neither have a stake in your product nor influence over it. It's often enough to inform this group when needed. For example, in the form of an article in the company newspaper or a press release. You can recruit “Defenders” from this group by more actively involving parts of the audience, or tapping into their needs.

The distribution of stakeholders across the map is a snapshot. It's entirely likely that people shift into other quadrants over time as your team focuses on different needs. Several patterns can emerge:

  • When Scrum teams have many Latents, this can be a sign that the mandate of Product Owners over their product is too low. When Scrum teams have to keep many people satisfied that don’t have a stake in the product, this will likely distract from the focus on what is valuable. Or cycle times become long because changes to the Product or Product Backlog have to traverse long approval chains.
  • When Scrum teams have few Promoters and many Latents or Defenders, it can be difficult to break through the many impediments that Scrum teams are likely to run into. Promoters are often your best friends when it comes to breaking through impediments.
  • When Scrum teams have few Defenders, it can be a sign that they are not sufficiently involving the day-to-day users of the product.
  • In general, Scrum teams should invest most of their time and effort in the people on the right of the Map. They are the actual stakeholders.
Use the worksheet to create your own Stakeholder Map. Download a free high-resolution poster & worksheet here.

Steps To Create A Stakeholder Map

There are many ways to create and update Stakeholder Maps. We’ve found the following approach helpful:

  1. Invite your Scrum team to a “stakeholder workshop”. Clarify the purpose and explain how this will benefit the team. Leave the decision to join up to the invitees. Respect whatever decision they make.
  2. Prepare for the workshop by either printing the map on a large poster or creating a huge stakeholder map on the wall or on the floor.
  3. (5 min) Invite everyone to individually and silently make a list of as many stakeholders as they can think of. Ask: “Who should we include, involve, or give a voice to when we decide what is valuable for our product?”. For example, Jenny from accounting (a key user), Patrick the angel investor (a financer), or Karen the customer (who is paying for the product and using it with her company). You can also include discrete groups of stakeholders. For example, “Backoffice users”, “Top tier funders” or “Retail customers”.
  4. (15 min) Ask people to pair up to combine and expand their lists and then again paired with another pair. Ask the groups to capture each stakeholder on separate stickies to make the next steps easier.
  5. (5 min) Invite the small groups to share some of the stakeholders they came up with with the whole group.
  6. (5 min) Explain the Stakeholder Map if the group is not yet familiar with it. In particular, make sure that people understand the axes and what it means to have a “stake” in the product or “influence” over it.
  7. (10–20 min) Ask the small groups to take their stakeholders and distribute them over the shared Stakeholder Map where they think they are. Duplicates are fine as they show consensus (i.e. placed in the same quadrant) or disagreement (i.e. different quadrant).
  8. (10–20 min) Ask everyone to take a step back and observe the patterns. Ask “What do you notice about the distribution of stakeholders?“. Let people first reflect on the map individually and in silence than in pairs. Capture the most salient patterns with the whole group and adjust the map as needed.
  9. Use a Liberating Structure like 1–2–4-ALL, Shift & Share, or Discovery & Action Dialogue to develop strategies for how to involve the various groups.

If you have the option, we always recommend inviting stakeholders. Instead of assuming where they are on the map, they can place themselves where they want to be. In general, we always recommend validating the assumptions with the stakeholders themselves. We like having the Stakeholder Map present during Sprint Reviews.

Closing Words

Scrum teams need good stakeholders to help them identify what is valuable, what people need, and what the best way is to spend their time and budget to fulfill those needs.

In this post, we shared the “Stakeholder Map”. It's a simple practice to help your Scrum team think about their stakeholders and develop strategies for how to effectively involve them. If you use it, let us know how it went! We’re always eager to hear examples (and even see pictures) of how teams use it.

Download a free PDF of the Stakeholder Map here.

Check out patreon.com/liberators to support us.

--

--

Christiaan Verwijs

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Developer, organizational psychologist, scientist, and Scrum Master.