Start with the problem. Always.
A product is not an idea. A product is a repeatable solution to a repeatable problem that someone will pay to remove. Step 1 exists because most founders skip it: they fall in love with a solution before they can clearly explain the pain.
Don't mention your solution. Don't pitch. Don't “educate” them. Listen until the pain becomes obvious without your help.
When the pain is real, people:
- Vent and use emotional language.
- Give examples without being prompted.
- Quantify the cost: time, money, risk, stress.
- Admit the workarounds they hate but tolerate.
The one-sentence problem statement
Use this template:
[Specific person] experiences [pain], which leads to [meaningful consequence].
Examples:
- Small practices struggle to track onboarding steps, causing delayed start dates and lost revenue.
- Finance teams manually reconcile transactions, creating reporting delays and audit risk.
Separate the buyer from the user
- User: feels the pain day-to-day.
- Buyer: feels the cost of the pain and controls budget.
Always validate:
- Who complains about the pain?
- Who budgets to make it go away?
If the user screams but the buyer shrugs, you might have a “cool tool” and not a business.
Ask: “What happens if you do nothing?”
Listen for answers like:
- “We keep missing deadlines.”
- “Revenue is delayed.”
- “We risk compliance issues.”
- “People burn out and quit.”
Be cautious if you hear:
- “It's annoying, but…”
- “We've lived with it.”
- “It's not urgent.”
The Toothbrush Test
Google's co-founder popularized a simple heuristic: is this something people use as regularly as a toothbrush? The point isn't literal daily use. The point is habitual value.
Ask yourself:
- Does the problem show up frequently?
- Is it part of a routine workflow?
- Do people think about it unprompted?
Daily pain builds daily dependence. That's how products become sticky without begging users to stick around.
Validate with conversations, not surveys
In early validation, aim for 10–15 conversations with your target audience. Ask open-ended questions, then let silence do the work.
Questions that work
- “Walk me through the last time this happened.”
- “What did you try first?”
- “Where did it break?”
- “What did it cost you?”
Printable checklist
Use this to decide if you've identified a real problem that could become a product. If you can't check a box, that's not failure—it's a signal to interview more and sharpen the problem.
Problem Validation Checklist
Check boxes only if you can back them up with real conversations. “I think so” doesn't count yet.
Problem strength
Ownership & economics
Toothbrush test
Clarity
If you can confidently check 10+ boxes, you likely have a real problem worth solving. If you're below that, keep interviewing—your code editor will still be there later.
