6 Pillars of Effective Researcher-Stakeholder Relationships

Any user researcher can tell you that one of their biggest responsibilities is “managing stakeholders.”

Personally, I dislike the way that is phrased. It sounds like we are trying to wrangle these unruly stakeholders into doing what we want them to do. At times, it might feel like this—but that is not what the majority of stakeholder relationships should be like. Instead, you should be working with your stakeholders to enrich their work and the greater organization with user research.

I’ve worked with a lot of stakeholders in my career whether in the same circle, such as designers, product managers, developers; or outside the product team, such as marketing, sales, account managers, solutions architects, and beyond. Some of the stakeholders I worked with hated user research, some of them had no idea what it was, and some had completely unrealistic (but great) expectations of what user research could do for them.

I have had to wrangle with teams who didn't want to include me, and push my way into roadmap planning, or beg people to join user research sessions so they could see what users were going through with their own eyes.

Sometimes those tactics worked, but the majority of the time, they didn't. In that time, I have learned several lessons that have helped me build relationships and properly engage with stakeholders of any kind.

How to work with stakeholders

There are a few pieces of advice I keep in mind whenever I start working with stakeholders, especially at a new company, or if I have never worked with them before. After a while, all of these steps get easier, and the process becomes more fluid.

Below are a few ways I work with stakeholders to make sure our relationship is enjoyable and helpful for both sides:

Manage expectations

It can sometimes seem user research gets minimized to unimportant or blown out of proportion in what it can achieve.

It is essential to educate stakeholders on what user research can actually do, particularly if they have used different research types in the past, such as market research.

Distinguish between qualitative and quantitative research, and the types of questions.

Educate them (patiently) on research questions

Many stakeholders might be coming at a problem or idea from a very different angle than you. For example, designers and developers might be thinking of solutions, and product managers might be thinking about business goals.

When stakeholders fill out a research intake document, they sometimes really miss the mark on the research questions. Instead, I get a jumble of solution- or business-driven questions, some of them not even answerable by anyone without a crystal ball.

At this point, I have seen researchers get increasingly frustrated by stakeholders, but we have to remember user research is its own practice and craft that we hone for years. Like I hope my product managers wouldn't expect me to know how to run scrum ceremonies or planning sessions, I wouldn't expect all my stakeholders to properly form the most advanced research questions.

Instead, take the time to educate stakeholders (repeatedly) by working through these issues or questions with them. Talk through what a research question is and why.

For instance, I like to preface research questions by starting with the words "why" or "how" because qualitative research is here to answer those types of questions—and they should not be yes or no questions. Continue working with stakeholders to help them understand how to craft a proper research question.

I can tell you it will take some time, but it is worth it!

Explain user research processes carefully

One of the most common questions I hear from stakeholders is, "When should I include a user researcher in a project?" My terribly vague answer is, "As soon as possible, or before."

Of course, I give this vague answer because not every company works in the same way. But remember: you should be explaining this process really carefully, repeatedly for each stakeholder.

A good way to explain user research processes is by meeting with your teams, especially your main stakeholders, and drawing out the different scenarios and where they can pull you in. For instance, I like to be part of roadmap planning, so I make sure to be a part of that meeting. I also create a bi-weekly meeting with all my product managers to ensure I do not miss any upcoming projects.

Additionally, I make the timelines very clear, especially when it comes to recruitment and conducting research because this is where information becomes most confusing. For instance, I talk through how long different research takes, from end-to-end, so stakeholders understand they should back up a few weeks from development for us to conduct a usability test.

Although timelines can differ (through recruitment availability and tools the company has), here are the basic guidelines I give:

• Generative research methods can take 4–6 weeks
• Evaluative research methods (usability testing) can take 2–4 weeks
• Surveys can take 1–2 weeks
• Recruitment can take 1–2 weeks
• Alignment meetings can take up to 1 week

Recognize they have goals to accomplish

Just like we have goals as user researchers, your stakeholders also have goals, and some of them can be conflicting with yours. Sometimes business goals don't align with user needs, and this is where you need to bring empathy toward your stakeholders and your users.

The best way to tackle this is to truly understand your stakeholders' goals and what they mean. This might mean sitting down with your stakeholders and interviewing them about their goals, as you would a user. When you truly realize what others are striving to accomplish, you can better align with them on what is important. You also feel more confident about pitching user research value to these roles since you can speak to the goals they were trying to accomplish.

For example, even though I had never researched content copy, I knew that marketing worked on the copy. I could talk about how I might interact and help the marketing department with their engagement KPIs. Additionally, I knew customer support had incoming calls about customer problems. I could then talk about how important it was for me to regularly meet with them to understand top issues, reducing their workload if fixed.

Democratize research to a point

I could speak about the pros/cons of democratizing user research for hours or, more likely, days. In one light, especially if you are a small research team or even a large research team in a large company, it is crucial to make sure user research doesn't become a bottleneck for teams. I have seen it happen in small teams and large teams when there are too many incoming requests for the team (or researcher) to take care of.

However, I believe we have taken democratizing research a step too far in certain scenarios. User research is one of the only areas of product/tech that gets "taught" to others so they can act on it. For example, I have not learned in-depth about SEO or how to run scrum ceremonies. I think we should be careful in giving the impression that others can easily learn user research in a few workshops.

It is important to empower stakeholders, so we are not an obstruction to projects moving forward. However, you should empower them to a certain point.

For example, I will generally work with product managers to teach them basic usability testing to focus on larger and more complex projects. This includes workshops, feedback, and shadowing, so it is not easy and simple, but it ends up worth it. Additionally, I will also help stakeholders learn how to properly word survey questions.

Templates and examples will be your friend when it comes to empowering—giving stakeholders an easy way to engage with user research will help you immensely. Also, consider them coming to research sessions as democratizing and empowering!

Align, align, and align again

When working with stakeholders, transparency is absolutely key. The worst projects I've led are when I overpromise and then underdeliver. They feel terrible and make for strained relationships. With stakeholders, as transparent and informative as you can be, the better you will work together.

To align properly means quite a few meetings and documents or processes. For example, intake documents are a great way to understand what the stakeholder really wants and put you on the same page at the beginning of the project.

Thereafter, creating a research brief with all of the research goals, questions and timelines will ensure you continue to align throughout the project. And, finally, having a kick-off meeting is always a nice idea to finalize the alignment.

Finally, being transparent with your stakeholders also means sometimes saying no. This doesn't mean you simply tell them "no," but also explain how your prioritization works and how you plan and distribute your capacity.

For instance, if I know I won't have the capacity for new projects in the next two months, I will tell all my stakeholders as soon as I know this and what we can do to work around it. I have learned the importance of being as transparent as possible, as quickly as possible, even if it isn't what people want to hear.

Overall, working with stakeholders can be an extremely satisfying experience and help you develop as a user researcher. Not only will you grow from these experiences, but also you can help other stakeholders improve with your knowledge!