Problem Discovery

Finding problems people actually have, instead of starting from a solution.

Also known as: problem discovery, customer discovery, problem exploration

Problem discovery is learning what problems people have before deciding what to build. Engineers instinctively start from a solution (“an app that does X”); discovery inverts it — live inside the problem space until a painful, frequent, expensive problem shows itself, then build the smallest thing that relieves it.

solution-first:  build X → search for someone who wants X (usually nobody)
problem-first:   watch 10 people work → find the painful workaround → remove it

Good discovery looks like fieldwork, not surveys: watch people do the job, ask what they tried, what it cost, what broke. Pain that people pay to relieve — with money, time or ugly workarounds — is demand wearing a disguise. Complaints without budgets are entertainment.

The classic mistakes:

Asking “would you use this?” People are polite about imaginary products and honest about past behavior. Ask what they did last time, what it cost, what they tried instead (see the Mom Test).
Discovering from friends. Friends encourage; strangers with budgets decide. Talk to people who can buy, especially early adopters already hacking around the problem.
One conversation, one conclusion. A single angry user is an anecdote. Patterns across ten-plus conversations are evidence — write each one up the same day or it blurs.
Falling in love with the first problem. The first pain you find is rarely the best one. Collect several, then pick by pain × frequency × willingness to pay.

Done looks like: a written list of candidate problems, each with who has it, how often, what it costs them, and what they do today — ranked, with the riskiest assumption flagged for testing first.