assumption-map

name	assumption-map
description	Map the assumptions a bet depends on on two axes — how much we know (knowledge) and how much it matters if we're wrong (impact). Produces a prioritised list of which assumptions to test first. Use before committing engineering effort to a solution, to find the riskiest assumptions cheaply.
argument-hint	[the bet, solution, or business idea to de-risk]
user-invocable	true
allowed-tools	Read, Write, Edit, Bash, Glob, Grep

Map the assumptions behind $ARGUMENTS.

Every bet rests on assumptions — about whether customers want it, whether they'll use it, whether the business case holds. Most "validation" tests the assumptions that are comfortable to test, not the ones that would sink the idea. This skill applies David Bland and Alex Osterwalder's assumption mapping (Testing Business Ideas): plot each assumption on knowledge × impact and test the high-impact, low-knowledge ones first.

Follow every step. The output is a two-axis map and a prioritised test list.

Step 1: Surface the assumptions

List everything that must be true for the bet to work. Cover the four risk areas so you don't only surface the comfortable (feasibility) ones:

Risk area	Assumption prompt
Desirability	Do customers want this? Does it solve a real problem they have?
Viability	Does the business case work? Will they pay? Does it fit the model?
Feasibility	Can we build and run it with what we have?
Usability	Can they figure out how to use it?

Write each as a falsifiable statement: "Ops managers will switch from their spreadsheet within one billing cycle", not "the product is good". This step is complete when you have a list of falsifiable assumptions across all four areas.

Step 2: Score each assumption on the two axes

For each assumption, score:

• Knowledge (x-axis): how much do we actually know about this? Evidence we have → no evidence at all
• Impact (y-axis): if we're wrong, how badly does the bet fail? Low → the bet survives; High → the bet dies

Use real evidence to place knowledge, not confidence. "We feel sure" is not knowledge — knowledge is data. This step is complete when every assumption has a knowledge score and an impact score.

Step 3: Plot the quadrants

Place each assumption in the grid:

	Low knowledge	High knowledge
High impact	TEST FIRST — the bet rests on these and you don't know	Watch — important but established
Low impact	Defer — uncertain but doesn't matter much	Ignore — known and low-stakes

The target quadrant is high impact, low knowledge: the assumptions the bet depends on that you have no evidence for. Those are what to test. High-knowledge, low-impact assumptions are established facts — don't waste an experiment on them. This step is complete when each assumption sits in a named quadrant.

Step 4: Recommend experiments for the target quadrant

For each high-impact, low-knowledge assumption, recommend the test that would move it. Match evidence strength to the stakes — and remember the evidence hierarchy: actual behaviour (purchases, usage, retention) > stated intentions > opinions. Most "validation" collects the weakest type.

• Desirability/value assumptions → a pretotype (/product-manager:design-pretotype) — fake door, smoke test, concierge
• Behavioural/usage assumptions → a Wizard of Oz or concierge run
• Demand assumptions → a smoke-test landing page with a real call-to-action

This step is complete when every target-quadrant assumption has a recommended experiment.

Rules

• Test the riskiest, not the easiest. Teams default to testing feasibility because engineers are comfortable there. The bet usually dies on desirability or viability — map all four areas.
• Knowledge is evidence, not confidence. "We're pretty sure" places an assumption in low knowledge, not high. Only data earns the high-knowledge column.
• Don't test what you already know. High-knowledge, low-impact assumptions are facts. Spend experiments on the target quadrant only.
• Falsifiable statements only. "The product is valuable" can't be tested. "30% of trial users will complete setup unaided" can.
• Behaviour beats stated intent. When you recommend a test, prefer one that measures what people do over what they say.

Output Format

Write to docs/product/assumption-map-[bet-slug].md:

# Assumption map: [bet]

## Assumptions
| # | Assumption (falsifiable) | Risk area | Knowledge (low/high) | Impact (low/high) | Quadrant |
|---|--------------------------|-----------|----------------------|-------------------|----------|
| 1 | ... | Desirability | low | high | TEST FIRST |

## Test first (high impact, low knowledge)
| Assumption | Recommended experiment | Evidence type |
|------------|------------------------|---------------|
| ... | [pretotype / Wizard of Oz / smoke test] | behaviour / intent |

## Deferred / ignored
- [assumption] — [why it doesn't need testing now]

Related Skills

• /product-manager:design-pretotype — designs the experiments for the target-quadrant assumptions.
• /product-manager:write-opportunity-solution-tree — assumptions hang off solutions on the tree.
• /product-manager:write-prd — the riskiest assumption belongs in the PRD's pre-mortem.