assumption_mapping v1.0.0

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.