Assumption mapping

This is the exact file agents read, including the credit header and licence notice. Save it as assumption-mapping/SKILL.md.

---
name: assumption-mapping
description: Surface every belief a product idea depends on, sort them into the five risk types (desirability, viability, feasibility, usability, ethical), rank them on a 2x2 of importance against evidence, and send the riskiest ones (important, little evidence) to the cheapest test first. Carries the real rules: writing each belief as a testable, precise, discrete hypothesis; an evidence ladder where only observed behaviour counts as evidence, not opinion or stated intent; the four quadrant actions; and ordering by importance first, then weakest evidence, then cheapest test. Use it when someone says assumption mapping, riskiest assumption, leap-of-faith assumption, de-risk an idea, what to test first, map our assumptions, or hidden assumptions. Do NOT use it to run the tests (see concept-testing and usability-testing), to choose which opportunity to pursue (see opportunity-solution-trees), to plan interviews (see customer-interviews), or to rank assumptions by opinion instead of evidence.
licence: CC BY 4.0. Free to use and adapt with credit to Afeez Adebayo, linking afeezadebayo.com, https://www.linkedin.com/in/afeez-adebayo/ and the skill's download page at https://afeezadebayo.com/skills-md/product-management/product-discovery/assumption-mapping/.
---

# Assumption mapping

Every product idea rests on a stack of beliefs, and most of them are invisible until the idea fails. Assumption mapping turns that stack into a list you can see, argue about and test. It takes an idea, pulls out everything that has to be true for the idea to work, sorts each belief by how important it is and how much real evidence stands behind it, and points you at the one or two beliefs worth testing before you build anything. The payoff is simple: you spend your testing budget on the assumptions that can actually sink the idea, not on the ones that are merely interesting.

The method has a long lineage, and the common mistake is to run the workshop and skip the discipline that makes it work. David Bland and Alexander Osterwalder's assumptions mapping plots each belief on importance against evidence and tells you to attack the important, unproven corner first. Marty Cagan names the risks a solution has to clear: value, usability, feasibility and viability, with ethical risk folded into viability. Teresa Torres finds assumptions by story-mapping the solution step by step. Itamar Gilad's confidence meter is a reminder that not all evidence is equal, so a belief backed by opinion is not backed at all. This skill makes an AI agent surface the assumptions, write them so they can be tested, rank them by real evidence, and hand the riskiest ones to the right experiment. It does not run the experiment, and it does not decide whether to build. It decides what to find out first.

## When to use this skill, and when not to

Use it when someone asks what to test first, which assumption is riskiest, how to de-risk an idea, how to map or surface the assumptions behind a feature, bet or business model, or how to turn a vague "I think users will love this" into something a team can actually check. Use it after you have an idea or a solution concrete enough to describe, whether that comes from discovery, a roadmap bet, a sales promise or a founder's conviction. Use it to prepare for a round of experiments, so the team runs tests that matter rather than tests that are easy.

Do not use it to run the tests themselves: designing and reading a fake door, a landing page, a pricing test or a prototype study is the concept-testing skill, and usability tests are the usability-testing skill. Do not use it to plan and run generative interviews or write an interview guide; that is customer-interviews. Do not use it to compare several opportunities and choose which one to pursue; that is opportunity-solution-trees, which produces the ideas this skill then de-risks. And do not use it to rank assumptions by who in the room is most senior or most sure. A map placed by opinion is worse than no map, because it gives false confidence a chart to hide behind.

## What the agent needs from you before starting

Ask for these before mapping anything. Do not proceed on assumptions about the assumptions.

1. The idea or solution, concrete enough to attack. Not "a better onboarding" but "a setup checklist that appears on first login and marks itself done as the user completes each step". If the idea is still a one-line slogan, stop and ask how it works, what it looks like, and where it lives, because you cannot surface the beliefs behind a solution you cannot picture.
2. The outcome or opportunity it is meant to serve. The customer need or business result the idea is chasing. This is what makes an assumption "important": important means the idea fails to reach this outcome if the belief is false.
3. The customer and the context. One segment and the situation they are in, described tightly enough that "will they do this?" has a real answer.
4. The evidence that already exists. Interviews, usage data, past experiments, support tickets, anything observed. Be honest about what is opinion and what is behaviour; the map depends on the difference.
5. The decision this feeds and its constraints. What happens after the riskiest assumptions are tested (build, drop, reshape), and how much time, money and customer access you have for testing. This sets how expensive a test you can reach for.

If the idea is too vague to picture or the outcome is unstated, stop and ask. Do not invent a customer, a need or a piece of evidence to fill the gap.

## How to map assumptions, step by step

Follow these in order. Steps 2 to 6 build the map; steps 7 to 9 turn it into a test plan and a decision.

### Step 1. State the idea as a solution you can attack

Write the idea in two or three sentences: how it works, what the customer sees, and where it sits in their day. If you cannot, the idea is not ready to map; send it back for shaping. A solution concrete enough to attack is one where a reasonable person could say "that will not work because..." and name a reason. Those reasons are your first assumptions.

### Step 2. Surface the assumptions

Use two passes so you catch more than desirability.

Story-map pass: imagine the solution already exists and map every step the customer takes, from the trigger that brings them to it through to the moment they get value and come back. At each step ask: what has to be true for the customer to take this step? Torres puts this at roughly 20 to 30 minutes for one solution, and it is worth doing even if you test nothing, because it exposes blind spots and steps that quietly demand too much of the customer.

Business pass: walk the money and delivery lines. What has to be true for this to be worth building (people will pay, it is legal, it fits the model) and for the team to build and run it (the technology exists, the data is available, support can handle it). This is where viability and feasibility assumptions hide; the story map alone will miss them.

Write each belief first in the loose form "We believe that..." to keep the mind open to being wrong, then tighten it in step 3. Aim for coverage, not volume: fifteen to twenty assumptions for one idea is plenty. Merge duplicates as you go.

### Step 3. Write each assumption as a testable hypothesis

A hypothesis is an assumption that is testable, precise and discrete: one belief, stated so clearly that a result could prove it wrong, with a measurable signal. Rewrite each "We believe that..." into this shape:

> We believe that [specific customer] will [specific, observable behaviour] because [reason]. We will know we are right when [observable signal reaches a stated threshold].

Run each through three checks: it names one belief, not a bundle; it could be false, and you can say what "false" would look like; and the signal is something you can observe, not a feeling. "Users will love the checklist" fails all three. "At least 40% of new users who see the setup checklist will complete all steps within their first session" passes.

### Step 4. Classify each assumption by risk type

Tag every hypothesis as one of five types, using its test question:

- Desirability: do customers want this, and will they do what it needs? ("Is there a market?")
- Viability: does it work for the business, including price, cost, legal and go-to-market? ("Should we build it?")
- Feasibility: can the team build and run it with what it has? ("Can we build it?")
- Usability: can people find it, understand it and complete the task? ("Can they use it?")
- Ethical: could building it this way cause harm, to users or others? ("Should it exist in this form?")

Force at least one assumption in each type before moving on. If a type is empty, you have not looked, not that the risk is absent. Ethical is the one teams skip most; ask it explicitly.

### Step 5. Rate the evidence, not the opinion

For each hypothesis, rate how much real evidence stands behind it, using an evidence ladder from weakest to strongest:

1. Your own conviction that it is true.
2. Other people's opinions (colleagues, managers, even customers saying what they would do).
3. A market or industry trend in its favour.
4. Anecdotes: a few customers asked for it.
5. Estimates and plans that say it is feasible or profitable.
6. Market data: survey results, stated preferences and intentions.
7. Customer evidence: what people did in a prototype or usability study.
8. Live behaviour: real usage, purchases, retention from a run experiment or the product itself.

The rule that makes the map honest: only levels 7 and 8, observed behaviour, count as "have evidence". Levels 1 to 6 are "little or no evidence", however confident anyone is. Stated intent is included in "little", because intention is a weak predictor of behaviour: a 2006 meta-analysis found a medium change in intention (d = 0.66) produced only a small change in behaviour (d = 0.36). If the only thing holding up an important belief is that people said they would, treat it as untested.

### Step 6. Rate importance and place each assumption on the map

Importance is a yes or no: if this assumption is false, does the idea fail to reach its outcome? If yes, it is important. If the idea survives the belief being wrong, it is not. Resist "quite important"; force the binary, because the map's value is separating the beliefs that can kill the idea from the ones that cannot.

Place each hypothesis on a 2x2 with importance up the side and evidence across the bottom:

```
 important |  MONITOR            |  TEST NOW (leap of faith)
           |  (strong evidence)  |  (important, little evidence)
 ----------+---------------------+----------------------------
 un-       |  LEAVE              |  IGNORE FOR NOW
 important |  (may cut feature)  |  (unimportant, no evidence)
           |   have evidence           little / no evidence
```

The four quadrant actions:

- Top-right, important and little evidence: these are your leap-of-faith assumptions. Test them, starting now and starting with the single riskiest. This is the only quadrant that earns a near-term experiment.
- Top-left, important and strong evidence: monitor. Do not re-test unless the context changes (a new segment, a new market, a pricing change), then move it back to the right.
- Bottom-right, unimportant and little evidence: ignore for now. Spending here is the most common waste; the belief could be wrong and the idea would still be fine.
- Bottom-left, unimportant and with evidence: leave it, and consider whether the feature that created the assumption is worth keeping at all.

### Step 7. Order the leap-of-faith assumptions

Rank the top-right quadrant so you test one thing at a time. Sort by importance first (a false belief that kills the idea outright beats one that only wounds it), then by weakest evidence, then by what is cheapest and fastest to test, then by what unblocks the most other assumptions. The top of that list is the one assumption to test next. Everything else waits; testing several important beliefs at once makes a muddy result no one can read.

### Step 8. Match each assumption to the cheapest sufficient test

For the assumption at the top of the list, choose the cheapest test that produces strong-enough evidence for the decision it feeds. Match by risk type:

- Desirability: problem interviews about past behaviour, then a landing page or fake-door test for demand, then a pre-sale for willingness to pay. Start with the cheapest that could kill the belief.
- Viability: a pricing or pre-sale test, a letter of intent, or a cost-and-margin model.
- Feasibility: a technical spike or a throwaway prototype of the hard part.
- Usability: a moderated or unmoderated usability test on a prototype.
- Ethical: a structured harm review (who could be hurt, how, how badly), plus a conversation with affected users or a domain expert. Some ethical questions are a stop, not a test.

Decide how strong the evidence needs to be before you trust it: directional (a quick read to steer), moderate (stated intent and preference), or strong (observed behaviour). An important, idea-killing belief deserves strong evidence; a steering question can live with directional. Then hand the assumption and the chosen test to the concept-testing skill (or usability-testing) by name. This skill does not run the test.

### Step 9. Set the pass signal, then test, learn and re-map

Before the test runs, write down the signal that would count as a pass and the threshold it has to clear. Do this first, on purpose, because defining success after you see the result is how teams fool themselves. After the test, move the assumption on the map: strong evidence earned means it slides left. If a critical, top-right assumption fails its test, that is the map doing its job; reshape or drop the idea rather than testing the next thing. Re-map on a cadence, because every change to the idea, the segment or the market adds new assumptions and ages old evidence.

## Worked example

Idea: a project tool adds a shared client inbox, so a client's replies land inside the relevant project instead of scattering across the team's personal email. Outcome: fewer decisions lost between client and team, measured by projects that reach sign-off without a "can you resend that?" delay. Segment: small agencies running client projects in the tool.

The agent story-maps the solution: client gets a notification, opens the project, reads the update, replies in the inbox, the reply shows against the project, the team sees it and acts. Walking the business lines adds the money and build questions. It surfaces, among others:

- Clients will reply inside the tool rather than just hitting reply in their own email. (Desirability, important, evidence: anecdotal only. Top-right.)
- Agencies will pay more for a plan that includes the client inbox. (Viability, important, evidence: none. Top-right.)
- The team can route inbound client email into the right project reliably. (Feasibility, important, evidence: an engineer's estimate. Top-right, but a spike can settle it.)
- Clients can find the reply box without training. (Usability, important, evidence: none. Top-right.)
- Storing client email in the tool meets the agencies' data obligations. (Ethical and viability, important, evidence: none. Top-right, and partly a stop to clear with legal.)
- The notification email renders in Outlook. (Usability, not important, evidence: none. Bottom-right, ignore for now.)

Ordering the top-right list, the single riskiest belief is the first one: clients will actually reply inside the tool. If that is false, nothing downstream matters, and the only evidence is that a few agencies asked for it, which is anecdote. The agent writes the hypothesis: "At least half of clients on pilot projects will send their next substantive reply inside the tool rather than by email, within two weeks." It chooses the cheapest sufficient test, a concierge pilot on five real projects where the team routes replies by hand, because that tests the behaviour without building the routing. It sets the pass signal (50% of next substantive replies in-tool) before starting, and hands the hypothesis and the test to the concept-testing skill. It does not decide whether to build the inbox; it has decided what to learn first, and in what order.

## Templates you can use verbatim

Hypothesis format:

```
We believe that <specific customer> will <specific, observable behaviour>
because <reason>.
We will know we are right when <observable signal> reaches <threshold>.
Checks: one belief only | it could be proven false | the signal is observed, not felt.
```

Assumption table (one row per belief):

```
ID | Hypothesis | Risk type (desirability/viability/feasibility/usability/ethical)
   | Importance (idea fails if false? Y/N) | Evidence (ladder 1-8; 7-8 = "have evidence")
   | Quadrant (TEST NOW / MONITOR / IGNORE / LEAVE)
   | Cheapest sufficient test | Evidence needed (directional/moderate/strong)
   | Pass signal + threshold | Owner | Status (to test / testing / passed / failed)
```

Evidence ladder (weak to strong; only 7-8 count as evidence):

```
1 own conviction  2 others' opinions  3 market trend  4 anecdotes
5 estimates & plans  6 survey / stated intent  7 prototype behaviour  8 live behaviour
Rule: 1-6 = little or no evidence; 7-8 = have evidence. Stated intent is level 6, not proof.
```

The 2x2 (place every hypothesis once):

```
important    | MONITOR (strong evidence) | TEST NOW: leap of faith (little evidence)
unimportant  | LEAVE (may cut feature)   | IGNORE FOR NOW
             |   have evidence           |   little / no evidence
```

## Common mistakes and how to avoid them

1. Placing dots by opinion, not evidence. The map ends up charting how sure the room feels, and the most senior voice slides an unproven belief into the "have evidence" column. Spot it when a dot moves because of who argued for it. Fix it by rating evidence on the ladder and counting only levels 7 and 8 as evidence; conviction, however strong, sits on the right.
2. Assumptions too vague to test. "Users will love it", "the market is ready", "it will scale" cannot be proven wrong, so they cannot be tested. Spot them when no one can say what "false" would look like. Fix by rewriting to the hypothesis format with one belief and a threshold.
3. Mapping only desirability. Teams enjoy debating whether customers want it and forget whether it is buildable, affordable, legal, usable or harmful. Spot it when four of the five risk types are empty. Fix by forcing at least one assumption of each type, and by asking the ethical question out loud.
4. A map that never becomes a test. The workshop produces a tidy chart that goes on a wall and nothing gets tested. Spot it when top-right assumptions have no owner or no named test. Fix by giving the single riskiest assumption a cheapest-sufficient test and an owner before the session ends, and testing one at a time.
5. Testing the cheap or the fun assumptions first. Running the easy experiment because it is easy, regardless of importance, burns the budget on beliefs that cannot sink the idea. Spot it when a test targets a bottom-quadrant assumption. Fix by ordering strictly: importance first, then weakest evidence, then cost.

## Quality bar: check the output against this before handing it over

- Every assumption is written as a hypothesis that names one belief, could be proven false, and has an observable signal with a threshold.
- Every assumption is tagged with one of the five risk types, and all five types have at least one entry or a stated reason none applies.
- Evidence is rated on the ladder, and only observed behaviour (levels 7 to 8) is marked "have evidence"; opinion and stated intent are not.
- Importance is a yes or no tied to the stated outcome, not a vague rating.
- Every assumption sits in exactly one quadrant, and only top-right assumptions are queued for a near-term test.
- The top-right list is ordered by importance, then weakest evidence, then cost, and one assumption is named as the next to test.
- The next assumption has a cheapest-sufficient test, the evidence strength it needs, a pass signal and threshold set before testing, and an owner.
- Nothing is invented: no fabricated evidence, confidence scores, benchmarks or quotes. Where there is no evidence, the map says so.
- The test itself is handed to concept-testing or usability-testing by name; this skill does not run it, and a human owns the build-or-drop decision.

## Guardrails

- Irreversible and people-facing actions need a human. Running a test on real customers, emailing recruits, launching a fake door or a pre-sale all reach real people and can mislead or disappoint them. Produce the test plan as a draft and get explicit confirmation before anything goes live.
- Never fabricate. The whole point of the map is to be honest about what you do not know, so inventing evidence, a confidence number or a benchmark defeats it. If an important belief has no evidence, that is the finding.
- Flag the ethics of deceptive tests. Fake doors and wizard-of-oz tests show customers something that does not fully exist. Name the risk, keep exposure small, honour the implied promise (follow up, never charge for something you cannot deliver), and hand the decision to a human.
- Protect personal data. Assumption maps and test plans may name customers, accounts and deals. Use anonymised labels, keep raw interview and usage data where it already lives, and do not paste contact details into prompts or third-party tools.
- Mind the cost. Mapping is cheap, a single session. The tests it triggers cost real customer time, ad spend and engineering. That is the reason to test only the important, low-evidence corner, and to reach for the cheapest sufficient test each time.
- Stay in scope. This skill surfaces, ranks and routes assumptions. It does not run the experiment (concept-testing, usability-testing), plan interviews (customer-interviews) or choose the opportunity (opportunity-solution-trees). It is decision-support, not a guarantee; a human owns every build-or-drop call.

## Tool-specific appendix

The method is tool-agnostic: a story map, a 2x2 and an assumption table hold on paper, a whiteboard, FigJam or Miro. Use a Business Model Canvas and a Value Proposition Canvas if you want structured prompts for the business and desirability passes, with a different colour per risk type so clusters stand out. Keep the assumption table in a spreadsheet so you can sort by importance and evidence and track status as tests land. Keep one map per idea, and treat it as a living document: re-open it after every test and every meaningful change to the idea, the segment or the market, rather than mapping once and filing it. Whatever the tool, the rules in the steps above do not change; the tool only decides where the map lives.

## Sources

- Strategyzer (David J. Bland), "How assumptions mapping can focus your teams on running experiments that matter": the importance-against-evidence 2x2, the categories (desirability, feasibility, viability, adaptability), the "We believe that..." framing, and the rule to test the important, no-evidence corner first. Last verified 13 November 2026.
- David J. Bland and Alexander Osterwalder, "Testing Business Ideas", and Strategyzer's summary: design-test-learn, the experiment library (discovery versus validation), the evidence hierarchy (opinions weak, stated intent moderate, behaviour strong), choosing a test by assumption type and evidence strength, and "start with the smallest possible test". Last verified 13 November 2026.
- Marty Cagan, Silicon Valley Product Group, "Product Risk Taxonomies": the four big risks (value, usability, feasibility, viability), with ethical, go-to-market and compliance risk inside viability; discovery as addressing these risks before building. Last verified 13 November 2026.
- Teresa Torres, Product Talk, "Getting started with discovery" and "Discovering solutions": story-mapping a solution to surface assumptions (about 20 to 30 minutes), the five assumption categories (desirability, viability, feasibility, usability, ethical), and defining success before testing. Last verified 13 November 2026.
- Itamar Gilad, "Product discovery with ICE and the confidence meter": the evidence ladder from self-conviction and others' opinions up to market data, prototype studies and live behaviour, and confidence as a multiplier so weak evidence lowers a score. Last verified 13 November 2026.
- Koji, "Which validation test to run first": run the cheapest test that can kill the riskiest assumption, the order problem then demand then willingness to pay then delivery, and sample-size and benchmark guidance (Unbounce 2024 median landing-page conversion 6.6%, 3.8% for SaaS; Webb and Sheeran 2006 meta-analysis, intention d = 0.66 to behaviour d = 0.36; CB Insights 2021, 35% of start-ups cited no market need). Verify current benchmarks before relying on them. Last verified 13 November 2026.
- Existing skills reviewed for structure and gaps: borghei "brainstorm-experiments" (XYZ hypothesis, experiment list, no sample-size or usability coverage), menkesu "continuous-discovery" and wondelai "continuous-discovery" (name assumption testing as a component but do not give the mapping mechanics), majiayu000 "product-discovery" (broad market-research scope, no assumption ranking). Last verified 13 November 2026.

---
1.0.0, 13 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is decision-support guidance, not a substitute for testing with your own customers.