Managing stakeholders on a team with strong opinions
Stakeholder analysis allows you to figure out how to approach a team with strong opinions
Sometimes, it’s not just the Highest Paid Person’s Opinion (HiPPO) you must watch out for.
When you design for long enough, eventually, you’ll find yourself on a team with strong opinions about the design. These team members may often have conflicting opinions that could pull your design in multiple ways.
So who exactly do you listen to in these cases? I used to be pretty awful at this as a Junior UX Designer. I’d wait on the sidelines for the team to argue, letting them determine the details before designing what somebody asked me to.
However, working on teams as a Senior Product Designer for over a decade has exposed me to various personalities and decision-making styles. You can’t always stand by and wait, especially if the final decision ignores user needs for the loudest person in the room.
If you’ve ever encountered this situation from your stakeholders, follow a simple mantra: “When in doubt, map your stakeholders out.”
Stakeholder Mapping and what it offers you
Stakeholder mapping is a project management technique for determining who your stakeholders are and how involved they may be in your work.
While this is sometimes done as a team, it’s more common for designers to use this internally with other designers to think about their stakeholders. For example, Designers working with multiple Product Managers on different project features may want to use Stakeholder Analysis to understand a unified strategy they should employ for interacting across teams.
It can start by simply brainstorming a list of your stakeholders, but once you do, you can then organize them in one of two ways:
Bullseye (concentric circles) template
Grid Template
Here’s how you can use both of them.
The Bullseye template: Grouping by priority
While this is typically used for smaller projects and fewer stakeholders, this can be a way of thinking about how different stakeholders relate to one another and how they should be classified by priority.
One of the first steps you need to do is to categorize them based on interest and involvement:
Core Users (Significant interest, significantly impacted by success/failure)
Direct Stakeholders(Some interest, somewhat impacted by success/failure)
Indirect stakeholders (Little interest, not impacted by success/failure)
Doing this allows us to develop groups that you can use to organize your stakeholders. So, for example, if your VP of Product is incredibly outspoken on several issues, but this is just one of several Products he’s a part of ( and is not hugely invested in this one ), then you perhaps would put him as an Indirect stakeholder.
However, this type of model doesn’t scale well with more stakeholders. We can look to another typical example: the Power/Interest Grid.
Power/Interest Grid: Organize by interest and power
One of the most common ways of organizing your stakeholders is to take the list of stakeholders and map them on a grid template, where the two axes are power and interest.
Doing this lets you see who is interested in your work and who can make decisions (or block actions). So while you don’t always want to follow the advice of a HiPPO, people who have high power (and can approve or block your decisions) are people to pay attention to.
This section is broken up into four categories:
As the matrix shows, all stakeholders can fall into four categories:
High power, highly interested people (Manage Closely)
High power, less interested people (Keep Satisfied)
Low power, highly interested people (Keep Informed)
Low power, less interested people (Monitor)
The people that are both highly interested in your project and have high power are those that you need to manage closely, while those that are less interested (or have low power) may need to be informed occasionally.
One thing to note is that using this grid isn’t just going down a list of job titles. While power may be fairly objective, interest is not.
For example, one Product manager might be OK with weekly updates, while another may ask for daily updates and message you whenever there are questions. In that case, putting these two Product Managers in different categories would be OK.
When you have your stakeholders mapped out like this, it becomes much easier to understand who are the essential stakeholders you always need to keep in mind for your design decisions.
Understanding your team is crucial in getting the right people on board
One thing that I’ve learned is that you can’t please everyone. What’s more, there’s a danger in trying to do so: you risk turning something into a design by committee.
So it’s essential to understand which stakeholders to prioritize if several requests pull you in different directions. However, that doesn’t mean you should ignore the suggestions of lower-priority team members.
High-priority stakeholders can be wrong, and lower-priority stakeholders can be right. However, what’s crucial is understanding which stakeholder you need to spend time convincing to ensure your user’s needs are met.
Just like the rest of your team can tame the Highest Paid Person’s Opinion (HiPPO), you can work with the rest of your team to convince stakeholders to choose the decision better for the Product.
So if you’ve ever found yourself with team members that feel very strongly about the design, often pulling in conflicting directions, take a step back and map them out.
Having a visual guide of your stakeholders and how to prioritize them will help you manage your stakeholders.
Kai Wong is a Senior Product Designer, Data-Informed Design Author, and Data and Design newsletter author. His new free book, The Resilient UX Professional, provides real-world advice to get your first UX job and advance your UX career.