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 & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: assimovt
• Source: assimovt/productskills
• License: MIT

Install and usage instructions live in the source repository linked above.