Assumption Map

Use this when a team has a feature idea, product concept, or strategic bet and needs to identify what they're assuming, how risky those assumptions are, and what to test first. Produces a prioritized assumption map with risk ratings and recommended validation methods. This is the starting point for focused discovery -- it tells you where to aim your research.

Related skills: Operationalizes the four-risk model from knowledge/pm-discovery-frameworks.md. Output feeds into /interview-plan, /usability-test-plan, or /experiment-design depending on the assumption type. Part of the discovery-sprint recipe.

Process

Step 1: Gather inputs

Ask the user to provide:

1. The idea or bet -- what is the team planning to build, launch, or invest in? (Feature, product, initiative, or strategic direction.)
2. Current evidence -- what do you already know? (Prior research, analytics, customer feedback, competitive intel.)
3. Stakeholder context -- who believes this will work, and why? (Understanding conviction sources helps surface hidden assumptions.)
4. Timeline pressure -- when does the team need to make a go/no-go decision? (This constrains how much validation is possible.)

Step 2: Surface assumptions

Guide the user through assumption extraction. For each risk category, ask: "What are we assuming is true that, if wrong, would make this fail?"

## Assumption Map -- (Idea/feature, date)

### Value assumptions (Will anyone want this?)
1. (Assumption -- e.g., "Users currently struggle with X and would switch to a better solution")
2. (Assumption -- e.g., "This problem is painful enough that users will pay to solve it")
3. (Assumption)

### Usability assumptions (Can people figure it out?)
1. (Assumption -- e.g., "Users will understand the new navigation without training")
2. (Assumption -- e.g., "The core workflow can be completed in under 3 minutes")
3. (Assumption)

### Viability assumptions (Should we build this?)
1. (Assumption -- e.g., "This feature won't cannibalize our existing product line")
2. (Assumption -- e.g., "We can acquire users for under $X CAC")
3. (Assumption)

### Feasibility assumptions (Can we build this?)
1. (Assumption -- e.g., "The API can handle 10x current load without infrastructure changes")
2. (Assumption -- e.g., "We can ship an MVP in 4 weeks with the current team")
3. (Assumption)

Extraction tips:

• Ask "What would have to be true for this to succeed?" -- each answer is an assumption
• Ask "What are we taking for granted?" -- especially for things that feel obvious
• Ask "What would a skeptic challenge?" -- find the assumptions the team doesn't want to examine
• Aim for 8-15 assumptions total. Fewer than 8 means you haven't dug deep enough. More than 20 means you need to consolidate

Step 3: Map assumptions to Business Model Canvas zones

After surfacing assumptions, map each one to its Business Model Canvas zone. This reveals where risk clusters:

• Desirability (Value Proposition, Customer Relationships, Channels, Customer Segments) -- Will anyone want this? Are we solving a real problem for real people?
• Feasibility (Key Activities, Key Resources, Key Partners) -- Can we build and deliver this? Do we have the people, tech, and partners?
• Viability (Revenue Streams, Cost Structure) -- Should we build this? Will the economics work?

If all assumptions cluster in one zone, that is the team's primary risk. If desirability assumptions dominate, the team has a value risk. If feasibility dominates, it is a delivery risk. If viability dominates, it is a business model risk. Name the cluster explicitly -- it focuses the validation plan.

Step 4: Prioritize on the risk matrix

Plot each assumption on two axes:

• Impact if wrong: How badly does the idea fail if this assumption is false? (High / Medium / Low)
• Evidence level: How much do we actually know? (Strong evidence / Some evidence / No evidence / Contradictory evidence)

### Risk matrix

| # | Assumption | Risk category | Impact if wrong | Evidence level | Priority |
|---|---|---|---|---|---|
| 1 | (Assumption) | Value | High | No evidence | **Test first** |
| 2 | (Assumption) | Usability | High | Some evidence | **Test soon** |
| 3 | (Assumption) | Viability | Medium | Strong evidence | Monitor |
| 4 | (Assumption) | Feasibility | Low | Some evidence | Accept for now |

### Priority definitions
- **Test first:** High impact + low evidence. These are the riskiest assumptions. Validate before committing resources.
- **Test soon:** High impact + some evidence, or medium impact + no evidence. Validate within this iteration.
- **Monitor:** Medium impact with some evidence. Keep an eye on it, but don't block progress.
- **Accept for now:** Low impact or strong evidence. Revisit only if conditions change.

Step 5: Recommend validation methods

For each "Test first" and "Test soon" assumption, recommend a validation approach:

### Validation plan

| Assumption | Recommended method | Why this method | Timeline | Effort |
|---|---|---|---|---|
| (Assumption 1) | (e.g., 5 user interviews) | (Value assumption -- need to hear from users whether this pain exists) | 1-2 weeks | Medium |
| (Assumption 2) | (e.g., Prototype usability test) | (Usability assumption -- need to see if users can navigate the flow) | 3-5 days | Low |
| (Assumption 3) | (e.g., Spreadsheet financial model) | (Viability assumption -- need to validate unit economics) | 1-2 days | Low |
| (Assumption 4) | (e.g., Technical spike) | (Feasibility assumption -- need to prove the architecture works) | 3-5 days | Medium |

Method selection guidance:

• Value assumptions → User interviews, surveys, landing page tests, fake door tests
• Usability assumptions → Prototype testing, hallway tests, wizard of oz
• Viability assumptions → Financial models, market sizing, competitive analysis, sales conversations
• Feasibility assumptions → Technical spikes, proof of concepts, architecture reviews

Step 6: Review and validate

Ask the user:

• Are we missing any assumptions? (The scariest ones are the ones nobody mentions.)
• Do the priority ratings feel right? Is anything under-weighted because the team has false confidence?
• Is the validation plan realistic given timeline and resources?
• Who on the team should own each validation? (Assign owners now or it won't happen.)
• When will you re-validate? Assumptions are dated the moment you write them. Market conditions, competitive landscape, and user needs shift. Schedule a review in 4-6 weeks. A validated assumption from last quarter may be invalid this quarter. Product-market fit is a moving target, not a destination.

Output location

Present the assumption map as formatted text in the conversation. The user copies it into their project documentation. The validation plan feeds directly into /interview-plan, /usability-test-plan, or /experiment-design depending on the assumption type.