problem-validation

Validate whether a problem is worth solving before building anything. Use when asked to validate a problem, assess problem-solution fit, decide whether to build something, or evaluate if a problem is real. Scores problems on frequency, intensity, willingness to pay, and existing workarounds.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "problem-validation" with this command: npx skills add assimovt/productskills/assimovt-productskills-problem-validation

Validate problems with evidence, not opinions. A problem worth solving is one that people encounter frequently, feel intensely, and have already tried to solve. If nobody has attempted a workaround, the problem isn't painful enough to build for.

Scoring Framework

Rate each dimension 1-5 based on evidence:

Frequency (How often does this happen?)

  • 5: Daily or multiple times per day
  • 4: Weekly
  • 3: Monthly
  • 2: Quarterly
  • 1: Rarely or once

Intensity (How painful is it when it happens?)

  • 5: Blocks critical work, causes real losses (money, time, reputation)
  • 4: Major friction, significant workarounds needed
  • 3: Annoying but manageable
  • 2: Minor inconvenience
  • 1: Barely noticeable

Existing Workarounds (Are people already trying to solve it?)

  • 5: Paying for imperfect solutions or built custom tools
  • 4: Cobbled together multi-tool workflows (spreadsheets + email + manual steps)
  • 3: Have a basic process but it's tedious
  • 2: Occasionally Google for solutions
  • 1: Haven't tried to solve it

Willingness to Pay (Would they pay to make this go away?)

  • 5: Already spending money on partial solutions
  • 4: Have explicitly said they'd pay (and named a number)
  • 3: Would "probably" pay (hypothetical — discount this)
  • 2: Want it free
  • 1: Haven't considered paying

Validation Score = Frequency x Intensity x Workarounds x WTP

  • 250+: Strong signal. Build.
  • 100-249: Promising. Needs more evidence on weak dimensions.
  • Under 100: Weak. Either pivot the problem framing or walk away.

Example: "PDF Export" — Frequency: 3 (monthly board reports), Intensity: 2 (screenshot workaround exists), Workarounds: 4 (3 users built browser-print-to-PDF workflows), WTP: 1 (nobody has paid for an export tool). Score = 3 x 2 x 4 x 1 = 24. Verdict: Kill — not painful enough.

Evidence Requirements

Every score MUST cite evidence. Acceptable evidence types, strongest first:

  1. Observed behavior: You watched someone struggle with this
  2. Spending: They pay for alternatives or workarounds
  3. Time invested: They built custom solutions (scripts, spreadsheets, processes)
  4. Quotes from interviews: Direct quotes about past behavior (Mom Test compliant)
  5. Support tickets / forum posts: Public complaints with specifics
  6. Survey responses: Weakest — people say one thing and do another

If your only evidence is survey responses or "my friend said," your validation is weak.

Go / No-Go Decision

Go when:

  • Score 250+ with evidence across all four dimensions
  • At least 5 people independently describe the same problem
  • Someone has spent money or significant time on workarounds

Investigate more when:

  • Score 100-249 with strong evidence on 2-3 dimensions
  • You've talked to fewer than 5 people
  • Workaround evidence is weak

Kill when:

  • Score under 100
  • Nobody has tried to solve the problem themselves
  • "Willingness to pay" is entirely hypothetical
  • You've talked to 5+ people and stories don't converge

Guidelines

  • CRITICAL: NEVER validate based on opinions or surveys alone. Require evidence of past behavior.
  • ALWAYS require workaround evidence. No workarounds = not painful enough.
  • NEVER count "I would definitely use that!" as validation. Enthusiasm is not evidence.
  • ALWAYS talk to at least 5 people in the ICP before making a go/no-go call.
  • NEVER confuse "interesting problem" with "problem worth solving." Interesting doesn't pay the bills.

Built on YC's "talk to users" philosophy and The Mom Test (Rob Fitzpatrick). Skills from productskills.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

prd-writing

No summary provided by upstream source.

Repository SourceNeeds Review
General

experiment-design

No summary provided by upstream source.

Repository SourceNeeds Review
General

bet-sizing

No summary provided by upstream source.

Repository SourceNeeds Review