Stakeholder mapping
We don't just build software products. We build software products for someone.
The diverse alliance we call "stakeholders" has an enormous impact on our product. Strong stakeholders give their engineering teams wings. Weak ones threaten the product.
But teams aren't at the mercy of their stakeholders. They are not an uncontrollable outside force. With a little bit of organization, effective leaders can manage them. Most of what we call "managing up" is influencing our stakeholders to support the product better.
Who are our stakeholders?
I use a very narrow definition of stakeholder to only include those we need to manage.
At a team level, a stakeholder is any internal party involved in or dependent on the evolution of the team's product. That means stakeholders vary from team to team. While that definition sounds generic, it cuts out a lot of parties.
It excludes customers, users, and vendors. We don't want teams to share their internal roadmaps with them. If the Finance team likes your product but couldn't care less about your roadmap, they are not a stakeholder. That team that relies on your API is. Identifying our team's stakeholders allows us to determine the target audience for our communication. It shows us which relationships to manage.
We'll start by listing all our stakeholders. While each organization is different, these are some of the most common ones:
Product
The product organization is the team’s most intimate partner. Product is also their most demanding stakeholder. They often help design solutions and want to be kept up to date on a feature level.
If a team maintains multiple products, they might serve multiple Product organizations. List all of them.
Sales
Salespeople care about new features and timelines. They allow them to woo new customers. If you have a Sales department that needs to be kept up-to-date about the roadmap, list them as a stakeholder.
The engineering team
Teams are their own stakeholders. By definition, they have an interest in the evolution of their product. They belong on the list.
Customer support
Customer issues often come through a service desk or customer success team. Note that these teams are the stakeholders, not the individual users or customers.
Internal customers
If the engineering team builds a data-intensive application, they might have to liaise with the data warehouse team. Other engineering teams are only stakeholders if they interact with each other. If that's the case: add them to the list.
By now, we have a list of all stakeholders that looks like this:
We can now divide them into two categories by asking a straightforward question: "Does this party generate items for our roadmap or backlog?"
If the answer is Yes, they go into the Input column. If not, they go into the Inform column.
By categorizing these stakeholders, it should become clear who actively provides input to the team's roadmap/backlog and who just wants to be kept up-to-date about the timeline.
And now for the good stuff:
Roadmap updates
Whenever the roadmap changes, send an e-mail to all stakeholders in both Input and Inform lists. This informs the entire target audience without spamming those that don't care. A targeted email beats a generic Slack channel.
Track stakeholder satisfaction
Each roadmap item gets linked to an Input stakeholder. Most project management tools allow you to tag stakeholders in a ticket. Over time, this will give you valuable insights into which stakeholders are served most and which are neglected. This is especially valuable for teams that maintain multiple products and can guide decisions about team reorganization.
Track unstable stakeholders
Each "expedited" ticket can also be linked to an Input stakeholder. This makes it trivial to spot the sources of unplanned work. We can influence that specific stakeholder to make their planning less chaotic.
Protect bandwidth
When new ideas reshuffle the roadmap, there's a real risk of serving the most chaotic Input stakeholder at the expense of more stable ones. Having a clear view of the source of each request allows us to protect stakeholder bandwidth. We can deliver the urgent feature at the expense of another feature for the same stakeholder—one in, one out.
Efficient communication
Calling a meeting with all stakeholders is expensive and wasteful. Recurring stakeholder meetings are even worse. They're practically an open invitation to reshuffle your roadmap. Avoid these at all costs.
These discussions become much more efficient when we've mapped each roadmap item to a stakeholder. Instead of debating the new plan with all parties, we can now invite only the impacted ones. The rest just gets updated about the new plan via e-mail.
Knowing who your stakeholders are and how they interact with your team is the first step to managing them well. It gives the team tools to influence those outside forces that affect them the most.