6 user interview tips I wish I knew earlier
Hello, fellow hackers!
Last week I had the first round of user interviews, trying to validate the importance of the product I'm building. After the single week of conversations with possible users, I now have a much better understanding of:
- How to position the problem & solution
- What customers' circumstance I need to target to sell
- Is this a problem worth solving
Frequently, when it comes to validation, people simply suggest "go talk to users.". But this advice alone says nothing about the goals of those conversations, how to structure them, and what's the right way to handle people's responses.
So here is a few insights I wish I knew when I was starting with user interviews. It should be especially relevant if you don't have the product ready and you want to figure out whether the problem is worth solving.
TLDR:
- Invalidate your hypotheses
- Dig deeper
- Less but better
- Have they tried to solve it before?
- Ask about the past
- Avoid attributes and labels
1. Invalidate your hypotheses
When you want to understand the problem people have, the best way to approach it is via hypothesis testing. For those interviews, your goals should be to invalidate the beliefs about the problem against reality.
That's important because if you're going to solve the problem for somebody, you need to have the same understanding of this problem.
Try writing down all the assumptions you're making about the problem and the circumstance people should be in for the problem to occur.
For example, here is how I described my assumptions for my product, CrossPatch (a tool for distributing product-related knowledge in the team).
2. Dig deeper
It's a good practice to be slightly skeptical about the user responses during the interview. If you want to get to the truth, don't hesitate to keep asking why multiple times (even if you think the person explained themselves clearly). It might lead to unexpected causality that could be helpful for you to understand while building a product for this problem.
3. Less but better
Sometimes it's not clear how many interviews you need to have to "fully" validate the problem. Is it 100, 1000s?
First of all, unfortunately, there is no such thing as full validation. The world is unpredictable, and we can't user test our wey to a successful product. Eventually, you'd need to build something and get practical feedback back.
But even a few high-quality interviews with relevant people can tell you a lot about the problem they experience and if the solution would be useful.
Here is my approximation: if after ten interviews I see general patterns on all the hypotheses I defined before talking with people – there is probably a small chance I'll be surprised after the next ten calls.
4. Have they tried to solve it before?
This one is a neat trick to understand if the problem is that painful. Ask people if they tried to solve this problem in the past. If they didn't even attempt to fix it – there is a high chance this problem is tolerable. They lived happily without solving it before and will continue doing so even when your product is out there.
But if they tried to solve it, that's a different story. That means people recognize the problem and willing to see a better way.
5. Ask about the past
In the interview, it's harder to lie, even unintentionally, about things that happened in the past. While when you ask questions about the future (e.g. Would you buy this product?) their response might not be representative at all. Because in the future, "anything can happen." we don't need to take responsibility now for the actions we will take.
6. Avoid attributes and labels
When you talk about the problem, try no to attach yourself to labels and other attributes. Labels, carry your beliefs. When you use them in conversation with other people, you expect them to interpret those labels the same way you do. It might not always be the case and will lead to misunderstandings.
For example, when I was talking about CrossPatch, I had to keep an eye on mentioning "As a Product Manager..." when talking about the problem. Because "Product Manager" as a job could mean a different thing for the person I'm talking to.
Hopefully, this would be helpful. If you're curious, here is the original thread with all those tips. I regularly document my thoughts on Twitter, feel free to follow if you like the content :)
