Why you should interview your users
Talking to users at all stages of your company, particularly at an early-stage is critical and hugely impactful. How you talk to your users to collect and what you do with that feedback can mean the difference between finding product market fit, or folding up.
A bit extreme, but it has happened. Lots of companies end up falling for the trap of building whatever the customer wants, and what they want is not always clear or really solving the root of their problems.
This is why at the core of a great user interview is learning about their life and the specifics around the problems you’re trying to solve for them. You need to extract information from the person that you’re talking to, turn it into data, validate that data, then turn it into product improvements.
“When we were developing the automobile, our users would have wanted a faster horse rather than a car.”
Henry Ford
A big problem that product managers, customer success, or even founders face when interviewing users is how to validate the feedback. Here are some common pitfalls to avoid.
Pitfalls to avoid during a user interview
Doing all the talking
It can be super easy to fall into the trap of doing all the talking. Sometimes a user gives one word answers. Sometimes we’re nervous and start blabbing too much to break the ice or ease into the interview.
Don’t do all the talking. In a user interview, try to restrain your interest in talking and really listen. Take notes and listen to what the user is saying because, in that span of the 10-30 minutes, you’re trying to extract as much information as possible so you’re collecting enough real facts and data about users’ lives to validate.
Talking about your product
Might seem counterintuitive, but it’s actually not the time to talk about your product during a user interview, and especially not the time to sell them on your product. It’s super easy to fall into this trap, especially when your a founder doing the interview because you are so used to pitching the product. Keep focused on the user, their life, and the problems they face.
Talking about hypotheticals
YCombinator shared some data around user interviews and it turns out that, in general, users are not that great at identifying future product features that will help solve their problems.
This is why it’s recommended to not talk about hypotheticals, such as if we built this X feature, would you be interested in using it?
Instead, talk about specifics that have already occurred in the user’s life. This will give you stronger and better information in which to make product and company changing decisions.
Don’t just talk about the specific solution that you’re presenting. Ask about the path that led them to encounter problem. Ask them questions about their life in more broader ways to extract context around how they arrived at this problem. Learn about their motivations. Learn about why they got themselves into that problem in the first place.
Five questions to ask during your user interview
“What’s the hardest part about doing the thing that you’re trying to solve?”
The first question helps you validate whether the problem that you’re working on is actually one that real users feel is a pain point. You are searching for problems that your users face on a regular basis, or problems that are painful enough to warrant solving.
“Tell me about the last time that you encountered this problem.”
The second question is about trying to get to specifics rather than hypotheticals. The goal of asking this question is to extract more context around the problem and better understand the different circumstances the user has encountered that problem.
“Why was this hard?”
The third question is may seem redundant, but it’s key because we narrowing down to a specific circumstance when the user felt the problem. Their answers can reveal what is really causing the problem to occur, and you’ll hear many different answers from different people.
“What, if anything, have you done to try to solve this problem?”
If users haven’t attempted very much to find potential solutions to their problem, it could be a sign that that the problem isn’t painful enough. If the problem isn’t painful enough, then it may not be the best use of your resources to find product market fit.
This question is one way of validating the problem and how severe it is. It tries to get to the root of the issue, is this problem painful enough that this user is already trying to solve it? What tools did they experiment with? Are other users saying the same thing?
“What don’t you love about the solutions that you’ve already tried?”
The fifth question can be the very beginning of your potential new feature set. Here you can start to understand what specific features you’ll want to consider building to better your solution and solve the users problem.
2 Responses