Discovery & Signal
Finding real problems, user research, separating noise from insight
1
Research That Changes Minds
No hypothesis, no research — just confirmation in disguise.
Before you talk to any user, write down exactly what you believe to be true and what would have to happen for you to be wrong. If you skip that step, the research will just be a conversation, and conversations don't change roadmaps. The goal is to be surprised, not confirmed.
2
The Real Problem Protocol
Stated problem is the symptom. Story is the diagnosis. Build the cure.
When you talk to users, don't just ask what they want — ask about the last time they faced this problem, what they tried, and what happened. People rarely describe their real need directly; they describe the surface frustration. Your job is to listen for the story underneath the complaint.
3
Problem-First Validation
Fall in love with the problem. Strangers, not friends. Energy, not agreement.
Before building anything, you need to confirm that a real problem exists for real people — not just your friends and family who will be polite. Talk to at least 20 strangers and watch for genuine energy, not just agreement. If people say 'oh I know someone with that problem,' it's probably not a real problem; if they lean forward and say 'wait, is this actually available?' you're onto something.
4
Problem-First Value Test
Real problems correct you. Nice-to-haves refer you.
Start with the problem, not your solution. Talk to at least 20 strangers about the problem — not friends or family — and watch how they react. If they say 'oh I know someone with that problem,' it's probably not real enough; if they lean in and start correcting your description of the problem, you're onto something worth building.
5
Signal Over Validation
Seek the surprise, not the confirmation — the secret is earned by being wrong faster than anyone else.
Discovery isn't about proving your idea is right — it's about finding out where you're wrong before you waste months building the wrong thing. Keep a living document of the top 10 real problems your users face, update it every quarter, and make sure your engineering and design partners can recite the same list. If everyone can name the same problems, you've done your job.