| name | fnd.r-scoring-problems |
| description | Scores problem severity, frequency, and willingness to pay. Use when ranking problems, validating problem-solution fit, assessing pain intensity, or prioritizing which problems to solve. |
| allowed-tools | Read, Write, WebSearch |
| license | Complete terms in LICENSE.txt |
Problem Validating
Validate and prioritize problems by severity, frequency, and willingness to pay.
Canvas Files
- Reads: 04.segments.md (primary segment for problem context)
- Reads: 01.context.md (beliefs about problems to validate)
- Writes: 05.problem.md
Prerequisites
Before validating problems:
strategy/canvas/04.segments.md must exist with primary segment defined
If missing:
"Problem validation requires customer segments from 04.segments.md.
Problems must be anchored to specific segments — 'everyone has this problem' is not validatable.
Run fnd.r-segmenting-customers skill or fnd-researcher agent first."
Process
Step 1: Load Context
Read from canvas:
- Primary segment from 04.segments.md
- Segment pain signals from 04.segments.md
- Beliefs about problems from 01.context.md (if exists)
Step 2: List Problem Hypotheses
For the primary segment, identify candidate problems:
- What pain points emerged from research?
- What jobs-to-be-done are underserved?
- What workarounds exist (signals real pain)?
- What do they complain about?
Aim for 5-7 candidate problems to evaluate.
Step 3: Score Each Problem
Frequency (1-5):
| Score | Frequency | Example |
|---|
| 5 | Multiple times daily | Email overload |
| 4 | Daily | Expense reporting |
| 3 | Weekly | Team coordination |
| 2 | Monthly | Quarterly planning |
| 1 | Rarely | Annual audit |
Intensity (1-5):
| Score | Intensity | Signal |
|---|
| 5 | Business stops | Critical system down |
| 4 | Significant loss | Revenue/time impact |
| 3 | Notable pain | Frustration, inefficiency |
| 2 | Mild annoyance | Workaround exists |
| 1 | Trivial | Nice to fix |
Willingness to Pay (1-5):
| Score | WTP Signal | Evidence |
|---|
| 5 | Actively buying | Budget allocated, RFPs out |
| 4 | Would pay | Direct P&L impact, clear ROI |
| 3 | Might pay | Indirect benefit, needs business case |
| 2 | Reluctant | Nice-to-have, low priority |
| 1 | Won't pay | No budget, no urgency |
Calculate Severity:
Severity Score = Frequency × Intensity × WTP (max 125)
Step 4: Gather Evidence
For each problem, document evidence:
Strong Evidence (prioritize):
- Customer interview quotes
- Job postings for roles addressing this problem
- Competitor funding rounds (market validation)
- Industry reports citing this problem
Moderate Evidence:
- Survey responses (n>30)
- Review site complaints
- Forum discussions
- Search volume trends
Weak Evidence (flag uncertainty):
- Founder intuition
- Secondary research only
- Analogies from other markets
Step 5: Identify Current Solutions
For each problem, document:
- Existing alternatives: What do they use now?
- Workarounds: Manual processes, spreadsheets
- Shortcomings: Why current solutions fail
This informs differentiation opportunity.
Step 6: Apply JTBD Frame
Convert top problems to Jobs-to-be-Done:
When [situation/trigger],
I want to [motivation/action],
So I can [expected outcome].
JTBD focuses on outcome, not solution — keeps problem definition clean.
Step 7: Rank and Select
Rank by Severity Score. Select:
- Top 3 for solution design (05.problem.md)
- #4-5 as expansion opportunities
Step 8: Write Output
Write to strategy/canvas/05.problem.md using output format below.
Output Format
# 05. Problems
## Primary Segment
[From 04.segments — who has these problems]
## Problem Stack (Ranked by Severity)
### Problem 1: [Name]
**JTBD:** When [situation], I want to [action], so I can [outcome].
**Severity Score:** [X]/125
| Dimension | Score | Evidence |
|-----------|-------|----------|
| Frequency | [1-5] | [How often, evidence] |
| Intensity | [1-5] | [How painful, evidence] |
| WTP | [1-5] | [Budget signals, evidence] |
**Current Solutions:**
| Alternative | How Used | Why Inadequate |
|-------------|----------|----------------|
| [Alt 1] | [Usage] | [Limitation] |
| [Alt 2] | [Usage] | [Limitation] |
**Root Cause:** [Why this problem exists]
**Cost of Problem:** $[X]/[period] — [calculation basis]
---
### Problem 2: [Name]
[Same structure]
---
### Problem 3: [Name]
[Same structure]
---
## Problem Validation Status
| Problem | Evidence Type | Confidence | Next Step |
|---------|---------------|------------|-----------|
| P1: [Name] | [Interview/Survey/Research] | High/Med/Low | [Action] |
| P2: [Name] | [Type] | [Level] | [Action] |
| P3: [Name] | [Type] | [Level] | [Action] |
## Problems NOT Prioritized
| Problem | Severity | Why Deprioritized |
|---------|----------|-------------------|
| [P4] | [Score] | [Reason] |
| [P5] | [Score] | [Reason] |
Quality Criteria
Before finalizing, verify:
Interview Questions
For customer discovery:
| Question | Purpose |
|---|
| "When did you last experience [problem]?" | Validates frequency |
| "Walk me through what happened" | Reveals intensity, context |
| "What did you do about it?" | Exposes current solutions |
| "What did this cost you?" | Quantifies impact |
| "If you could wave a magic wand..." | Reveals desired outcome |
Red Flags (Problem May Be Weak)
| Signal | Interpretation |
|---|
| "It would be nice if..." | Low intensity |
| Can't recall last occurrence | Low frequency |
| No workaround exists | May not care enough |
| Won't quantify cost | Not actually painful |
| "We've always done it this way" | Accepted status quo |
Green Flags (Problem Is Real)
| Signal | Interpretation |
|---|
| Emotional response | High intensity |
| Specific recent example | High frequency |
| Built internal tool | High WTP |
| Quantifies cost readily | Tracked the pain |
| "I would pay for..." | Validated WTP |
Boundaries
- Does NOT validate solution fit (separate concern)
- Does NOT assess market size for problem (see fnd.r-sizing-markets)
- Does NOT interview customers (provides framework for interviews)
- Problem scores are hypotheses until validated with customers
- Requires segment context — generic problems are not actionable
- Does NOT prioritize based on ease of solution (that's Solution Design)
- Evidence quality matters — flag low-confidence scores
