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 is deceptively simple: start with the problem, not the solution.

Before writing code, you need to 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

The most reliable source of problems is your own experience. What frustrates you daily as a developer? What tool do you wish existed? What takes you hours that should take minutes?

Your personal frustration is a signal. If you experience the problem, others probably do too. And you understand the context deeply enough to build the right solution.

2. Listen in Communities

Developers congregate in predictable places. Read them actively:

  • Reddit (r/webdev, r/programming, r/sideprojects) — look for repeated complaints
  • Hacker News — "Ask HN: Who is hiring?" and comment sections reveal pain points
  • Twitter/X — developer frustrations are shared publicly and searchable
  • Discord servers — real-time conversations where people express genuine frustrations
  • GitHub Issues — where people document exactly what is broken or missing

The pattern you're looking for: the same complaint from different people. One person's frustration is an edge case. Ten people's frustration is a market.

3. Study Existing Solutions

If people are already paying for something, the problem is validated. Your job is to find the gap:

  • Read 1-star reviews on G2, Capterra, and Product Hunt
  • Study competitor feature request boards
  • Search Twitter for "I wish [competitor name] would..."
  • Ask in forums: "What's your biggest complaint about [tool]?"

Dissatisfied customers of existing solutions are your best early adopters.

4. Job-to-be-Done Framework

Clayton Christensen's framework: customers don't buy products — they hire them to do a job.

"I hired a milkshake for my morning commute to give me something to do with my hands and keep me full until lunch."

For developer tools: "I hired this deployment platform to take server administration off my plate so I can focus on building."

The job-to-be-done reveals: what is the customer actually trying to accomplish? What are they using today? What is frustrating about the current solution?

Validating the Problem

Before building, talk to 20 potential users. The goal is not to pitch your solution — it is to understand their world.

Use the Mom Test (Rob Fitzpatrick's framework):

  • "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

What you're listening for: specific stories (not vague complaints), evidence they've tried other solutions, unprompted complaints about the problem, and quantification (hours, dollars, headcount).

Market Sizing

Before going deep, sanity check the market:

TAM (Total Addressable Market) — how much revenue exists if you got every possible customer?

SAM (Serviceable Addressable Market) — how much of TAM can you realistically reach?

SOM (Serviceable Obtainable Market) — how much will you capture in the first 3 years?

You don't need a $1B market. A focused $10M-$100M market that you can own 20-30% of is a perfectly viable business.

Red Flags

  • "Nice to have" problems — no urgency, no willingness to pay
  • "Someone should build this" — vague, unvalidated
  • No existing alternatives — often means no market, not an opportunity
  • 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
  • Sanity check market size before investing significant time — a viable business needs a reachable, willing-to-pay market

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',
  ],
};
Try it yourself — MARKDOWN