Discovery & validation
Knowing you're building the right thing before you build it.
The short version
Discovery is the work of replacing assumptions with evidence before you commit engineering time. The goal is not to "do research", it is to find the cheapest test that could prove you wrong. Talk to real users, watch them work, and look hardest for the disconfirming signal. A week of discovery routinely saves a quarter of building the wrong thing.
Why it matters
Most failed products were built competently, they just solved a problem nobody had badly enough to change behavior. Discovery is how you avoid that: you separate what customers say they want from what they actually need, and you do it while changing your mind is still free.
The trap is treating discovery as a phase you complete, or as theatre that confirms what you already decided. Good discovery is adversarial toward your own idea. You are not looking for permission to build; you are looking for the fastest evidence that you should not.
How to run it
Common mistakes
Asking leading questions and hearing the answer you wanted.
Confusing a vocal minority for the market, a few loud requests are not representative signal.
Validating the solution before validating the problem.
Treating discovery as a one-time gate instead of a continuous habit through the lifecycle.
In a startup
Discovery and building blur together, you are learning in public with real users. Bias to shipping a scrappy slice to a few customers over weeks of upfront interviews; the market is the only validation that fully counts.
In an enterprise
You have scale and existing data others would kill for (support tickets, usage logs, CS contacts). Mine it, but still talk to real users directly; aggregate data tells you what is happening, not why.
Quick check
0/2Optional, find the right answer for each to complete the concept. Keep trying; nothing is gated.
1. What is the primary goal of discovery?
2. Which question surfaces real behavior?