Discovery & Signal
Finding real problems, user research, separating noise from insight
1
Research That Challenges You
No hypothesis, no insight — just interesting noise.
Before you talk to users, write down exactly what you believe to be true and what would prove you wrong. If you skip this step, you'll have great conversations and learn nothing actionable. Then talk to real users repeatedly over time — not just once — so their problems feel personal, not statistical.
2
Stated vs. Real Problem Discovery
Ask about the last time it broke, not the next thing they want.
When you talk to users, don't just ask what they want — ask them to tell you about the last time they had this problem, what they did about it, and what happened. People are much better at describing past experiences than imagining future solutions. That story contains the real problem.
3
Problem-First Validation
Strangers who correct you are more valuable than friends who agree.
Before building anything, talk to 20 strangers who might have the problem you think you're solving. If the problem is real, they'll get excited, argue about the details, or ask where they can get the solution. If they just politely agree and move on, the problem probably isn't painful enough to build a business on.
4
Problem Gravity Test
Real problems correct you. Nice-to-haves refer you.
A real problem is something that genuinely disrupts someone's work or life, and they already know it. A nice-to-have is something that sounds good in a survey but never makes anyone's to-do list. The test: talk to 20 strangers about the problem — if they start correcting your description and telling you the real version of the problem, it's real. If they say 'I know someone who might care,' keep looking.
5
Earned Insight Discovery
Falsify, don't validate. Layer, don't headline. Earn the secret — don't assume it.
Discovery is not a phase you complete before building — it is a continuous habit. Start by maintaining a living document of the top 10 known problems in your product, updated every quarter. When you look at data, never stop at the headline number; always ask what that number looks like by customer segment, product line, or feature adoption.