---
name: "assumption_mapping"
description: "Surfaces the risky assumptions behind a new product idea or strategic bet: sorts them into value, usability, feasibility, and viability buckets, ranks them by impact and evidence, and turns the riskiest ones into cheap experiment cards. Use when someone has a product idea, pitch, or plan and needs to find what could kill it, decide what to test first, or design a cheap test before committing budget or build time."
---

# Assumption Mapping

## Purpose

Before a team commits money or build time to a new idea, find every belief the
plan depends on and test the dangerous ones first. This skill runs one unified
flow: pull the assumptions out of the pitch, sort them into risk buckets, rank
them by how much they hurt and how little evidence exists, and write an
experiment card for each of the riskiest. The output tells the team exactly
what to test, how, and what result would kill the idea. No build work starts
until the risky beliefs are checked.

The risk buckets come from Marty Cagan's four big risks (SVPG, introduced in
*Inspired*); the mapping, scoring, and test-card discipline follows David
Bland and Alexander Osterwalder's *Testing Business Ideas* (2019). See
references/worked-example.md for a complete run-through on a sample idea.

## Workflow

### 1. Extract: list every belief the plan depends on

Ask the requester to state the idea plainly: who it is for, what it does, what
it costs, and what has to happen for it to work. Then write down every
assumption as a falsifiable belief, one per item, in the form
"We believe that [specific claim]." Prompt across all four buckets so nothing
hides:

- Value: "Will the customer buy or choose to use this?"
- Usability: "Can the customer figure out how to use it?"
- Feasibility: "Can we build it with the time, skills, and technology we have?"
- Viability: "Does this work for our business (pricing, channels, legal, brand)?"

Rules: one belief per item. If an item contains "and", split it into two.
Ban vague beliefs ("people want this") and opinions ("this is a good idea").
Aim for 10 to 20 assumptions; stop when new items start repeating old ones.

### 2. Bucket: sort each assumption

Put every assumption into the one bucket where being wrong would hurt most.
When one fits two, pick the side whose failure is more expensive, not the
one that is more comfortable to think about. Note the owner for each bucket:
value and viability sit with whoever owns the plan; usability sits with
whoever designs the experience; feasibility sits with whoever builds it.

### 3. Score and rank: find the dangerous ones

Score each assumption 1 to 3 on two axes:

- **Impact:** 1 = being wrong is a minor annoyance; 2 = being wrong forces a
  redesign or delays the plan; 3 = being wrong kills the idea.
- **Evidence:** 1 = no evidence, a guess; 2 = some evidence (anecdotes,
  analogous cases, weak data); 3 = strong evidence (behavioral data from a
  relevant test or product).

Test order follows impact first, evidence second. The queue is:
high impact + weak evidence (test these first), then high impact + moderate
evidence (monitor closely), then everything else. Assumptions with low impact
and strong evidence drop off the list entirely. Plot them on the 2x2 of
evidence against impact if the team is in a room; the exact position does not
matter, only the quadrant.

### 4. Write experiment cards for the risky ones

For each queued assumption, design the cheapest experiment that can still move
the belief. Use the test-card template in assets/test-card.md. Each card has:

- **Assumption:** the belief from the ranking table.
- **Hypothesis:** a testable claim about behavior with a named segment.
- **Experiment:** concrete enough to run tomorrow (channel, asset, audience
  size, duration). Check references/experiment-patterns.md before choosing.
- **Metric:** a behavioral measure (clicks, replies, signups, dollars,
  retention). Stated intent ("would you use this?") never counts.
- **Criteria:** the numeric pass threshold with unit and timeframe, set
  BEFORE the test runs, plus the kill condition: what result invalidates the
  assumption and stops this line of testing.
- **Cost:** hours and dollars, estimated. **Time to signal:** days.

Assign every card an owner and a deadline. A card without an owner, a
deadline, and a written decision is not scheduled.

## Output Contract

Deliver:

1. **Assumption register:** a table with ID, the assumption ("We believe
   that..."), bucket, impact score, evidence score, and rank.
2. **Test queue:** the assumptions to test first, in order, with the quadrant
   reasoning in one line each.
3. **Experiment cards:** filled test cards for each queued assumption.
4. **Verdict:** one paragraph. Which beliefs carry the idea, what the cheapest
   path to an answer is, and the one result that would make the team stop.

Keep the SKILL-level answer readable in one screen; the full register and
cards can run longer.

## Operating Rules

1. No confident unverified claims. Every fact in the register or cards must
   come from the requester, a real source, or be marked as an estimate.
2. Behavior over intent. Interviews and surveys inform; only observable
   behavior (clicks, money, retention, task success) validates.
3. Thresholds are set before running, never after seeing results. Write down
   why the number was chosen.
4. Cheapest evidence first. A full build is never the test. If the cheapest
   test that could move the belief still costs more than a week, shrink the
   belief, not the standard.
5. Weak signals before strong ones. Run cheap interest tests first; only
   spend on commitment tests (pre-sales, builds) when the weak test passes.
6. Split compound beliefs. One belief per card, one card per test.
7. Every queued assumption leaves with a named owner, a deadline, and a
   stated kill condition. Anything missing those three does not count.