Stakeholder Management: How I get Everyone on the Same Page
As I wrote about in How we build our Product Roadmap at Asana, a big part of my job is getting huge numbers of stakeholders together to make decisions on things that everyone cares a lot about. The stakes are high because everyone is thinking about how the choices are going to affect their different teams, and each person has different context, goals, experiences, and risk tolerance.
The tricks to stakeholder management are to focus on goals, clarify the decision maker, and know when to escalate.
Focus on goals
Start by understanding where each of the stakeholders are coming from.
My favorite way to approach this is to set up a coffee chat when we first start working together, way before we get into any tricky situations. For the roadmap process I asked a lot of people “How did you feel about the way we did the roadmap last year? Any thoughts for how we could do better?”.
And then when I got the answers, I dug deeper, sometimes just with a simple “tell me more”. I learned a lot of non-obvious goals this way. For example, some teams were pushing for more complex projects for recruiting or morale reasons. Knowing their goals helped me anticipate how they would react to different options, and helped me come up with solutions that would really work for them.
Later in the process when I’m getting feedback and trying to make a decision, it’s again really important to bring the conversation back to goals. In the roadmap process, lots of stakeholders pushed for projects I didn’t think we should prioritize. First I’d try talk to them about what goal they were going after, and sometimes they’d quickly agree that their goal wasn’t as high priority as our other goals. Sometimes I’d start a larger discussion about whether to prioritize the new goal.
Other times I’d realize we were going after the same goals, but they had different assumptions than I did about which projects would best achieve our goals.
I try to get to the bottom of assumptions by asking “What would I have to believe to believe that person is right? Under what circumstances are they right?” As an example from product launches, when there’s a disagreement about when to launch, there’s usually different assumptions about how big the marketing bump will be, and how much it will be impacted by different timing.
Once I’ve figured out the goals and assumptions, managing stakeholders is much more straightforward — we can have a clear conversation about which goals are higher priority or how to validate assumptions.
Clarify the decision maker
I sometimes find it scary to clarify the decision maker because I’m worried that multiple people think it’s them. But in practice, this is a critical step, and it’s always better to bring it out into the open. If I am the decision maker, it’s really helpful to have all the stakeholders know that. If it’s not me but I’m leading the process, I’ll alter my approach a little. At Asana we’ve made it a cultural norm to ask “Who’s the decision maker on this”, and so it now feels easy and normal to ask.
In addition to the one decision maker, I figure out what everyone else’s role is. Are there other people who can give blocking feedback? Are the rest of the people just advisory? Again at Asana we often formalize this so the structure is clear.
Once I know the decision maker and roles, I’ll talk to everyone about how we’re going to be making decisions. For example with the roadmap, after a large round of cross functional discussion, we aim to come to a consensus with the 6 people on product planning. I make sure the large cross functional group knows that not everyone is going to be totally happy upfront, so we don’t run into trouble with someone from the larger group later on thinking they’ve have veto power.
Then, for The Magic Step: I make space to understand each stakeholder and make them feel heard. One way to do this is an around-the-room, while I take notes and project them, so people can see that I captured their points accurately. On bigger things like the product roadmap I assign each person a task, so they can take time asynchronously to give feedback.
Know when to escalate
At Asana we often refer to a problem we call “serving multiple masters.” When you’ve got two people trying to be your boss, or two goals that are trying to be the number one priority, of course they’re going to come into conflict. It’s basically the opposite of clarity of responsibility. Whenever we notice this problem, we try to immediately resolve it.
Sometimes I can solve these problems without escalating — I’ll get together with the stakeholders and we’ll all agree which goal is more important. We can walk up the Pyramid of Clarity and come to a shared understanding.
But other times as stakeholders we’re each too specialized to evaluate how our goals or assumptions compare. After a conversation I understand the other person’s point of view, but I’m honestly not sure whether their concerns should outweigh mine. That’s when I escalate.
Escalation in these cases isn’t failure — it’s the system working the way it should! The best way to escalate is with that tone in mind — I’m not complaining that the other person is wrong. I’m escalating because I respect the other person and I don’t want to barrel over their goals. I’m surfacing the two points of view and asking the person to whom I escalated to use their larger context to make a decision.
I’ve seen escalation work really well. Here are some examples:
- A product team with a revenue goal and a product team with an ease-of-use goal were trying to make conflicting changes. This got escalated to me and I changed the second team’s goal to “improve ease-of-use without hurting revenue”.
- Neither I nor the head of business wanted to be final decision maker on Privacy issues. We escalated to the CEO who created a cross-functional Privacy Board for discussing issues that came up as a group.
- A few times a PM and their marketing stakeholder disagree on the launch date because they’re valuing the benefits differently. We’ve now made it official that JR is the decision maker in those cases, so the team knows to escalate quickly before the discussions get stressful.
Escalation is a really important tool for stakeholder management because when people really are optimizing for different goals you don’t want the decision to be made by whoever is willing to argue more. It really is best for the company for someone to do the hard work of deciding which goal is more important.
Click the ❤️ below if you like this and let me know what you want me to write about next!
