PM Best Practices: How to interview your users (and why it's important!)

Among our many responsibilities, Product Managers are tasked with representing the voice of our customers. It’s the PM’s job to know—intimately—our customers’ tendencies, motivations, and pain points, and to use this knowledge to guide decisions about what investments to make, what features to develop, and what technical trade-offs are worth it.

Gaining this knowledge isn’t easy. At Heap, our customer base is pretty diverse, and includes companies of different sizes, teams with different responsibilities, and users in multiple industries. Your customer base is likely similar—far too diversified to be captured by any single customer profile.

So what’s a good PM to do? Well, at Heap we think it’s important for our PMs to learn how to run an effective user research program, and to get the accurate, unbiased feedback we need to make the right product decisions. As a bonus, running a good user research program also provides an opportunity to build strong relationships with your users—relationships that will continue to reap benefits as you continue to iterate on your product.

Like many companies, we’re not large enough to have a dedicated user research team, so our PMs pair with our designers to run the process. We’re all still learning. But in what follows I’ll walk through some lessons I’ve learned (often the hard way!) about running a good user research program.

Running a good user research program

Find the Right Person to Interview

Interviewing the wrong person is a waste of time for everyone involved. The last thing you want is to get feedback, incorporate it into your product, then realize that the person you’ve been talking to wasn’t the person you should have been talking to.

The path to these nightmare scenarios often starts by asking account owners for help identifying people to interview. It’s not that account owners aren’t interested. It’s just that account owners tend to recommend their main point of contact in the outside company, which is usually the economic buyer. And the economic buyer is usually too far removed from day-to-day product use to be helpful in a product-focused interview.

A better strategy is to start out by specifying the characteristics of the person you’d most like to talk to. These characteristics can be both work-related (What team are they on? What is their role?) and product-specific (How often do they take action X? How sophisticated is their usage of feature Y?). In my job, I use Heap to build a segment of users based on rules that match my ideal criteria. Only then do I partner with account owners to reach out to these users.

Using this approach has yielded many high-quality interviews. I’m surprised how many power users fly under the radar of account owners. Without this technique, I would never be connected to them and would miss out on valuable user insights.

Incentivize your interviewers

There are many examples of research programs offering bad incentives. Just last week, I received a canned email to provide feedback in exchange for entering a raffle for an AWS gift card. While intrigued, I didn’t respond. (A raffle for an AWS gift certificate? Not worth it!) At Heap, we’ve spent lots of time experimenting with different kinds of incentives. Surprisingly, offering a monetary prize resulted in limited success; people tend to not be motivated by putting a price on their time.

So what do users care about? What our experiments have taught us is that interviewees want to know 1) that they’re the right person to be offering insights, and 2) that their feedback will make an actual difference.

We now address this issue head on by addressing both concerns in our invite email, sharing our target characteristics from the previous step (which reassures interviewees that their opinions do matter to us), and by detailing how their feedback will affect project status, timelines, and next steps. Invites that include this information points tend to have a 90%+ response rate!

Make a plan

It’s easy for research calls to become biased. Your users may feel pressured to validate that your plan makes sense. Or you may end up (despite yourself!) processing only the points you want to hear. That’s why it’s important to craft a research plan that can protect you from introducing undesirable bias into the process.

At Heap, every research program starts from a research brief, which we use as a forcing function to ensure we get the kinds of results we want. Research briefs aim to answer the following questions; we address each question in its own section of the brief:

• What is the goal of this research? What will the outcome inform?

• What do we want to learn? What are open questions to ask for each of the things we want to learn?

• What are project risks we want to explore? What questions will help de-risk these? What answers will successfully de-risk these?

• What does the research program look like? How many people will we talk to? How long is the program? What are the deliverables?

It’s important to remember that your answers to these questions may evolve. Once you start talking to users, you may realize that you’re asking about the wrong thing, or that there are other priorities that justify your attention. This is a good thing! It means your research is doing the right thing: giving you more knowledge about your users and the problems they’re facing.

Bonus tip: Designers often have experience doing user research and can help you ask questions in an unbiased way. Loop in your design colleagues to review your research plan and offer feedback.

Better research = better information

User research is really fun—you’ll discover new ways to think about your product and find new dimensions to your users. Following these guidelines helped me find useful patterns in user feedback. Hopefully, these tips help you get the data you need to make better product decisions.