How to Do User Interviews That Actually Teach You Something

User interviews are the highest-information-density activity available to a product founder. One hour of good conversation replaces weeks of analytics speculation. The problem is that most founders run interviews that produce low-quality signal — they ask leading questions, hear what they want to hear, and leave the call feeling validated when nothing has actually been learned.

Here's how to do them correctly.

Quick answer: Run 5 interviews per audience segment — active customers, churned customers, and unconverted trials separately. Ask about past behavior ("walk me through the last time you dealt with X") not hypotheticals ("would you use a product that does X"). Wait 5 seconds after each answer before asking the next question. Write up the 3 most important learnings within 24 hours of each call.

The fundamental rule: you are not pitching

The moment an interview becomes a pitch — the moment you're trying to convince the person that your idea is good — the data quality collapses. People are polite. They will tell you what you want to hear. They will say "yes, I would definitely use that" to avoid awkward silence.

Your job in a user interview is to understand their world, their problem, their current behavior, and their constraints. Not to present your solution. Not to get them excited. Not to close them.

Who to interview

For a pre-product interview: talk to people who you believe have the problem you're solving. Not friends who want to support you — people who actually deal with the problem regularly.

For a post-launch interview: talk to three groups separately.

1. Active paying customers (who got value — why did they buy, what problem does it solve, what's still missing?)
2. Churned customers (who left — what failed, what did they switch to, was the problem real?)
3. Trial users who didn't convert (in between — what made them try it, what held them back from paying?)

Each group teaches you something different. Don't mix them.

How to recruit interviewees

For pre-product research:

• Post in communities where your ICP is active ("I'm researching how [type of person] handles [problem] — 20 minutes, I'm not selling anything, just learning")
• Reach out to LinkedIn connections who match your ICP
• Offer a small incentive ($20-30 gift card) for your time — it increases response rate and attracts people who will actually show up

For existing customers:

• Email: "We're doing 20-minute research calls with customers to make the product better. [Link to schedule]." Aim for 5-10 calls per round of research.
• In-app trigger after a key action (first export, 10th login, etc.)

Target: 5 interviews per distinct audience segment before you start seeing diminishing returns. You'll start hearing the same themes after 5 — that's when you have enough to act on.

Structuring the interview

Opening (2-3 minutes): Set expectations.

• "Thanks for your time — this is a research conversation, not a sales call. I'm going to ask you about how you do things today, not pitch you anything."
• "I'm going to take notes so I can be fully present in the conversation. Is that okay?"
• "If any question isn't relevant to you, just say so — that's useful information too."

Context (5-10 minutes): Understand their situation before drilling into the problem.

• "Tell me a bit about your role and what your day-to-day looks like."
• "Where does [problem area] show up in your work?"

Problem discovery (15-20 minutes): Go deep on the specific problem.

• "Walk me through the last time you dealt with [problem]. What happened?"
• "How do you currently handle that?"
• "What's the most frustrating part of that process?"
• "Have you looked for solutions? What did you try? Why didn't it work?"
• "What does it cost you when this doesn't work well?" (time, money, stress, risk)

Retrospective (5 minutes): Pull insights.

• "If you had a magic wand and this problem was solved perfectly, what would that look like?"
• "On a scale of 1-10, how important is solving this compared to everything else on your plate? Why that number?"

Close (2 minutes):

• "Is there anything you think I should have asked that I didn't?"
• "Is there anyone else dealing with this problem who you think would be worth talking to?"

The last question is your referral engine — users who find your research valuable often refer you to 1-2 other people who have the problem.

Questions to avoid

Leading questions: "Would you say X is a problem for you?" — forces a yes/no, anchors their answer.

Hypothetical questions: "Would you use a tool that did X?" — hypothetical behavior is unreliable. Future behavior predictions are almost always too optimistic.

Feature validation questions: "Would you use a feature that does X?" — again, hypothetical and leads to false validation.

Opinion questions: "What do you think of this idea?" — invites social niceness, not honest assessment.

What to ask instead: "Tell me about the last time you [behavior]." Specific, past-focused questions produce accurate, detailed answers. Hypotheticals produce wishful thinking.

How to listen correctly

Take sparse notes: If you're writing everything down, you're not listening. Write only quotes and key observations, not paraphrases.

Embrace silence: After they finish answering, wait 5 seconds before asking the next question. People often add the most honest detail in the silence when they're not sure if they're done.

Follow surprising answers: The most valuable moments in an interview are when someone says something unexpected. Follow those: "That's interesting — tell me more about that."

Don't defend your idea: If they describe a problem your product doesn't solve, or criticize an approach you're taking, suppress the urge to explain. Note it and ask more questions.

After the interview: capturing the insight

Within 24 hours of each interview, write:

1. The 3 most important things you learned
2. The single most surprising moment
3. Any direct quotes worth saving verbatim

After 5 interviews, look for patterns across all of them:

• What problem came up in every conversation?
• What current solution did everyone hate?
• What outcome did everyone describe when talking about their ideal world?

Those patterns are your product signal.

How to avoid confirmation bias

The default human mode is to hear evidence that confirms existing beliefs and discount evidence that contradicts them. In user interviews, this is deadly.

Practical counter-measures:

• Record the calls (with permission) and listen back — you often hear things you missed in the moment
• Have a second person on the call whose only job is to listen and note things you miss
• Before each round of interviews, write down the three things that would most change your mind — then actively watch for those signals

---

Frequently Asked Questions

How long should a user interview be?

30-45 minutes is the sweet spot. Under 20 minutes is too short to go deep on anything. Over 60 minutes loses focus and fatigues the interviewee.

Should I record the interviews?

Yes, with permission ("Do you mind if I record this for my own reference? It won't be shared"). Recordings let you review specific quotes and catch things you missed in the moment. Most people say yes.

How many interviews before I have enough to make a decision?

5 per audience segment. After 5 interviews you'll hear recurring themes. After 10 you're mostly confirming what you already heard. Diminishing returns kick in quickly — the goal is speed to insight, not comprehensive research.

What if interviewees are too polite to be honest?

Ask about past behavior, not hypothetical future behavior. "When was the last time you had this problem" produces honest answers. "Would you use a tool that solved this" invites people to imagine an ideal, optimistic version of themselves. Behavior beats intent every time.

Should I show them a prototype?

Not in a discovery interview. Showing a prototype changes what people say — they start reacting to your solution rather than describing their problem. Run discovery interviews (understanding the problem) separate from usability tests (evaluating your solution).

---

Find product research and feedback tools at tools.cafe.