Most founders think they're running user interviews. What they're actually doing is giving presentations with a question mark at the end. "We're building a tool that does X — does that sound useful?" "Would you use something like this?" "How much would you pay for it?"
How to Run User Interviews That Actually Reveal the Truth
These questions feel like research. They produce useless data. People are polite. They say yes to things they'll never use. They quote prices they'll never pay. And the founder walks away from 10 "positive" conversations believing they've validated something, when they've actually just confirmed that people are nice.
User interviews done well are one of the highest-leverage activities in early-stage product development. A single 45-minute conversation, conducted correctly, can surface an assumption you've been building on for months that turns out to be wrong. That conversation is worth weeks of development.
The difference between interviews that reveal the truth and interviews that confirm your biases is almost entirely in the question design and the facilitation technique. This article gives you both.
Ready to Run a Discovery Phase?
We'll turn your idea into a scoped, validated product plan in 2 weeks.
The Core Principle: Ask About the Past, Not the Future
The single most important rule in user research: people cannot accurately predict their future behavior. If you ask "would you use this?", you're asking for a prediction. Predictions are systematically optimistic because they're costless.
Ask instead about what has actually happened. "Tell me about the last time you had to [problem your product solves]." "Walk me through what you did." "What did you try first?" "What happened?" Past behavior is anchored in real events. It's infinitely more reliable than future speculation.
This principle, developed by Rob Fitzpatrick in The Mom Test, is the foundation of every good interview technique that follows.
The Five Questions That Open Up Honest Answers
Start every interview with a broad scene-setter, then drill down with these five question types:
- "Tell me about the last time you..." — grounds the conversation in a specific, real event rather than generalities
- "Walk me through exactly what you did" — the detail in the walkthrough reveals the actual workflow, not the idealized one
- "What did you try before that?" — reveals existing solutions and how much the problem actually bothers them
- "What was the hardest part?" — surfaces the real pain point, which is often different from the stated problem
- "What did you end up doing?" — shows the workaround or resolution; a sophisticated workaround suggests strong motivation to solve the problem
Notice that none of these questions mention your product. You're not pitching — you're understanding. The moment you introduce your solution, you contaminate the data. The participant starts giving you feedback on your idea rather than information about their problem.
The Five Questions to Never Ask
Equally important: the questions that will destroy the quality of your interviews.
- "Would you use X?" — hypothetical; produces meaningless optimism
- "How much would you pay for X?" — people systematically understate willingness to pay in interviews; ask about what they currently pay instead
- "What features would you want?" — users are bad at specifying solutions; they're good at describing problems
- "Don't you think X is a problem?" — leading question; you've already told them what answer you want
- "Did you like the design?" — politeness bias; you'll hear yes regardless
Running the Interview: Structure and Facilitation
A 45-minute user interview has a predictable structure:
Minutes 0–5: Context setting. Introduce yourself, explain the purpose ("I'm trying to understand your current workflow — there are no right or wrong answers"), and confirm you'll record (or take notes). Make clear you're not demoing a product.
Minutes 5–35: The main exploration. Start with the broad scene-setter and follow the participant wherever they go. Resist the urge to fill silences — a 3-second pause after an answer often produces the most valuable follow-up the participant offers.
Minutes 35–45: Closing. Ask: "Is there anything about this topic that I haven't asked about but should have?" Then: "Is there anyone else you'd recommend I talk to about this?" The referral question is the most underrated part of user research — satisfied participants refer you to their network.
Startup Idea Validation: How to Do It Right in 5 Steps
Article by:
LogicCraft
How to Listen for Signal vs. Noise
Not everything a participant says is equally valuable. Learn to distinguish:
High-signal responses:
- Specific stories with named people, dates, and consequences ("Last Tuesday my manager asked me why the report was wrong again...")
- Emotional language ("I hate this so much" / "This saved my life")
- Current spending — money they already pay to solve the problem
- Workarounds they've built themselves (a system of 14 spreadsheets is a very good signal)
Low-signal responses:
- Generalities ("Usually I just..." / "Typically we...")
- Conditional predictions ("If it was cheap enough I'd probably...")
- Compliments on your idea or your questions
Synthesizing What You Heard
After every interview, spend 15 minutes writing a summary while it's fresh. Don't transcribe — synthesize. What were the two or three most important things you learned? What surprised you? What contradicted your assumptions?
After 10 interviews, lay all the summaries side by side and look for patterns. What words come up repeatedly? What problems do multiple participants name unprompted? What workarounds appear in more than three interviews?
The pattern that emerges is your validated insight. It's not what you thought going in — it rarely is. But it's real, and building from it is significantly more likely to produce a product people actually use.
The best discovery phases are built around this kind of systematic, rigorous user research. If you're building without it, you're building on assumptions.
By clicking "Accept" you agree with our