A startup CEO’s guide to user interviews that produce real product learnings
I’ve been interviewing user and customers for the past 8 years when taking on the product lead role in our current startup, I realized that probably most of these hundreds of hours I’ve been getting it wrong. We’re working with a product strategy advisor, Markus Müller, who previously led product teams at N26, Circ, and is currently helping promising startups to get their product game straight. I could not be luckier to have his support, because he points out all the things that are wrong with how we and I approach product and the search for Product-Market-Fit.
In our last session he asked me a question to which I did not have a good answer: Do you think you’re getting enough out of your user interviews? Do you think you actually lead successful interviews? Interviews that actually deliver the learnings you need? Which questions do you ask? Do these reveal what you need to know about the user problem and how they currently solve it. I felt like I am falling into a deep dark hole. Obviously I don’t know if it works. Obviously I have asked myself the same question many times before since imposter syndrome is literally my go-to-issue.
So in order to get out of this mess, I have read the book “The Mom Test” and have tried to summarize all you need to know in order to make sure your interviews are better than 90% of all founder-user-interviews out there. It’s still worth reading the book, if you are a PM, a growth leader, a startup founder or a designer. However, this list of interview questions below is supposed to help you save some time when looking for the top interview questions that can help you to turn every encounter with a user into a successful learning opportunity. Before we get into it:
Overall, when running successful user interviews, you need to keep these rules in mind:
1. Talk about their life, not your product or idea.
2. Ask about specifics in the past instead of generics or opinions about the future.
3. Talk less and listen more (like 10% asking Qs vs. 90% listening)
Opening questions:
Let’s say you are building a product to help with X (a problem you are solving). These are great opening questions for a conversation:
- What are the big focuses and goals right now?
- What are the top 3 things on your mind when it comes to work/life/topic X?
- When was the last time you had/did X? What was it like?
- What’s the last thing you did with X?
Questions to find out more about the problem and their current alternatives (basically your competitive solutions):
- What did you do last time it happened? Talk to me about that.
- How are you dealing with X now?
- How did you resolve X back then? Walk me through your process.
- What did you like and hate about this current approach to solving X?
- How much time did it take you to solve X with this approach?
- Did you successfully solve X with that approach?
- How did you hear about your current solution to X?
- How did you find your current solution to X?
- What else have you tried?
Questions to find out whether it’s a real problem:
- How much did you pay for your current solution to X?
- Is X a big deal for you? What are the implications of X for you? Why do you bother?
- Have you tried searching for other, better solutions?
- Have you allocated a budget for the problem? How much is it? How much is that in % of your monthly total budget?
Questions to close the conversations with commitment and make the interview a successful one:
- Do you have time next week for follow-up call where we discuss your feedback on our solution to X/your team’s feedback on our solution etc.? (time commitment)
- Do you have time next week to give us feedback on wireframes? (time commitment)
- Would you like to try a product that solves X for the next 2–4 weeks? (time commitment)
- Could you intro me to Y that also experiences X in your circles/company/network?
- Would you be OK with sharing your experiences with X for a short testimonial/blog post?
- Would you be interested in pre-ordering our solution to X?
The more your users are ready to give up to get your product to solve X, the more you should listen to their input and take it seriously.
If you did not clarify what the next step will be after the meeting, the meeting was pretty much pointless. Your business is built on building relationships that are built on the exchange of value. If you stay on the surface of that and don’t actually commit to providing value and ask for value (time, reputation etc.) in return, it’ll die out sooner than later.
When you get feature requests from users, drill down on what’s the need and motivation for the request, don’t ever stop at the request by putting it into your backlog (I know everyone does that, I did too. It’s wrong.).
- Why do you want this feature?
- What does it allow you to do?
- How are you coping without it?
- Do you think we should push back the launch to add that feature or is it something we can add later?
- How that fit into your day (using that feature)? When and how would you use it?
Don’t ever ask these questions, because they don’t actually deliver any meaningful learnings:
Would you pay Y for a product that solves X?
This does not work because people will lie to you that they would pay something for it. There is nothing that they have to give up to back up their statement in that situation, so it’s very easy to just say stuff, w/o actually needing to commit to any of it. People mainly want to be nice to you, they don’t prioritize your learnings. That’s your job.
Would you buy a product that solves X?
Same as above, people can claim they would, but they don’t actually need to do anything, so it’s very easy to give in to the pressure of the social situation. After all they’ll tell you whatever you want to hear to be able to go on with their day.
Don’t pay attention to fluff that comes in shapes like these:
- Generic claims (I usually, I always, I never)
- Future-tense promises (I would, I will)
- Hypothetical maybes (I might, I could)
When you hear these types of statements aka lukewarm responses, this means that whatever you are trying to offer does not work, interest your user. They’re just not that into it (yet):
- Umm, I am not so sure about that
- That’s pretty neat
- Oh cool, let me know when you launch it
- That’s so cool, I love it!
- There are a couple of people I can introduce you to when you’re ready
- I would def. buy that
Turn that fluff into real learnings by following up with specific, past-focused questions:
- When is the last time that happened?
- Can you talk me through how you’ve handled that?
On the logistics of user meetings and interviews:
Pre-plan the top 3 most important things you want to learn from any given type of person: customer, user, investor, industry expert, key hire etc. Come up with good questions to find out those things and update the list as you go.
Informal is ALWAYS better than formal: Learning about your users and their problems in a comfortable, informal chat will enable you to take many more opportunities to learn and will make your users feel valued and that you’re interested in their problems.
Rule of thumb here is: If it feels like they’re doing you a favor by talking to you, it’s probably too formal.
It takes approx. 5 min to learn if that problem exists.
It takes approx. 10–15 min to understand their current workflow.
It takes approx. 1h to get an industry overview from an industry expert.
I hope this helps you to make your next user interview count and get actual product learnings out of, as well as de-risk your assumptions.
Thanks to Rob Fítzpatrick for writing a kick-ass book, that you all should read if you’re interested in building valuable products that find Product-Market-Fit.
Looking forward to your feedback, as well as all of your questions that have worked for you in the past to find out whether the problems that your products solve exist, whether your assumptions make sense and whether your ideas are viable.
