Rent The Runway Product Lead on Building A Stakeholder Map
Stakeholder Map: Mitigate Chaos, Stay On Target
If I threw you out of a helicopter in the middle of the wilderness and you could only request one thing, my guess is you’d pick a phone with a maps application on it. Every day, we rely on maps to point the way. So it shouldn’t be hard to convince you that if you’ve gotten pushed into a messy and confusing project lately, and you’re trying to find a path forward, you may want to make a stakeholder map.
What is a stakeholder map?
A stakeholder map is a way to visually display where people who matter agree and disagree. Often as product managers, we touch products that impact multiple far-reaching teams. Everyone has an opinion on the decisions we have to make. Many of these opinions conflict and sometimes a conflict can doom your launch. A stakeholder map helps us call out and plan for conflicts as clearly as a mountain range.
Making your stakeholder map
- Be generous when listing stakeholders. Whenever you start a new opportunity, you should cast a wide net to find your stakeholders. You can always narrow your set as the development process progresses. But in the early days, it’s good to start big.
- Identify critical decisions by sharing low-fidelity designs. It can sometimes be difficult to find out what’s contentious within your project. Many people don’t know they have a strong opinion until they hear or see something they disagree with. It’s helpful to have a straw man idea of your roadmap and low fidelity designs to draw out conflict early. Where possible, I try to choose an especially bold set of designs as a conversation starter.
- Plot out where each stakeholder falls. As you begin to identify critical decisions, explicitly ask folks their thoughts on them, and start writing those thoughts down. I like to use a combination of a spreadsheet to capture the general binary direction of their sentiment. In addition, you can take notes in a separate doc so I can understand and remember the nuances.
- BONUS: Identify clusters. Things really get interesting when you’re able to identify clustering in the opinions you encounter. On a recent stakeholder map that a teammate and I built, we discovered that our stakeholders were all aligned on the customer experience we were trying to create, were in two distinct camps about the digital experience, but were all over the place on the branding.
Using your stakeholder map
Once you know where things are likely to fall apart, you have a few options for how to move forward.
- Scope conflicts out of the project. The simplest solution, is that if X is a huge point of stakeholder contention, and if X is not critical to achieving the success metrics associated with your launch, try to scope X out of your launch. Trying to find a solution there may be a waste of your limited resources.
- Do your homework on high-conflict decision points. If you have to (or want to) take on the mountain range, the best case scenario is that you can come to a decision through data. Because you’ve identified the areas of greatest contention in advance, you can spend extra time conducting customer interviews, doing data deep dives, and demonstrating technical expertise on these decisions to help steer the project in the right direction, or at least to feel confident when defending contentious decisions.
- Use your map to lead a conversation about conflicts. When there isn’t ready data, sometimes the most powerful things you can do to move forward is to show your map to your stakeholders. By showing everyone where the group stands, and by faithfully representing the valid and passionate arguments you’ve heard along the way, often you can the group move itself forward.
Once, an executive I worked with was dead-set against a feature.
Specifically, she was concerned it would compromise the quantity of data we get from customers. After showing her the stakeholder map, she saw all of the people from our data teams I had interviewed, and that all of them were in support of this feature because it would vastly improve the quality of the data.
The map not only helped her understand this specific problem. In addition, it also eased her mind that product was doing the work to understand the needs of other teams. She was less prescriptive in projects moving forward.
When I got into product management, l did not expect to become a cartographer of conflict, but I now ask every PM on my team to develop a stakeholder map for each of the meatier features or projects they take on. It doesn’t make conflict disappear, but it does tend to keep it from taking us by surprise, and often that’s all you can ask for.