product-discovery

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.