| name | product-discovery |
| description | Finds out whether a problem is real and a solution would work, before building it — recruiting the right people, interviewing without leading them, separating what users say from what they do, naming the riskiest assumption and testing that one first, and reaching a decision rather than a summary. Use this to validate a problem, test an idea cheaply, decide whether to build something, or fix a discovery process that keeps confirming what the team already believed. |
Product discovery
Discovery is how you find out you were wrong while it is still cheap. A process that never kills
anything is not discovery, it is a preparation ritual with research attached.
Start from the assumption that would sink this if it were false
Every idea rests on a stack: that the problem exists, that people care enough to change what they
do, that your approach solves it, that they would pay, that you can build and deliver it. They are
not equally uncertain, and testing them in order of comfort is how teams spend six weeks confirming
the safe one.
Write the assumptions down, mark the one that would be most damaging to be wrong about, and test
that one first. Usually it is the second: the problem is real, and people are living with it
comfortably enough not to move.
Recruit the people who have the problem, not the people who are easy to reach
Interviewing your friendliest customers produces reliable encouragement. Talk to people who churned,
people who evaluated and chose something else, and people who solved it another way — those three
groups carry most of the information.
Five to eight conversations in a segment usually exhausts the new material. If you are still
hearing new things at eight, the segment is too broad.
Interview about the past, not about the future
People are poor at predicting their own behavior and generous when asked to react to an idea. They
are reliable narrators of what they actually did.
- Ask about the last time it happened. What triggered it, what they tried, what it cost them,
what they did instead.
- Follow the workaround. A spreadsheet someone maintains by hand every week is stronger
evidence of a real problem than any amount of enthusiasm about a proposed feature.
- Do not describe your solution until the end, and treat everything said after that point as
weaker evidence.
- Silence is a tool. Most of the useful material arrives after the pause you were tempted to
fill.
"Would you use this?" and "would you pay for this?" produce answers that do not predict anything.
What predicts is whether they have already spent money or time on the problem.
Weigh what people do over what they say
Rank evidence honestly: what they have paid for, what they have built themselves, what they do in
an unprompted usage log, what they say in an interview, what they say in a survey. A prototype
someone tries in front of you sits high on that list; an enthusiastic reaction to a mockup sits low.
Test with the cheapest thing that could produce a real signal
Match the artifact to the assumption. Demand risk is testable with a landing page or a sales
conversation, usability risk with a rough prototype, feasibility with a spike. Building a working
version to test whether anyone wants it is the expensive way to answer the cheap question.
Define the outcome that would change your mind before you run it. A test with no failing threshold
is a demonstration.
End with a decision
Discovery output is build, do not build, or a specific next test — not a deck of themes. Write what
you learned, what you still do not know, and what you are doing about it, and keep the record of
the ideas you killed and why. That record is what stops the same idea returning every six months.
Never
- Test the assumption you are most confident about first.
- Ask whether someone would use a thing instead of what they did last time it came up.
- Recruit only from customers who already like you.
- Run a test with no threshold that would have counted as failure.
