I run a service business·I build them

Product Strategy

Finding Problems Worth Solving

Learn how to identify and validate real problems before writing a single line of code.

Ideas Are Cheap — Validated Problems Are Valuable

Every startup begins with an idea. Most fail not because of bad code, but because they built something nobody needed. The antidote: start with the problem, not the solution.

Before writing code, be confident that:

  1. The problem is real (people actually have it)
  2. The problem is painful (people want it solved badly enough to pay)
  3. You can reach people who have the problem (distribution is possible)

Four Ways to Find Real Problems

  1. Scratch Your Own Itch — Your personal frustration is a signal. If you experience the problem, others probably do too.
  2. Listen in Communities — Reddit, Hacker News, Twitter/X, Discord, GitHub Issues. Look for the same complaint from different people.
  3. Study Existing Solutions — Read 1-star reviews on G2/Capterra, study competitor feature request boards, find dissatisfied customers.
  4. Job-to-be-Done Framework — What is the customer actually trying to accomplish? What are they using today? What is frustrating?

Validating the Problem

Before building, talk to 20 potential users. Use the Mom Test:

  • "How do you currently handle X?" → reveals the real workflow
  • "How long does that take?" → quantifies the pain
  • "How much does that cost you?" → establishes willingness to pay
  • "When did you last encounter this problem?" → tests frequency

Listen for: specific stories, evidence they've tried other solutions, unprompted complaints, and quantification.

Red Flags

  • "Nice to have" problems — no urgency, no willingness to pay
  • No existing alternatives — often means no market
  • Can't find people who have the problem — distribution will be impossible

Key Takeaways

  • Start with the problem, not the solution — validate that the pain is real before building
  • The Mom Test: ask about behavior and specifics, not opinions about your idea
  • Look for the same complaint from multiple sources — one frustrated person is an edge case, ten is a market
  • Study competitor complaints — dissatisfied customers of existing tools are your best early adopters

Example

markdown
// Problem validation framework (as a checklist)
const validationChecklist = {
  problemIsReal: [
    'Talked to 15+ potential users',
    'Found the same problem mentioned in 3+ communities',
    'Identified 5+ competitor complaints about this gap',
  ],
  problemIsPainful: [
    'Users can quantify time or money lost to the problem',
    'Users have tried other solutions and been unsatisfied',
    'Users express urgency when discussing the problem',
  ],
  distributionIsPossible: [
    'I know where these users congregate (communities, events)',
    'I can reach 100 potential customers in my network',
    'There are existing channels to find more users (SEO, ads, communities)',
  ],
  marketIsSized: [
    'TAM estimate is defensible with data',
    'SOM is achievable with realistic assumptions',
    'Unit economics will work at target market share',
  ],
};
Example — MARKDOWN
// Problem validation framework (as a checklist)
const validationChecklist = {
  problemIsReal: [
    'Talked to 15+ potential users',
    'Found the same problem mentioned in 3+ communities',
    'Identified 5+ competitor complaints about this gap',
  ],
  problemIsPainful: [
    'Users can quantify time or money lost to the problem',
    'Users have tried other solutions and been unsatisfied',
    'Users express urgency when discussing the problem',
  ],
  distributionIsPossible: [
    'I know where these users congregate (communities, events)',
    'I can reach 100 potential customers in my network',
    'There are existing channels to find more users (SEO, ads, communities)',
  ],
  marketIsSized: [
    'TAM estimate is defensible with data',
    'SOM is achievable with realistic assumptions',
    'Unit economics will work at target market share',
  ],
};