Managing products: User interviews for learning and profit

Your main job in managing a product is understanding what product users really want – here are my thoughts on conducting interviews to get you good answers

The single best source of data on what users need from your product is the user interview. You get a great deal of information from a single user interview. If you do dozens and dozens of them – I’d shoot to spend 3-5 hours a week all told on user interviews – you will develop a powerful sense for what your users need.

Here's what I need when I'm not using your products

The setup

I like to do most customer interviews over a videoconference. A videoconference strikes a nice balance. In-person interviews are valuable in that you get a real feel for who a user is and what they’re about. And for some users, particularly those not particularly adept with technology – corn and soybean farmers I’ve worked with come to mind – it can be the only way to get quality feedback. In-person sessions also extremely expensive in terms of time and travel costs. A phone is pretty low-bandwidth and doesn’t allow for screen-sharing so I try to avoid those. On a videoconference, the best practice is to record the interview – ask the user if they are ok with you recording. Also ask users to turn on their webcams if they’re ok with that – most will be fine with it and it will give you a better feel for your users.

One word about the most common rookie mistake all of us make when we start doing user interviews: we ask users what other users might think. For example, we ask “How important do you think this is to other users.” Users cannot correctly answer this question and if they try, they’ll just be guessing. Also it’s your job to answer this, not theirs. Ask users about their own thoughts, don’t ask them to speculate on the thoughts and needs of others.

Establishing rapport

The first thing any sales person will coach you on is to build rapport with a customer. The user mostly wants to know you’re a human. Here’s how someone coached me when I was briefly in a sales role: when you get on the line, tell them your name and your position. This establishes status and relevance. Then – and this is key – say something humanizing. Anything will work.  Ask them how they’re doing today. Respond to their answer. Use it to engage in conversation if it’s anything more than “good.” Ninety-nine percent of Americans will then ask you how you’re doing. Take this and run with it and show them you do something besides work. “Man, I’m so glad I got out on my early morning bike ride today,” is one I’ll use. Or “I got to see my nephew take his first swim lesson this week, which was awesome.” Don’t force it, but be prepared for a 5 or 10 minute conversation.

Setting and getting the context

When you get on the line, your user will be wondering two things: what are you going to ask them and how will you use that information. Tell them up front. Tell them your position, tell them what you’re working on broadly, tell them why you’re conducting this interview, tell them how this will directly impact the product you are responsible for.

Also understand who they are. If they’re in an enterprise, what’s their role? Who do they report up to? If they’re a consumer, what are their demographics, where do they work etc? This info is super helpful to you in triangulating the information coming from the dozens of users you interview and will signal to the user that you care about who they are.

Working off an interview guide

Definitely absolutely 100% of the time build an interview guide – a written list of the questions you will ask and the points your are trying to hit on during an interview. The guide should get at the main questions you want to ask your users. It serves several purposes: it helps keep you on track during an interview; it allows other team members to give input into the questions asked ahead of time; it allows others, when reviewing your interview write-ups to understand what questions you were asking to get the answers users gave you. Asking “how great is Mark” will get you quite different answers from “tell me about times Mark wasn’t great”.

Specifics get you to needs

The key to a user interview is using specifics to get to underlying needs. If someone mentions that they really want a particular feature, dig way into that. What would they do with that feature? What does their workflow look like now? Why? What’s the underlying problem they’re trying to solve? How common is that problem? How does it attach to other problems they need to solve? Are there other solutions they’ve used to go after similar problems? How do they like those?

One great way to get to specifics is to ask users to share a screen that they’re looking at and talk you through it. Design researchers will of course do this all the time, but for your purposes it can be super helpful as a conversation prompt. Take screenshots of the screens they’re showing you and stick those screenshots in your writeup. When you have to illustrate a concept later for the rest of the company these screenshots are super valuable.

Stay light on your feet and look for surprises

One classic problem with the user interview is that you dig down into the details of the problem in front of you and miss the larger forest for the tree you are looking at. It’s important to let the user wander a bit and do the things you need to do to see the edges of the problem, to see the fuzzy future world that is not yet in existence and that your competitors have not yet grasped. This goes to the heart of the creativity inherent in product management.

One very tactical way to do this is to look for surprises. I always try to imagine the most surprising or pernicious way that someone could use the product and probe gently around that to see if users are doing it. Often, they are. These surprises and the insights into human behavior that come with them are part of what make product management fun. They can also alter the course of how you build your product.

In one example, I was in charge of rebuilding the dashboard experience for an enterprise software company. Our users made a lot of use of dashboards, mostly for displaying status lights that indicated a green/yellow/red status for various parts of their software environment. I said to myself wait, what if users are using the status lights to obfuscate status rather than display it. I started asking questions and – aha! – customers started telling me that they rarely or even never wanted a red light to show on a dashboard executives might see so they did a bunch of work to avoid that outcome. That changed how we thought about status lights in our product.

Involving other team members

Bringing your team along is an important aspect of good product management. Having them sit in on the interviews is a great way to do that – it makes everybody feel more involved than if they listen to recordings after the fact. I add designers and developers as optional to almost all my user interviews and encourage them to attend and ask a few questions. I sometimes make an exception and take the calls on my own when I am just getting started on a subject and I’m still tweaking my questions and approach so that I don’t feel unnecessary group pressure to sound smart.

Writing it up

The writeup is all-important. It is the reference document that you and others in the company will use to understand the context, information learned and of the customer conversations you’ve had. I keep a running Google doc with my user interview write-ups that I share broadly within the company. It can be bullet-pointed format as long as it would be pretty clear for a naïve reader to pick up the doc and understand what you’re getting at.  If you’re making recordings, it’s also worth saving those in case someone wants to verify your writeups – interpretations of what someone said can for sure vary.

The writeup should contain 4 elements:

Date and people

Include the date, location, people on the line and their positions/reporting structure.

Overall message

What are the takeaways from the customer? What are their needs? How are they being met now? How do they, in their role, view success over the next few years if they are in an enterprise? How do they view their personal goals over the next few years if they’re a consumer? What are their priorities for their business (enterprise)? For their life (consumer)? For your product?

Specific asks

What do the users specifically ask for? What functionality? Why? What underlies the ask? Have they seen this functionality elsewhere, like in a competitor’s product?

Screenshots

These are super helpful for your audience to grasp the context of your conversation with the user. You don’t need too many, but a few relevant screenshots add depth to your writeup.

Closing thoughts

Remember that one of your most important functions as a PM is to bring clarity and truth to swirling debates about what your team should build. You will find that the truth is shockingly hard to agree on, so the more documentation you have, the better. For example, how a question was phrased can be just as important in understanding answers you hear as the phrasing of the answer itself. I find recordings of user interviews invaluable as a source of truth when there’s some debate about what users actually meant.

This divining of user meaning and needs – and being a faithful reporter of it – is your main function as a PM. You should think of yourself as 80% customer needs diviner and 20% engineering team organizer. The user interview is the most important thing you can do to divine those needs.