The user interview is not the discovery
Interviews surface what people are willing to say. Discovery is the harder work: understanding what they mean, and what they never say at all.
The comfortable ritual
Product teams have developed a reassuring ritual around discovery. Schedule fifteen interviews. Build an affinity map. Present the themes. Call it validated. The ritual isn't wrong - it's insufficient, and treating it as sufficient is where most early-stage products quietly go off the rails.
What interviews measure
A user interview measures what a person is comfortable articulating about their own behavior, under social conditions that reward coherence and punish ambiguity. People describe their frustrations in the most acceptable framing available to them. They tell you what they tried, not what they felt. They describe the surface of the problem and leave the anxious, embarrassing, irrational part of it - the part that drives behavior - entirely unstated.
The gap between what someone says in an interview and what they do in the moment of choice is where most product bets are lost.
The structural question beneath the surface question
Every stated problem has a structural question beneath it. The user who says "I want a simpler budget tracker" is carrying a question that sounds more like "will I ever feel in control of this?" The founder who hears "simpler" builds a cleaner UI. The discovery that goes deeper finds that control is the variable - and that a completely different product architecture follows from that.
Reading what isn't said
The most important signal in a discovery conversation is usually not an answer. It's a hesitation. A subject change. The moment someone describes a competitor's product with more warmth than they described yours, then catches themselves. The thing they mention and immediately qualify with "but that's probably not important."
None of this shows up in a synthesis deck.
The discipline
Real discovery is an interpretive practice. It requires sitting with partial information and forming hypotheses about the human architecture underneath the stated problem - then pressure-testing those hypotheses against behavior, not only against more interviews. It's slower and less reassuring than a fifteen-interview sprint. It's also the only kind that produces a product with psychological truth.