In the Think → Ship → Repeat cycle, the Think phase depends entirely on one asset: accurate signal. And the most corrupted source of signal in Product Management is the discovery interview.
The user who told you "I'd definitely use that" wasn't lying to deceive you. They were lying to protect you. And you designed every condition that made it easy for them to do it.
Understanding why interviews produce false signals isn't a research technique. It is a prerequisite for building anything real.
1. The Four Lies Users Tell
Not all false signals look the same. Users mislead in four distinct ways, each with a different root cause.
The Compliment: "This looks really great." This is the most common lie in discovery — and the least useful data point you will ever collect. Compliments are reflexive. They tell you the user is polite, not that the product is valuable. A compliment is not validation; it is the sound of someone not wanting to hurt your feelings.
The Hypothetical Promise: "I would definitely pay for this." Future intent is not evidence. When a user projects themselves into an imagined future, they are describing who they wish they were — not who they are. The gap between "I would" and "I did" is where products go to die.
The Courtesy Edit: "Maybe if you added a search bar, it would work for me." When users start suggesting features, they are often solving a different problem: how to give you something useful without telling you the real issue is the concept itself. Feature requests dressed up as feedback are one of the most seductive forms of false signal.
The Minimization: "It's not a huge deal, but..." The words before the "but" are a courtesy. Everything after the "but" is the only truth in the sentence. Users downplay friction because they don't want to seem demanding — and because they've normalized workarounds they have been living with for months.
2. Why You Are Building the Lie
The false signal isn't coming from the user. It is coming from the interview architecture you designed.
The Enthusiasm Tax: When you walk into a discovery interview visibly invested — demo slides ready, feature list prepared — the user reads your energy before you ask a single question. Their job, in their mind, becomes making you feel good. Every question you ask after that point is answered through the lens of: "What does this person need to hear?"
The Hypothetical Question: "Would you use a feature that did X?" is not a research question. It is an invitation to speculate. Users answering hypothetical questions are performing an act of imagination, not reporting lived experience. Imagination is optimistic. Reality is not.
The Confirmation Ladder: If your interview follows a logical path from problem to solution, you are inadvertently leading the witness. Each "yes" to an earlier question makes the next "yes" more likely. By the time you ask "would this solve your problem?", the user has already committed to a narrative of agreement.
3. Redesigning the Interview for Truth
Honest interviews are not about asking better questions. They are about building a different architecture from the ground up.
Past Over Future: Replace every hypothetical question with a behavioral one. Not "Would you use this?" but "Tell me about the last time you had to do this manually. What did you use?" Behavior that has already happened cannot be socially edited. It is the only data that costs the user something to fabricate.
The Invisible Conviction: Go into discovery interviews with your hypothesis held privately. No slides. No concept explanation. Ask the user to describe their world first. If their description surfaces the problem you are trying to solve — unprompted — you have real signal. If it doesn't, you have something more valuable: an early Kill Switch.
The After-The-Comma Rule: Whenever a user minimizes — "it's not a big deal, but..." or "it's fine, although..." — ignore the preamble and go directly to what follows the comma. That is the interview. Everything before it is politeness.
End on Behavior, Not Opinion: Close every session not with "What did you think?" but with: "Is there anything about your current workflow you've tried to fix and couldn't?" The user who has spent time, money, or effort solving a problem before your product existed — that user has a real problem.
4. AI-Augmented Signal Extraction
Even a well-designed interview produces noise. Patterns across interviews are where truth lives — and humans are poor at finding patterns without bias.
The Contradiction Detector: Feed your interview transcripts into an AI model and prompt: "Identify any instances where what the user said contradicts what they described doing in practice." The gap between stated preference and reported behavior is where the real insight is buried.
The Minimization Scanner: Ask the AI to flag every sentence containing a qualifier — "a bit," "kind of," "not really," "I suppose" — then extract what follows each one. This surfaces the friction points users buried under politeness.
The Signal vs. Compliment Sorter: Prompt: "From these transcripts, categorize each piece of feedback as either Evidence (describes a specific, past behavior or outcome) or Opinion (describes feelings, preferences, or hypothetical reactions)." If the Evidence column is thin, you don't have validation — you have enthusiasm. Those are not the same thing.
Build the Interview. Then Build the Product.
The Hypothesis Engine told you to turn expensive guesses into cheap experiments. But a hypothesis is only as good as the signal that tests it.
If your discovery interviews are producing compliments instead of evidence, you are not in the Think phase. You are in the Comfort phase.
The user who lied to you wasn't being dishonest. They were responding to the system you built. Rebuild the system — and you will be surprised how honest they become.