A PM’s guide to making friends with UX researchers

Inspired by a conversation with Tricia Wang.

Working with a researcher for the first time can be really intimidating. They have so many degrees! They know so much! They’re so opinionated. It’s just so much easier to work your designers and developers…

Or maybe you’re not exactly intimidated — you just don’t know how to fit these folks into your workflow. You consult researchers sometimes, and you’re not on bad terms, but you feel like your relationship could be so much better. It’s just never quite clicked.

This is something that a lot of PMs struggle with. We all get a solid introduction to working with developers, and most of us work closely with designers as well. Researchers are a little different; not all of us have worked in an organization that had a formal research discipline. And the organizations we’ve been in that did hire researchers often had very few of them, so we didn’t get to spend much time with them.

Don’t worry! Building amazing relationships with researchers is not as different as you think. And once you figure out how to make it work, you’ll never want to go back.

Start by learning what kind of researcher they are.

Researchers are just as varied as product managers are, and understanding what your researcher’s style is the first step in collaborating effectively. Don’t overthink this: just ask your researcher what their style is! Any researcher worth their salt will, at this point, have plenty of thoughtful opinions about different approaches to research and why they like their particular style.

In particular, find out if your researcher prefers a qualitative, quantitative, or mixed methods approach.

Qualitative researchers focus on deeply understanding the experiences of a small(er) group of people. They’ll do things like shadow people and perform interviews. They are particularly good at capturing subjective human experiences that are nearly impossible to measure on a numeric scale. Because their research is so in depth, they will usually talk to anywhere from 5 to a couple dozen people. If they’re not careful about how they choose who they talk to, it’s easy for them to miss parts of your audience. They’ll be able to find out why people are doing certain things, but they won’t be able to tell you how widespread it is.

Quantitative researchers are on the other end of the spectrum. They focus on gathering large sets of data (tens, or hundreds, of thousands of people) and using statistical analysis to make inferences. They are particular good at spotting what people are do at scale. However, they’re not able to talk to any of those people in depth, so they can’t tell you why people are doing what they’re doing.

Mixed methods researchers combine qualitative and quantitative approaches. For example, a mixed methods researcher might perform some basic statistical analysis to identify a behavior pattern, and then interview people who are part of that pattern to understand their behavior and motivations more deeply. At its best, a mixed methods approach will give you a good understanding of subjective human experience and a sense of how broadly those behaviors scale. At its worst, a mixed methods approach will give you a bunch of low confidence or inaccurate assumptions that you can’t act on.

There’s no right or wrong way to do research. The important thing is to understand where your researcher is coming from so that you can ask them the right questions.

Ride along with them.

The best way to understand what your researchers do is to go with them and experience it yourself. You have to walk a fine line here; you don’t want to accidentally create extra work for them. Getting underfoot is not a great way to improve your relationship.

Focus on picking up simple administrative tasks, or at least staying out of the way. If they’re interviewing users, offer to take notes. Ask if there’s any way that you can help with synthesis — there are often simple, repetitive tasks (like qualitative coding) that you can do to help out. All of this will immerse you in the data, and help you understand the problem space. If there’s nothing for you to help them with, ask if you can be a silent observer.

Throughout all of this, make sure you’re not being disruptive. Let them lead all of their work, even when you really want to say something (imagine how you would feel if they cut into a presentation you were giving to your stakeholders!). Many researchers will specifically create time at the end of a session for you to ask any questions, or create a system for you to relay your questions to them. It’s also helpful to tell your researcher “I’m not going to speak unless you call on me” so that you’re both on the same page about how the session will run.

Listen to what they tell you.

When your researcher tells you something, listen to them. Put on your very best active listening skills. Even when you think they’re being unreasonable. Especially when you think they’re being unreasonable.

Good researchers spend more time thinking about the problems you’re solving, and the people those problems affect, than anyone else in your entire organization. That’s their job.

The rest of the team is wrapped up in the solutions to these problems. UX designers are worrying about how to craft the right interactions, usually with UI. Developers are trying to figure out how to turn proposed solutions into working code. Marketers are building a story to help customers understand how what you’re building helps them. Product managers are juggling a whole bunch of things, from the overarching product market fit to feature prioritization to today’s bugs.

In a way, researchers are the only people on the team who are able to look at the problem for what it is. Every researcher brings their own biases to bear, because they’re human, but they’re the only folks who aren’t automatically biased by the question “How does the thing I want to build fit into this?” That helps them see things that the rest of the team is blind to.

On a healthy team, there is strong mutual trust. Researchers say “Hey, there’s something here that you’re missing.” and everyone else says “Holy cow, you’re right! Let’s talk about what to do with that information. We might not be able to act on it right away, but we should incorporate this into our collective consciousness.”

Unfortunately, it’s much more common for teams to say “That’s great and all, but we’re really busy building. We don’t have time to talk about high level research, and we definitely can’t afford to change the product direction right now. Can you come back later?”

Somehow, later is never the right time either. The researchers start to become jaded. They develop Cassandra Syndrome: they can guess how users will react to the product with high accuracy, but are unable to convince anyone else of what they know.

My friend Carolyn, who’s a brilliant researcher, told me that feeling like nobody is listening is the fastest way to burn out:

When I start getting this vibe it’s usually not long before I’m looking for the next gig. At the end of the day, researchers want to build a great product too, and they want their research to help in that process by helping the team navigate around problems. They feel they can’t do that when their findings are falling on deaf ears.

Why does this happen?

Researchers are trained, and hired, to do research. They’re not consistently taught persuasive argumentation, managing up, or the finer points of organizational politics. Some researchers are really great at those things! But the average researcher isn’t, because their job is to do research.

It’s totally fair to expect researchers to have similar communication skills to designers and developers: they should share new perspectives with the rest of the team, happily collaborate with others, ask questions, and explain when their teammates don’t understand. But you shouldn’t expect them to gracefully convince a hostile or unbelieving audience of their findings day after day.

Unfortunately, that’s what a lot of teams do to their researchers. We don’t mean to, but we’re busy. We don’t understand how their work fits into what we’re doing. Their findings aren’t intuitive. We need them to convince us. We unconsciously draw an invisible line between the researcher and the rest of the team, instead of treating them like part of the team.

Luckily, the fix is straightforward: the next time your researcher shares information with you, do the work of proactively fitting it into your worldview yourself, and include your researcher colleague in your process. Echo back what you think you’re hearing, and ask them if you’re understanding correctly. Tell them what product implications you’re seeing, and get their feedback. Ask them what situations you can apply these findings to, and which ones are a bit of stretch (in research terms, this is known as “generalizeability”). Encourage everyone else on the team to do the same.

As product managers, we spend a lot of our time managing upwards and sideways. That’s not something that our teammates necessarily want to do, or should do. It’s part of our job to help them do that, not to become another roadblock that they have to manage around.

Invite them into your planning process.

Planning is where researchers shine. Researchers are great to have around all the time, but their contributions skyrocket when you’re planning new features. After all, their expertise is in diving into the unknown and pulling out useful knowledge. They’re able to remove a substantial amount of guesswork from the planning process, narrowing down to key areas where you should focus your bets.

When I worked on Windows Ink, I was completely dependent on the researchers that I collaborated with. I had my own hypotheses about how people might use digital pens, based largely on my own experiences, but I had no idea how “normal” those behaviors were. I had access to all sorts of telemetry, but it was only representative of the people who used our existing pen features. All we knew about those folks was that they were a tiny fraction of our user base; most people tried using their pen and quickly abandoned it. Usage data from the few people who stuck it out was pretty obviously not going to help us build something useful for the people who hadn’t found value in what was already available.

If we had been working without a research team, we would have done our best: do as much observation as we could, prototype some things, roll out a pilot MVP, and either iterate until we got it right or leadership cut our funding. This is a pretty standard approach, and it does eventually work. But we could do better than that, because we had a well-funded team of senior researchers. They were able to immediately tell us the answers to many of the questions we had, based on studies they’d already done.

Q: Why are new users abandoning pen so quickly?

A: Here’s a study we did where we gave people who’d never used a digital pen before a Surface and told them to write. Here are some representative video clips. Here’s a summary of their expectations, hopes, and disappointments.

Q: Why do people write things down?

A: We did a longitudinal study where we paid people to track everything they wrote down, including taking pictures of what they wrote and writing a description of why they did it. We also read through some other research and created categories of the different types of writing people do, and their motivations.

Q: What specifically do people write? Can we use AI to somehow add value if they write on a computer?

A: We still have all of the samples from that same longitudinal study. We can look through all of that data to see what specifically people wrote down, and match it against the kinds of things that we might be able to recognize with AI (like phone numbers and email addresses).

All of the researchers I collaborated with had spent hundreds of hours sitting with real people, and they had an internalized understanding of what our users cared about. I sat side-by-side with them (often quite literally!) during the planning process and shared all of my framing documents. I double checked my value proposition with them, and they helped me write out representative scenarios so that I could explain our goals to the rest of the team. I co-authored all of the basic framing — the vision, key scenarios, goals, and priorities — with my researcher.

It was much faster than I could do alone, because they knew the data so well, and we were able to clearly justify most of the choices we made. Because I had data to back almost every choice, and had clearly outlined all of my hypotheses when I didn’t have data, it was easy to explain my plan to leadership. And, best of all, we were able to build something that was useful to real people.

Ask them to help you make tradeoffs.

Researchers are also great at helping you manage tradeoffs as you build. They are a great north star, because they’re much farther away from the messy execution details. It’s all too easy to get lost in the details, because you’re constantly juggling so many things. You envisioned one thing, and as you’re building you realize that that isn’t totally realistic. So you make compromises, you shave off pieces of functionality, you push things out into a future milestone. This is completely normal product development, and there’s nothing wrong with it.

The danger comes when we’ve spent so long shaping an idea to fit what we can build in a given release that we forget to measure it against the most important metric: its impact on the real humans who will use it. When we’re in the middle of building something, we can’t make an objective comparison. That’s where researchers can help us out.

I always think of researchers as an anchor. Their job is to tell me what our end users want and need. Their job is to keep me honest, with myself and my teammates. If I’ve made one tradeoff too many, and the product is no longer valuable, I want to know!

We often leave researchers out of conversations about tradeoffs because we’re worried that they’re going to take too hard a line, and ask the team to do something impossible. Ironically, that happens the most when we don’t include them in our process. They can’t know what we can and can’t build if we keep them at arm’s length. But a good researcher knows the difference between nice-to-have and mission critical, and they’re able to help us stay true to that as well.