How to Prepare for a User Interview
The Why, The Who, The Script and discovering actual user problems
“Build something people want” starts with knowing what people want. There’s no better way of knowing what people want than by talking to them. As a Product Manager, it’s your job to empathise with users and paint a clear picture of their problems. It’s not an easy job. There are tools and frameworks to help with discovery, but probably none as powerful as User Interviews.
User interviews are conversations with your product’s users, with the objective of uncovering user pain, understanding problems, and aligning your mental model of user personas with reality.
As a part of my onboarding onto a Product Management role, I’ve participated in quite a few user interviews over the past few months, and have recently started playing a more active role — starting threads of questions and driving the conversation. In all honesty, it’s terrifying the first few times. Despite reading a ton of material on what are good questions that one should ask, and common pitfalls to avoid (Pointing at The Mom Test and a hundred different blog posts), when you’re actually running an interview, theoretical knowledge goes out of the window, and it takes conscious effort to not discuss hypotheticals, crave approval, or throwing potential solutions at users to see what sticks.
One realisation, obvious in hindsight, has been that a key to a successful user interview is how prepared your are going in. Preparing well is not hard, but it does require a little discipline, and some intuition. In this article, we’ll cover a handful of points that I’ve personally found helpful.
Take. Time. Out.
I get it. You’re busy. But to make the most of the 30 minutes you have with a user today, block a reasonable amount of time to prepare. A rule of thumb I’ve been trying to follow is a 4x allocation, where I take out 2 hours to prepare for a 30 min call, to answer the Why? the Who? and to draft a script for the interview.
Why?
Why do you want to conduct this user interview? What do you aim to get out of it?
Improved understanding of your users’ problems, right? Well, yes. But a little more articulation goes a long way in making the interview more specific and less hypothetical.
Are you looking to validate a certain hypothesis? Are you hoping to figure out the journey of a particular segment of users? Are you trying to uncover the points of friction in a particular flow on your product? Having clear, written answers to these questions helps.
This also acts as a great guardrail to steer the conversation and maximise the probability of stumbling across insights for your queries.
Who?
Who is the user you’re speaking with today? How long, and how frequently, have they been using your product? What are their most common use cases? What issues / feature requests / complaints have they raised before? What have they appreciated? What does a day in their function look like? When it comes to deriving value from your product, what does success mean for them?
Finding answers to most, if not all, of these questions, before the interview helps build a user profile, and in turn, helps your write a script that can boost the quality of your takeaways.
I work at Enterpret, where we help customers learn from their users’ feedback. We have an instance deployed that we can Enterpret on Enterpret — it’s built on the feedback that our own customers have shared about Enterpret. I spend a significant amount of time before any user interview doing three things:
I find, and consume the feedback shared by the particular user. Enterpret makes this easy, because I can just search for the user’s name / email and consume summarised insights, and quickly get a gist of their voice, along with relevant quotes.
I watch their user sessions on Full Story to get a subjective of understanding how they use our product.
I analyse their quantified product usage on Amplitude to get a wider perspective of their frequency of usage and different journeys.
This exploration, while time-taking, tremendously helps understand the user better. Which in turn helps ask more relevant questions, and elicit specific answers and user stories.
Script
User interviews should not be scripted. It’s not a series of questions and answers. If you end up following a written set of questions, down to the letter, you probably did not do a very good job. Yet, it’s a good idea to have a script to ground your conversation. The nuance here is how this script is structured, and how it should be used.
Your interview script should be a collection of relevant open-ended prompts that help start conversations where your users feel encouraged to share specifics of their experience of using your product — the good, the bad, and especially the ugly. The Why? and Who? from the last two sections are the basis of this script, and as for framing questions, Eric Migicovsky’s framework is a must-watch pre-requisite, in my opinion.
Team Up
As humans, we are biased. As Product Managers, we are biased. It’s immensely helpful to have someone else in the room. Your colleague can help take notes, keep an eye on the clock, jump in with interesting perspectives and questions, and above everything else, when you’re discussing takeaways, help you check your biases as you distill your thoughts.
Breathe
Relax. You’re talking to fellow human being. Ask them about their day, share what your dog did this morning. Have an actual, pleasant conversation. When you think about it, it’s a such a positive setting! Here’s a person who believes in your ability to help solve their problems, and is willing to share their views and insights with you to help you build a product that people want! Make the most of it.
That’s it! I hope you found this post useful. I’ll work on sharing what I’ve been learning on the best practices to follow during a user interview, and some thoughts on distilling takeaways after one in the coming weeks. Do share your thoughts and comments!