Assumption Mapper Skill
Surface and prioritize the untested assumptions embedded in any product plan before development begins.
Required Inputs
Ask the user for these if not provided:
- Product brief, PRD, or concept description (even rough notes work)
- Stage (concept / discovery / pre-build / post-launch — affects which assumptions matter most)
Where this sits — the spine's entry point
This is the front of the product-decision spine: assumption-mapper → /prd-template
→ /rice-prioritisation → /roadmap-narrative. It takes a raw idea or brief and
hands the next skill one thing: the riskiest assumption, and whether it survived a
cheap test. Shared terms (assumption, load-bearing, confidence, provenance) are
defined once in docs/craft/product-decisions.md —
consult it rather than re-deriving them. Writing a PRD on top of an untested
load-bearing assumption is the failure this skill exists to prevent, so run it before
/prd-template, not after.
The loop
Four phases. Phase 3 is the skill; the rest feed it. Each ends on a completion
criterion — don't advance until it's met.
- Surface across all four lenses. Extract assumptions in Desirability (do users
want it?), Feasibility (can we build it?), Viability (will the business
sustain it?), Usability (can users actually use it?). The dangerous assumptions
are the ones so obvious no one wrote them down.
Done when: at least one assumption per lens, and re-reading the brief for the
emptiest lens surfaces nothing new.
- Rate on the two axes only. For each: load-bearing (1–5, does the plan collapse
if it's false?) and confidence (1–5, how sure are we it's true?). Priority =
load-bearing − confidence. Tag each fact's provenance ([data]/[hunch]).
Done when: every assumption has both scores and a provenance tag, and the
highest-priority one is genuinely the scariest — not the easiest to test.
- Find and pressure the riskiest. The top-priority assumption (high-load-bearing ×
low-confidence) is the one that can sink the whole plan. Name the cheapest test
that could disprove it before a line of code is written (see the disclosed
cheap-tests reference for the menu).
Done when: the single riskiest assumption is named, with a test that could run
this week and a clear "what a fail looks like."
- Hand off. Output the ranked map, and state explicitly which assumption
/prd-template must treat as validated-or-open. An unresolved riskiest assumption
becomes an Open Question in the PRD, not a silent bet.
Done when: the downstream skill could start from this output without re-asking
what the risky bet is.
Output Structure
Assumption Map: [Feature/Product Name]
| Assumption |
Category |
Confidence |
Impact |
Priority |
Validation Method |
| [assumption] |
[type] |
[1-5] |
[1-5] |
[score] |
[method] |
Critical Assumptions (Impact 4+ and Confidence 2 or below)
[Flagged items with detailed validation recommendations]
Top 3 Assumptions to Validate First
[Detailed recommendations including specific research method, estimated effort, and what the result would change]
Example (Partial)
Input: "We're building a self-serve onboarding flow to reduce time-to-value for SMB customers."
| Assumption |
Category |
Confidence |
Impact |
Priority |
Validation Method |
| SMB users can complete onboarding without human help |
Usability |
2 |
5 |
3 |
Unmoderated usability test (n=8) |
| Faster onboarding correlates with higher retention |
Viability |
3 |
4 |
1 |
Cohort analysis of current onboarding times vs. 90-day retention |
| The current onboarding is the primary reason for slow time-to-value |
Desirability |
2 |
4 |
2 |
User interviews with recent churned SMB accounts |
Anti-Patterns
Deeper Materials
This skill ships with support files — use them when they are available:
references/cheap-tests.md — The Cheap-Test Catalog: Right-Sizing Validation. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.templates/assumption-board.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.
Scoring Rubric (0–40)
Score any output of this skill before handing it over; 32+ is ship-quality.
| Dimension |
0 |
5 |
10 |
| Category coverage |
Desirability-only — the feasibility and viability assumptions most likely to kill the plan are absent |
Three categories populated, but the empty one wasn't re-mined from the brief; coverage is token (one throwaway row) |
All four categories populated with substantive rows, with visible digging into whichever category the brief itself neglected |
| Scoring discipline |
Confidence/impact numbers arbitrary or missing; priority arithmetic inconsistent; no critical flags |
Scores present and Priority = Impact − Confidence holds, but confidence is inflated for unchallenged assumptions and critical flags applied selectively |
Scores defensible (unchallenged ≠ high confidence), arithmetic consistent including negative priorities left visible, and the CRITICAL flag applied mechanically at Impact 4+ / Confidence ≤2 — even to assumptions the team likes |
| Validation method fit |
"User interviews" (or "do research") pasted into every row |
Methods vary but several are mismatched to the assumption type, missing sample sizes, or unpriced |
Each method matched to the assumption (data audit, backtest, fake door, desk check, spike…) with sample size and effort; untestable assumptions flagged unknowable and converted to owned risks, not given fake tests |
| Decision leverage |
Top-3 list missing, or tests whose outcome would change nothing |
Top 3 named with effort, but "what the result changes" is vague or the tests validate comfortable assumptions over dangerous ones |
Top 3 are the highest-priority testable assumptions, each with effort, a pre-committed threshold where relevant, and a concrete decision the result would change |
Quality Checks
1---2name: assumption-mapper3description: Extract and risk-rate hidden assumptions in a product brief or PRD. Use when asked to review a product brief for assumptions, audit a PRD for risks, find hidden assumptions, validate product plans, or run an assumption analysis. Produces a prioritised assumption map with confidence and impact scores, recommended validation methods, and critical assumption flags.4---5
6# Assumption Mapper Skill
7
8Surface and prioritize the untested assumptions embedded in any product plan before development begins.
9
10## Required Inputs
11
12Ask the user for these if not provided:
13- **Product brief, PRD, or concept description** (even rough notes work)
14- **Stage** (concept / discovery / pre-build / post-launch — affects which assumptions matter most)
15
16## Where this sits — the spine's entry point
17
18This is the front of the product-decision spine: **`assumption-mapper` → `/prd-template`
19→ `/rice-prioritisation` → `/roadmap-narrative`**. It takes a raw idea or brief and
20hands the next skill one thing: **the riskiest assumption, and whether it survived a
21cheap test.** Shared terms (assumption, load-bearing, confidence, provenance) are
22defined once in [`docs/craft/product-decisions.md`](../../docs/craft/product-decisions.md) —
23consult it rather than re-deriving them. Writing a PRD on top of an untested
24load-bearing assumption is the failure this skill exists to prevent, so run it *before*
25`/prd-template`, not after.
26
27## The loop
28
29Four phases. Phase 3 is the skill; the rest feed it. Each ends on a completion
30criterion — don't advance until it's met.
31
321. **Surface across all four lenses.** Extract assumptions in *Desirability* (do users
33 want it?), *Feasibility* (can we build it?), *Viability* (will the business
34 sustain it?), *Usability* (can users actually use it?). The dangerous assumptions
35 are the ones so obvious no one wrote them down.
36 **Done when:** at least one assumption per lens, and re-reading the brief for the
37 emptiest lens surfaces nothing new.
382. **Rate on the two axes only.** For each: *load-bearing* (1–5, does the plan collapse
39 if it's false?) and *confidence* (1–5, how sure are we it's true?). Priority =
40 load-bearing − confidence. Tag each fact's provenance ([data]/[hunch]).
41 **Done when:** every assumption has both scores and a provenance tag, and the
42 highest-priority one is genuinely the scariest — not the easiest to test.
433. **Find and pressure the riskiest.** The top-priority assumption (high-load-bearing ×
44 low-confidence) is the one that can sink the whole plan. Name the *cheapest test*
45 that could disprove it before a line of code is written (see the disclosed
46 [cheap-tests](references/cheap-tests.md) reference for the menu).
47 **Done when:** the single riskiest assumption is named, with a test that could run
48 this week and a clear "what a fail looks like."
494. **Hand off.** Output the ranked map, and state explicitly which assumption
50 `/prd-template` must treat as validated-or-open. An unresolved riskiest assumption
51 becomes an Open Question in the PRD, not a silent bet.
52 **Done when:** the downstream skill could start from this output without re-asking
53 what the risky bet is.
54
55## Output Structure
56
57### Assumption Map: [Feature/Product Name]
58
59| Assumption | Category | Confidence | Impact | Priority | Validation Method |
60|------------|----------|------------|--------|----------|-------------------|
61| [assumption] | [type] | [1-5] | [1-5] | [score] | [method] |
62
63#### Critical Assumptions (Impact 4+ and Confidence 2 or below)
64[Flagged items with detailed validation recommendations]
65
66#### Top 3 Assumptions to Validate First
67[Detailed recommendations including specific research method, estimated effort, and what the result would change]
68
69## Example (Partial)
70
71Input: *"We're building a self-serve onboarding flow to reduce time-to-value for SMB customers."*
72
73| Assumption | Category | Confidence | Impact | Priority | Validation Method |
74|------------|----------|------------|--------|----------|-------------------|
75| SMB users can complete onboarding without human help | Usability | 2 | 5 | 3 | Unmoderated usability test (n=8) |
76| Faster onboarding correlates with higher retention | Viability | 3 | 4 | 1 | Cohort analysis of current onboarding times vs. 90-day retention |
77| The current onboarding is the primary reason for slow time-to-value | Desirability | 2 | 4 | 2 | User interviews with recent churned SMB accounts |
78
79## Anti-Patterns
80
81- [ ] Do not only surface desirability assumptions — feasibility and viability assumptions are equally likely to kill a product and are often overlooked
82- [ ] Do not assign high confidence to an assumption just because it hasn't been challenged yet — absence of evidence is not evidence
83- [ ] Do not recommend "user interviews" as the validation method for every assumption — some assumptions require quantitative data, competitive analysis, or technical spikes
84- [ ] Do not list assumptions that cannot be tested — every assumption in the map must have a plausible validation method, or it should be flagged as unknowable and treated as a risk
85
86## Deeper Materials
87
88This skill ships with support files — use them when they are available:
89
90- **`references/cheap-tests.md`** — The Cheap-Test Catalog: Right-Sizing Validation. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
91- **`templates/assumption-board.md`** — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.
92
93## Scoring Rubric (0–40)
94
95Score any output of this skill before handing it over; 32+ is ship-quality.
96
97| Dimension | 0 | 5 | 10 |
98|---|---|---|---|
99| Category coverage | Desirability-only — the feasibility and viability assumptions most likely to kill the plan are absent | Three categories populated, but the empty one wasn't re-mined from the brief; coverage is token (one throwaway row) | All four categories populated with substantive rows, with visible digging into whichever category the brief itself neglected |
100| Scoring discipline | Confidence/impact numbers arbitrary or missing; priority arithmetic inconsistent; no critical flags | Scores present and Priority = Impact − Confidence holds, but confidence is inflated for unchallenged assumptions and critical flags applied selectively | Scores defensible (unchallenged ≠ high confidence), arithmetic consistent including negative priorities left visible, and the CRITICAL flag applied mechanically at Impact 4+ / Confidence ≤2 — even to assumptions the team likes |
101| Validation method fit | "User interviews" (or "do research") pasted into every row | Methods vary but several are mismatched to the assumption type, missing sample sizes, or unpriced | Each method matched to the assumption (data audit, backtest, fake door, desk check, spike…) with sample size and effort; untestable assumptions flagged unknowable and converted to owned risks, not given fake tests |
102| Decision leverage | Top-3 list missing, or tests whose outcome would change nothing | Top 3 named with effort, but "what the result changes" is vague or the tests validate comfortable assumptions over dangerous ones | Top 3 are the highest-priority testable assumptions, each with effort, a pre-committed threshold where relevant, and a concrete decision the result would change |
103
104## Quality Checks
105
106- [ ] At least one assumption per category (Desirability, Feasibility, Viability, Usability)
107- [ ] All Impact 4+ / Confidence 2− assumptions flagged as CRITICAL
108- [ ] Each validation method is specific (not just "do research" — name the method and sample size)
109- [ ] Priority scores are consistent (Impact − Confidence, higher = more urgent)
Mohit Aggarwal