problem-solution-fit

What this skill does

# Problem-Solution Fit

You assess problem-solution fit for proposed solutions. You research market context, alternatives, and customer pain points yourself — do not ask the user for data they would need to look up. Only ask the user for decisions and confirmations.

This skill validates whether a solution addresses a genuine, significant problem **on paper** (pre-product). It complements `value-proposition-canvas` (which designs value propositions) by **evaluating fit** and designing validation experiments.

## Phase 1 — Setup

### Input handling

Follow shared foundation §7 — interview mode. When input is missing or insufficient, interview to gather at minimum:

| Dimension | Required | Default |
|---|---|---|
| **Problem description** | Yes | — |
| **Solution description** | Yes | — |
| **VPC / persona data** | No | None |
| **Existing evidence** | No | None |
| **Competitors/alternatives** | No | Will be researched |

**Exit interview when**: Problem and solution are clear enough to assess fit.

### 1. Collect input

Accept one of:
- A problem and solution description
- A file path to a VPC, business case, or Lean Canvas
- Pasted content describing the idea
- No input or vague input → enter interview mode

### 2. Confirm scope

```
**Problem**: [brief description]
**Solution**: [brief description]
**Target customer**: [segment or "to be researched"]
**Evidence available**: [yes/no — what type]
**Data source**: [imported from VPC / from input / will research]
```

Ask the user to confirm or adjust. Ask diagram render mode and output path per the `diagram-rendering` and `autonomous-research` mixins.

## Phase 2 — Research

Use WebSearch and WebFetch per the `autonomous-research` mixin.

### 2a. Problem space research

- Market context for the problem domain
- Evidence of the problem in forums, reviews, articles, social media
- Frequency and severity indicators from real-world sources
- Industry reports on the problem space

### 2b. Alternatives research

- Existing solutions (direct competitors)
- Workarounds and makeshift solutions (strong signal for problem significance)
- Adjacent solutions that partially address the problem
- Why existing alternatives fail or fall short

## Phase 3 — Problem Assessment

### Problem significance scoring

| Dimension | Scale | Score |
|---|---|---|
| **Frequency** | Daily (5) / Weekly (4) / Monthly (3) / Quarterly (2) / Rarely (1) | [1-5] |
| **Intensity** | Critical (5) / High (4) / Moderate (3) / Low (2) / Trivial (1) | [1-5] |
| **Willingness to pay** | Proven (5) / Likely (4) / Uncertain (3) / Unlikely (2) / None (1) | [1-5] |

**Problem significance score** = (Frequency + Intensity + WTP) / 15 × 100

### Problem validation level

| Level | Description | Evidence required |
|---|---|---|
| **Confirmed** | Validated with customer evidence | Interviews, surveys, behavioral data |
| **Observed** | Seen in market but not directly validated | Forum posts, reviews, support tickets |
| **Hypothesis** | Assumed based on reasoning | No direct evidence |

### Existing alternatives

| Alternative | Type | Strengths | Weaknesses | Market share |
|---|---|---|---|---|
| [name] | Direct / Workaround / Adjacent | [list] | [list] | [estimate] |

**Key signal**: Customers using makeshift/workaround solutions = strong problem validation (pain hierarchy level 4-5).

### Root cause analysis (5 Whys)

Apply the 5 Whys technique to the stated problem to uncover root causes. The solution should address root causes, not symptoms.

## Phase 4 — Customer Forces Canvas

| Force | Description | Findings |
|---|---|---|
| **Triggers** | What events push customers to seek a solution? | [specific events] |
| **Desired outcomes** | What does success look like? | [measurable outcomes] |
| **Existing alternatives** | What are they using today? | [solutions + satisfaction level] |
| **Inertia factors** | What keeps them with current solutions? | [switching costs, habits, contracts, learning curve] |
| **Friction factors** | What makes adopting the new solution difficult? | [onboarding, integration, trust, price] |

### Force balance assessment

- **Push forces** (triggers + pain intensity): How strongly are customers pushed toward change?
- **Pull forces** (desired outcomes + solution appeal): How strongly does the new solution attract?
- **Resistance forces** (inertia + friction): How strongly do forces resist adoption?

Net force = (Push + Pull) - Resistance. Positive = favorable conditions for adoption.

## Phase 5 — Solution-Problem Mapping

### Mapping table

| Problem (validated) | Solution feature | Mapping strength | Notes |
|---|---|---|---|
| P1: [problem] | F1: [feature] | Strong / Moderate / Weak | [evidence] |
| P2: [problem] | — | **GAP** | No feature addresses this |
| — | F3: [feature] | **OVER-ENGINEERING** | No validated problem for this |

### Coverage metrics

- **Problems addressed**: [X] of [Y] validated problems = [%]
- **Features justified**: [X] of [Y] features mapped to problems = [%]
- **Gaps**: [count] validated problems without solution
- **Over-engineering**: [count] features without validated problem

### Coverage score = (Problems addressed / Total validated problems) × 100

## Phase 6 — DVF Assessment

### Desirability (0-100)

| Factor | Score (0-20) | Evidence |
|---|---|---|
| Problem significance | [0-20] | [from Phase 3] |
| Customer pull signals | [0-20] | [search volume, forum activity, willingness to pay] |
| Emotional resonance | [0-20] | [frustration level, urgency] |
| Early adopter presence | [0-20] | [makeshift solutions = level 4-5 on pain hierarchy] |
| Competitive gap | [0-20] | [what existing solutions miss] |

### Viability (0-100)

| Factor | Score (0-20) | Evidence |
|---|---|---|
| Revenue potential | [0-20] | [market size, pricing feasibility] |
| Cost structure | [0-20] | [unit economics, margins] |
| Scalability | [0-20] | [growth potential, network effects] |
| Business model clarity | [0-20] | [how money is made] |
| Competitive moat | [0-20] | [defensibility, switching costs] |

### Feasibility (0-100)

| Factor | Score (0-20) | Evidence |
|---|---|---|
| Technical complexity | [0-20] | [known technology, novel components] |
| Resource requirements | [0-20] | [team, budget, timeline] |
| Dependencies | [0-20] | [third-party, regulatory, partnerships] |
| Time to market | [0-20] | [MVP timeline, iteration speed] |
| Risk level | [0-20] | [technical, market, regulatory risks] |

### Overall DVF

- **DVF score** = (Desirability × Viability × Feasibility)^(1/3) — geometric mean ensures all three must be strong
- **Weakest lens**: [which dimension is lowest and why]
- Scores below 40 on any single lens = critical weakness

## Phase 7 — Riskiest Assumption Testing (RAT)

### Assumption register

| ID | Assumption | Category | Impact (1-5) | Confidence (1-5) | Risk Score | Rank |
|---|---|---|---|---|---|---|
| A01 | [assumption] | Value / Audience / Problem / Motivation / Execution / Competition | [1-5] | [1-5] | [Impact × (6-Confidence)] | [rank] |

Risk Score = Impact × Lack of Confidence (where Lack of Confidence = 6 - Confidence)

### Top 5 validation experiments

For each of the 5 highest-risk assumptions:

| Field | Description |
|---|---|
| **Assumption** | [what we're testing] |
| **Test type** | Landing page / Survey / Customer interview / Prototype / Pre-sale / Concierge |
| **Success criteria** | [specific, measurable threshold] |
| **Fail condition** | [what would disprove the assumption] |
| **Evidence quality** | [target level on Strategyzer ladder] |
| **Effort** | Low / Medium / High |
| **Timeline** | [estimated duration] |

## Phase 8 — Evidence Assessment

If evidence is provided by the user, score it per Strategyzer's Evidence Quality Ladder:

| Level | Type | Strength | Example |
|---|---|---|---|
| 1 | Gut feel / hypothesis | Weakest | "I think customers want this" |
| 2 | What people say (opinions) | Weak | Survey: "Would you use this?" |
| 3 | What people say (fac