How do you talk to users without leading them?
The biggest mistake founders make in user research is turning interviews into a pitch in disguise — asking questions designed to get agreement rather than truth. Unbiased conversations require deliberate structure: ask about the past, not the hypothetical future, and stay quiet long enough to hear something that surprises you. The signal you're looking for is the thing users say that contradicts your assumptions.
Why founders accidentally lead users
The problem is psychological before it is methodological. Founders are deeply invested in their idea being correct. That investment leaks into every question they ask. 'Would you pay $10 a month for something that solved X?' is not a research question — it's a leading question dressed up as research. The user hears that you want them to say yes, and most people, especially friendly early adopters, will oblige. You leave the conversation feeling validated and having learned nothing.
The deeper trap is that you're not just leading users toward a particular answer — you're also leading them toward a hypothetical future that has never existed. Humans are notoriously bad at predicting their own behavior. When asked what they would do, they describe an idealized version of themselves. When asked what they actually did last Tuesday, they tell you the truth. This distinction — past behavior versus future intention — is the most important structural choice you make before an interview begins.
Paul Graham's observation about early adopters is relevant here: the earliest users of a successful startup are the hardest people to fool. That cuts both ways. If you're honest with them and ask genuine questions, they'll give you honest answers. If you're subtly fishing for validation, they'll sense it and play along — which is its own form of being fooled, just in a direction you didn't expect.
The architecture of a non-leading question
A non-leading question has three properties: it is anchored in the past, it is open-ended, and it does not contain the answer. 'Tell me about the last time you dealt with [problem]' satisfies all three. Compare that to 'How frustrating is it when [problem] happens?' — which presupposes frustration, presupposes the problem occurs regularly, and signals what emotional register you want the user to perform in.
The practical rule: if your question contains an adjective, a frequency word, or a solution noun, rewrite it. 'How often do you struggle with X?' should become 'Walk me through what happened the last time you did X.' 'Would this feature be useful?' should become 'How do you handle that situation today?' The rewritten versions put the cognitive load on the user to reconstruct reality rather than react to your framing.
Follow-up questions matter as much as opening questions. The most powerful follow-up in user research is silence. After a user finishes answering, most interviewers jump in to rephrase, clarify, or move on. Instead, wait three full seconds. Users will almost always fill the silence with something more honest, more specific, and more useful than what they said in their polished first answer. The second thing people say is usually the real thing.
What you're actually listening for
The goal of an unbiased user interview is not to collect positive or negative sentiment — it's to map the actual workflow users have built around a problem. That map will include workarounds, emotional moments, handoffs to other people, and points of resignation where users stopped trying to solve something and just accepted it as a fact of life. Those points of resignation are often where the best product opportunities live, precisely because users have stopped articulating the problem as a complaint.
Paul Graham's point about doing things that don't scale applies directly to interview quality: the feedback you get from direct, one-on-one, unmediated conversations with early users is uniquely valuable and impossible to replicate at scale. That means the time you spend doing it well — sitting with someone, watching them work, asking follow-up questions that only make sense in the moment — has compounding returns that a survey never will. Treat each interview as irreplaceable rather than as a data point to be aggregated.
Listen specifically for moments of contradiction: when what a user says they do differs from what they describe having done, or when their emotional tone shifts unexpectedly. A user who says 'it's fine, really' while describing an elaborate manual workaround is giving you a high-value signal. The cognitive dissonance between their stated satisfaction and their actual behavior is the gap your product needs to close.
Practical setup that removes bias before the interview starts
How you frame the interview invitation shapes the conversation before it begins. If you tell users 'we'd love to get your feedback on our product,' you've already primed them to be helpful and supportive. Instead, frame it as: 'We're trying to understand how people handle [problem area] — no product demo, we just want to learn about your experience.' This removes the social pressure to be encouraging about something you've built.
Record every session with permission. You cannot take good notes and listen deeply at the same time. When you're transcribing afterward, you will catch things you missed live — a hesitation, a reframing, a throwaway comment that turns out to be the most important thing said. Pattern recognition across multiple interviews only works if you have accurate records of each one.
Do interviews in pairs when possible, with one person asking and one observing. The observer's job is to write down direct quotes and flag moments that warrant a follow-up question. After the interview, compare notes before discussing interpretation. If two people came away with different readings of what the user said, that ambiguity is itself a finding — it means you need to go back and ask a cleaner question in the next session. Never let your interpretation of an interview become the official version without checking it against what was actually said.
When to stop interviewing and start building
User research has diminishing returns, and founders can use it as a form of productive-feeling procrastination. The signal that you have enough is when you can finish users' sentences — when the third or fourth person describes a workflow you've heard twice before and you can predict what they'll say about the point of failure. At that threshold, additional interviews confirm rather than expand your model, and the marginal value of building and watching someone use it exceeds the marginal value of another conversation.
The test of whether you conducted unbiased interviews is whether the answers changed your plan. If every user interview confirmed exactly what you already believed, something went wrong — either your sampling was too narrow, your questions were too leading, or you filtered out the contradictions in retrospect. Genuine user discovery almost always surfaces at least one finding that is uncomfortable: a segment you thought would care doesn't, a use case you didn't anticipate turns out to be the primary one, or the problem you're solving ranks third behind two problems you hadn't considered.
Bring that discomfort into your planning rather than rationalizing it away. The founders who build things people actually use are the ones who let what they heard in interviews override what they wanted to believe going in.
“The feedback you get from engaging directly with your earliest users will be the best you ever get.”
— Paul Graham, source
The one thing to do
Before your next user interview, rewrite every question so it asks about a specific past event rather than a hypothetical future — then stay silent for three seconds after each answer.
Frequently asked questions
How many user interviews do I need before I can trust my findings?
There's no magic number, but most experienced researchers find that patterns stabilize after five to eight interviews with users who share a common role or workflow. The right stopping signal is saturation — when new interviews stop introducing new findings — not a target count.
Is it okay to show users a prototype during an interview?
Yes, but sequence matters. Ask all your behavioral and problem questions before showing anything you've built. Once a user sees a prototype, the conversation shifts to reacting to your solution rather than describing their actual experience, and you lose access to the unfiltered problem space.
What do I do when a user says they'd use my product but I don't believe them?
Ask them to describe the last time they tried to solve the problem with something else. Willingness to act in the past is a better predictor of future behavior than stated intentions. If they've never tried anything, the problem may not be urgent enough to drive adoption.
How do I handle users who just want to be polite and agreeable?
Explicitly give them permission to be critical: 'The most helpful thing you can do is tell me what's missing or wrong — positive feedback is less useful to us right now than honest skepticism.' Then ask about specific past behaviors rather than hypothetical preferences, which makes politeness-driven distortion harder to sustain.
Sources
- Billionaires Build — Paul Graham
- How to Raise Money — Paul Graham
- Before the Startup — Paul Graham
- gstack: skillify/SKILL.md — Garry Tan
- Do Things that Don't Scale — Paul Graham