Most pre-launch user research is theater, and the worst part is both sides know their lines. You ask "would you use something like this," and the person across the call — who is being nice, who has nothing at stake, who is imagining a product that doesn't exist — says yes. You write it down as validation. It isn't. It's a stranger being polite about a hypothetical.
I used to run these interviews religiously, because every product-strategy book tells you to. Talk to fifty users before you write a line of code. Find the pain point. Validate the problem before the solution. It sounds disciplined, and it photographs well on a whiteboard. But the actual output of ten discovery calls is ten people telling you what they think you want to hear, filtered through their own vague memory of a problem they haven't thought about since the call started. Nobody lies to you on purpose. They just don't have the information yet — because the information doesn't exist until the thing exists.
The thing interviews can't produce
What you actually need to know before building is behavioral, not attitudinal: will a person open this app a second time, will they pay for it, will they get stuck on the third screen and quit. None of that shows up in a conversation. It shows up in a session replay, a drop-off chart, a support ticket. A user can tell you with total sincerity that onboarding "makes sense," and then abandon it forty seconds in, because self-report and behavior are two different instruments measuring two different things.
The economics used to force the interview-first order anyway. If building the thing takes eight weeks and three engineers, you cannot afford to find out it's wrong after you ship — so you front-load the risk into cheap conversations and hope they catch the expensive mistakes. That trade made sense when building was the bottleneck. It doesn't anymore. A working prototype — real auth, a real database, a UI someone can actually click through — is now something you build in an afternoon with the right tools, mine included. Once the cost of a first version drops that far, the interview stops being cheap risk-reduction and starts being the expensive step. You're paying with weeks of calendar time to avoid a build that costs you a weekend.
What I do instead
Build the smallest real version of the idea, put it in front of three to five actual people who have the problem, and watch, don't ask. Not "what did you think" — where did your cursor hesitate, what did you click that didn't do anything, what did you try to do that the product didn't support at all. That last one is the gold: the thing they attempted without being prompted is a truer signal than anything they'd have told you in a hypothetical interview, because it's revealed preference instead of stated preference.
This flips the traditional research funnel, and it's worth being explicit about what changes:
| Interview-first | Build-first | |
|---|---|---|
| What you're measuring | Stated intent ("I'd probably use this") | Revealed behavior (they opened it three times this week, or they didn't) |
| Cost of being wrong | Low per-cycle, but you can be wrong for months across dozens of interviews | One build cycle, then the data corrects you fast |
| Best question to ask | "What's frustrating about how you do this today?" | "Show me the last time you tried to do X in here" |
| What it's good at finding | Whether a problem exists at all | Whether your specific solution to it works |
| Failure mode | Everyone's polite, nobody's honest, you build the wrong thing confidently | You ship something rough before you've earned trust, and it makes a bad first impression |
Notice the two rows don't cancel each other out — they answer different questions. Interviews are decent at confirming a problem is real. They're bad at telling you your specific solution is right, because your specific solution doesn't exist yet for anyone to react to honestly. That's the distinction most "talk to users" advice glosses over: it's usually good advice for problem discovery and bad advice for solution validation, and people apply it to both.
A founder I know ran fourteen interviews for a scheduling tool aimed at hair salons. Thirteen said the double-booking problem was real and painful. She built it. Adoption was flat. It turned out salon owners hated double-booking in the abstract but had already built brittle personal workarounds they didn't want to give up — something none of them mentioned, because nobody thinks to describe their coping mechanism unless you can show them a replacement and watch them refuse it.
Where the critics are right
This doesn't hold everywhere, and I'd be overselling it if I pretended otherwise. If the build is genuinely expensive to reverse — hardware, a regulated medical workflow, anything with a compliance review attached to every change — then the interview-first calculus flips back, because the cost asymmetry that makes build-first cheap simply isn't true there. A prototype you can throw away in an afternoon is a different animal from a device you've tooled a mold for.
The other place research earns its keep is enterprise sales with a long cycle. If your buyer is a procurement committee and your sales cycle is four months, you cannot "just ship it and watch" your way to a signed contract — you need to know before the build whether the thing even clears a security review, because a rejected deal six months in costs far more than any interview would have. And pure problem discovery, done early and cheap — sitting with someone while they do their actual job, not asking them to imagine a future product — is genuinely underused and genuinely useful. I'm not against talking to people. I'm against treating a polite hypothetical conversation as evidence, when a rough real build sitting in front of the same person for ten minutes would tell you the truth instead.
