The cheapest way to find out you are wrong. Twenty conversations cost two weeks; building the wrong thing costs a year.
10 min read · Level 1
Discovery converts a year-long expensive experiment into a two-week cheap one, and founders skip it because building feels like progress while asking feels like delay. Having the problem yourself makes you one customer, usually an unusual one — your tolerance, your workarounds and your budget are not representative. The cost of finding out you were wrong never goes down. It only moves from conversations to code.
Customer discovery is talking to people who have the problem, before and while you build, to find out what is actually true rather than what you assume.
It is not market research, not usability testing, and not selling. It is finding out how someone's day actually works.
Because the most expensive thing a founder can do is build something nobody wants, and it is also the easiest thing to do accidentally.
Twenty conversations take about two weeks. Building the wrong product takes six months to a year and produces no information — you learn only that nobody signed up, not why.
Discovery converts a year-long expensive experiment into a two-week cheap one.
A founder is certain that freelancers need better invoicing software. They plan four months of building.
Instead they do fifteen interviews first. What they find:
The product that comes out of this is completely different from the one they were about to build — and the last point tells them the single thing that must not be true of it.
Cost: two weeks. Value: four months not wasted, plus a much better product.
First-time founders often skip discovery because they are sure they already know — particularly when they have the problem themselves. Having the problem makes you one customer, and often an unusual one. Your workarounds, tolerance and budget are not representative.
The second mistake: treating discovery as a phase that ends. Discovery continues for the life of the company. The founders who keep talking to customers at scale are the ones who keep building the right things.
Before any conversation, list your assumptions about the problem, who has it, and what it costs them. This makes being wrong visible.
Not friends being supportive. People in the actual situation. Your own network, communities, cold outreach, introductions.
'Tell me about the last time this happened' produces facts. 'Would you use this?' produces politeness.
The moment you describe your solution, the conversation becomes about your feelings and the data stops being useful.
Memory rewrites conversations towards what you hoped to hear. Notes within the hour are far more reliable.
One conversation is an anecdote. Ten is a pattern. Twenty is a decision.
Before building anything, and continuously after. It never stops being valuable.
Do not use interviews to test a UI — that is usability testing, a different technique with a different script. And do not use them to decide details customers cannot know, like architecture.
Before building the full product, Dropbox published a short demonstration video showing how the file syncing would work. The response to the video — a large jump in the waiting list overnight — served as evidence of demand for something that did not yet exist, at a fraction of the cost of building it first.
Ask what the cheapest possible test of your core assumption is. It is almost never a working product, and it is often not code at all.
The recurring shape: a founder is certain the problem is X, runs fifteen interviews, and discovers the pain is adjacent — not invoicing but chasing late payment, not scheduling but the Sunday-night dread about Monday. The product that results is different from the one they were about to build, and better.
Expect discovery to change what you build, not confirm it. If fifteen conversations changed nothing, you were probably pitching rather than asking.
Create a free account to read the rest and apply it to your own startup.