Building a Successful User Research and Product Management Relationship

Product managers are our allies and champions in the user research process. They hold critical knowledge of the business and the strategy of an organization. As user researchers, having product managers "on our side" can make or break how user research works at a company.

After many years of working with product managers, I realized that many miscommunications and misconceptions between PM’s and user researchers come from a lack of education. Just like we strive to understand our users, we also have to understand the role and goals of product managers. When we do this, our stakeholders become our partners and advocates.

Today, one of the first things I do when getting started at an organization is sit down with the product manager(s) I’ll be working with and get to know them. I generally act like a researcher and ask them questions about their role, goals, and how they think/feel about user research. We then discuss the ways we could realistically work together, including timelines and their deadlines.

However, when I began my career, I wasn't sure how to interact with or help product managers understand how to work with me. After a while, I picked up on the areas where product management and user research overlap, collaborate, and hit heads.

Frequently asked questions from product managers

I gathered the most common questions product managers have asked me and put together a few ways to help facilitate the relationship. These questions have led me to build successful frameworks and user research practices across many different organizations.

If you take the time to be proactive with this information, your colleagues will trust and feel comfortable coming to you with questions or ideas.

When should I reach out for help on user research?

This question is essential to clear up as soon as you start working with product managers. Often, we feel like we receive last-minute research requests and are scrambling to make something work. Late research requests usually occur when colleagues aren't sure when the right time is to reach out.

In the past, I have given my product managers several example timelines so they understand what exactly to expect. Of course, timelines will vary on your customer base, recruitment tools, and other factors, but here is the step-by-step process I ask product managers to go through when trying to determine when to reach out to me:

1. Determine the date you want the insights/deliverable by
2. Consider the type of research you want to do (generative versus evaluative)
   • Generative research takes four to six weeks
   • Evaluative research takes two to three weeks
3. Decide on the kind of recruitment criteria you need
   • Standard recruitment criteria takes one week
   • Customized recruitment criteria takes two to three weeks

With this information, we can start to build some timeline templates:

1. If you want a generative research study with basic recruitment, you need to reach out five weeks before you want insights.
2. If you want an evaluative research study that has customized recruitment criteria, you need to reach out about four weeks before you need the deliverable.

Of course, this doesn't always work and, when in doubt, I ask product managers to come as soon as they know they need research. I also set up bi-weekly meetings with my product managers to ensure we are consistently aligned.

What should I expect from a user researcher?

This question can be tricky to answer, but colleagues must understand what to expect from user research and you, as a user researcher.

When I join a new company, I always sit down with my most direct colleagues and do an educational session on the value of user research at an organization. Once I've held this meeting, I schedule one-on-ones with the relevant colleagues.

During one-on-ones, I flip the question on its head by conducting a mini user research session with my colleague. I ask them a lot of questions to better determine what they need or expect from me:

1. How do you feel about user research in general?
2. Tell me what happened the last time you did user research.
3. What kind of timelines are you working with? Have you tried to fit user research into those timelines? Why or why not?
4. What are the most significant barriers to conducting user research?
5. If we could do user research on a recent project, what would that look like to you?
6. What are some ideal outcomes of user research?
7. What are some ways user research could go wrong?
8. What would be the perfect way we could work together?

With this list of questions, you can gather a lot of information from your stakeholders to inform you of their feelings toward user research and how you can best approach working together.

Should user researchers be able to conduct qualitative and quantitative research?

Like business or technical-oriented product managers, user researchers can specialize in qualitative or quantitative user research. Of course, mixed-methods researchers are skilled almost equally on both sides.

However, most user researchers tend to over-index on one side or the other. Therefore, I always tell product managers that I specialize in qualitative user research and my split is 80% qualitative user research and 20% quantitative research.

Because I am not as skilled in quantitative research, I have taken the time to understand how I can work with other people in the company to help support me. For instance, I usually team up with product analysts or business intelligence to help supplement what I am missing. When a product manager asks me to help with quantitative user research outside my scope, I explain the situation and set up a meeting with a team member who can help us.

Unless trained as mixed-method user researchers, colleagues shouldn't expect us to be experts on both sides. It is better to get support from those who specialize in your "weaker" side.

How should I brief a user researcher on a project? What do they need to know?

I love when I get this question because it means colleagues are thinking through how to empower team members to do their best work. If your product manager sends you a research request and it is a sentence or two long, it can be difficult for you to figure out the next steps. This scenario can cause a lot of email back-and-forth or unnecessary meetings.

As people get more interested in user research in the organization, I introduce an intake document. This intake document will help your colleagues know the type of information they need to fill out to kick off a research project (or, at least, get it prioritized). If an intake document doesn't work at your organization, you can always tell product managers the basics of what you need.

Before I had an intake document set up, I always asked them for:

• Why they want to research this topic now
• The goals of the research
• What questions they want to have answered
• What types of information (or deliverables) they would expect
• What previous research has been done to help support the research questions/goals

With this setup, you will have the basic information you need to decide whether or not to proceed with the project and what the next steps should be.

Why do I have to do user research?

Through the years, many people have questioned whether user research is really necessary. People usually ask this question because they had a poor previous experience with research or lack understanding of the value user research can bring to a particular role.

The first thing is to educate colleagues on how user research can specifically help them. If a product manager needs to raise acquisition or retention rates, walk them through how user research can help them achieve their goals. For instance, if we speak to current customers to understand why they stay or, better yet, talk to churned customers, we can help guide product teams toward solutions that users need.

If your product managers are concerned about cost, effort, time, or the other common concerns, the best you can do is speak to them to ease their anxieties. For instance, if the timeline is an issue, talk through how you can reduce the scope of the research to fit into their timeline.

One other note is when people at an organization believe they already know their users. In this case, I like to organize a workshop to delineate between hypothesis/assumption and fact. In this workshop, colleagues talk through what they think they know and then rate their confidence level, what previous data backs up their claim, and the amount of risk they would be willing to take on that fact. This exercise quickly helps to separate fact from assumption. I also look for previous research that either validates or disproves their statements.

How do I hire user researchers?

I also commonly get asked about hiring user researchers, especially if there have never been any at an organization. There are a lot of things that go into hiring a user researcher from identifying the type of UXR you need and writing an accurate job description, to setting up the onboarding process and creating a good job experience.

To give them the full framework of what they need to do, I’ve put together a step-by-step guide to hiring user researchers as well as advice for creating a positive onboarding experience.

Addressing all the questions

Addressing all the questions can feel overwhelming to someone just starting in the field or at a new company. After a few conversations with colleagues, I built a framework that speaks to all of these questions.

This framework helps colleagues understand user research processes at a given organization and how we can work together in the best ways. By building this framework, you will avoid constant meetings and updating each individual when something changes. In addition, this document can give much-needed transparency to current and future colleagues.

If you help your product managers and strive to understand them, user research will find a comfortable and efficient spot at your organization. You will see product managers coming to you for support and requests and truly valuing your insights.