Identify Assumptions

Assumption Mapping Expert

Overview

Systematically identify, categorize, and prioritize the assumptions underlying your product decisions. This skill extends Teresa Torres' four risk categories with four additional categories for new products, and uses a devil's advocate approach from PM, Designer, and Engineer perspectives to surface hidden assumptions.

When to Use

• After ideation, before committing to build.
• When a product decision "feels right" but has not been validated.
• When the team disagrees on risk or priority -- assumptions make disagreements explicit.
• Before designing experiments -- test the riskiest assumptions first.

Risk Categories

Core 4 Categories (Existing Products)

These four categories come from Teresa Torres' Continuous Discovery Habits and cover the primary risks for features within an established product:

Extended 8 Categories (New Products)

For new products, four additional risk categories become critical:

Methodology

Phase 1: Devil's Advocate Assumption Surfacing

For each product idea or decision, adopt three adversarial perspectives:

PM Devil's Advocate "I challenge whether this is worth building."

• Is there real demand, or are we projecting our own preferences?
• Will this move the metric we care about?
• Can we sustain this economically?
• Does this align with strategy, or is it a distraction?

Designer Devil's Advocate "I challenge whether users will actually use this."

• Will users discover this feature?
• Can they complete the task without help?
• Does this add complexity that hurts the overall experience?
• Are we designing for edge cases and assuming they are common?

Engineer Devil's Advocate "I challenge whether we can build and maintain this."

• Do we have the technical skills and infrastructure?
• What are the hidden dependencies and integration risks?
• Can this scale if it succeeds?
• What is the ongoing maintenance burden?

Phase 2: Categorize Each Assumption

For each assumption surfaced, assign:

Phase 3: Prioritize Using Impact x Risk Matrix

Calculate a risk score for each assumption:

Risk Score = Impact x (1 - Confidence)

Where confidence maps to: High = 0.8, Medium = 0.5, Low = 0.2

Phase 4: Classify into Quadrants

Place each assumption on a 2x2 matrix:

                    HIGH IMPACT
                        |
     Proceed with       |     Test Now
     Confidence         |     (highest priority)
                        |
  ──────────────────────┼──────────────────────
                        |
     Defer              |     Investigate
     (low priority)     |     (may be important)
                        |
                    LOW IMPACT

         LOW RISK ◄─────┼─────► HIGH RISK

Phase 5: Suggest Tests

For each "Test Now" assumption, recommend a validation approach:

Python Tool: assumption_tracker.py

Track and prioritize assumptions using the CLI tool:

# Run with demo data
python3 scripts/assumption_tracker.py --demo

# Run with custom input
python3 scripts/assumption_tracker.py input.json

# Output as JSON
python3 scripts/assumption_tracker.py input.json --format json

Input Format

{
  "assumptions": [
    {
      "description": "Users will prefer AI summaries over manual notes",
      "category": "value",
      "confidence": "low",
      "impact": 9
    }
  ]
}

Output

Sorted by risk priority with quadrant classification and suggested actions.

See scripts/assumption_tracker.py for full documentation.

Output Format

Assumption Registry

Action Plan for "Test Now" Assumptions

For each assumption in the Test Now quadrant, document:

• Assumption description
• Why it is high risk
• Suggested validation method
• Owner and timeline

Use assets/assumption_map_template.md for the full template.

Integration with Other Discovery Skills

• Use brainstorm-ideas/ to generate ideas whose assumptions you will map.
• Feed "Test Now" assumptions into brainstorm-experiments/ for experiment design.
• Run pre-mortem/ to catch risks that assumption mapping might miss (especially elephants).

Troubleshooting

Success Criteria

• All product decisions have at least 8-15 explicit assumptions documented before build commitment
• Every "Test Now" assumption has an assigned owner, validation method, and timeline
• Risk scores are calculated consistently using the Impact x (1 - Confidence) formula
• Assumptions are re-scored after each validation experiment (confidence levels update)
• At least 80% of "Test Now" assumptions are validated or invalidated before major build decisions
• Assumption map is reviewed and updated at every product discovery cycle (weekly or bi-weekly)
• The team can articulate the top 3 riskiest assumptions for any active initiative

Scope & Limitations

In Scope:

• Systematic assumption identification using PM/Designer/Engineer devil's advocate perspectives
• 8-category risk classification (Value, Usability, Viability, Feasibility, Ethics, Go-to-Market, Strategy, Team)
• Quantitative risk scoring using Impact x (1 - Confidence) formula
• Quadrant classification (Test Now, Proceed, Investigate, Defer) with suggested validation methods
• Assumption registry with priority sorting and action plan generation

Out of Scope:

• Running validation experiments (see brainstorm-experiments/ skill)
• Product strategy or roadmap decisions (see execution/outcome-roadmap/)
• Technical feasibility deep-dives or architecture reviews (see engineering/ skills)
• Financial modeling for viability assumptions (see finance/ domain skills)

Important Caveats:

• Confidence levels (high/medium/low) map to fixed numeric values (0.8/0.5/0.2). This is a simplification; real confidence is continuous.
• The quadrant threshold for "high impact" is set at 7/10. Adjust this threshold for your risk tolerance.
• Assumption mapping is most effective when done collaboratively (Product Trio), not by a single person.

Integration Points

Tool Reference

assumption_tracker.py

Tracks, scores, and prioritizes product assumptions using an Impact x Risk matrix with quadrant classification.

Input fields per assumption:

• description (required): Clear statement of what must be true
• category (required): One of value, usability, viability, feasibility, ethics, gtm, strategy, team
• confidence (required): One of high, medium, low
• impact (required): Integer 1-10

References

• Teresa Torres, Continuous Discovery Habits (2021)
• David J. Bland & Alexander Osterwalder, Testing Business Ideas (2019)
• Ash Maurya, Running Lean (2012)
• Marty Cagan, Inspired (2018)

Assumption Map Template

Context

---

Assumption Registry

Risk Score Formula: Impact x (1 - Confidence), where High=0.8, Medium=0.5, Low=0.2

Quadrant Assignment:

• Test Now: Impact >= 7 AND Confidence = Low or Medium
• Proceed: Impact >= 7 AND Confidence = High
• Investigate: Impact < 7 AND Confidence = Low
• Defer: Impact < 7 AND Confidence = Medium or High

---

Risk Category Quick Reference

Core 4 (All Products)

Extended 4 (New Products Only)

---

Prioritization Matrix (Impact vs. Risk)

     10 ┌─────────────────┬─────────────────┐
        │                 │                 │
        │    PROCEED      │    TEST NOW     │
  I     │  (move forward  │  (experiment    │
  M     │   with tripwire)│   immediately)  │
  P   7 ├─────────────────┼─────────────────┤
  A     │                 │                 │
  C     │    DEFER        │   INVESTIGATE   │
  T     │  (accept risk)  │  (gather data)  │
        │                 │                 │
      1 └─────────────────┴─────────────────┘
        HIGH confidence    LOW confidence
        (low risk)         (high risk)

Place each assumption's number on the matrix above.

---

Action Plan: Test Now Assumptions

---

Tripwires: Proceed Assumptions

---

Notes

Capture reasoning, debates, and additional context from the mapping session.

Assumption Mapping Guide

Teresa Torres' Four Risk Categories

Teresa Torres identifies four types of risk that every product decision carries. These categories originate from her book Continuous Discovery Habits and are the standard framework for assumption mapping in continuous product discovery.

Value Risk

Question: Will customers want this? Will they choose it over alternatives?

What to look for:

• Assumptions about the severity or frequency of the problem.
• Assumptions about how customers currently solve the problem.
• Assumptions about willingness to switch from the current solution.
• Assumptions about perceived value relative to price.

Red flags:

• "Everyone has this problem" -- usually not true. Define the specific segment.
• "Users told us they want this" -- stated preference does not equal revealed preference.
• "No one else is doing this" -- could mean no demand, not just no competition.

Usability Risk

Question: Can customers figure out how to use this? Will they complete the task successfully?

What to look for:

• Assumptions about user mental models and expectations.
• Assumptions about discoverability of features.
• Assumptions about required knowledge or skill level.
• Assumptions about error recovery and edge cases.

Red flags:

• "It is intuitive" -- intuitive to the team that built it, maybe not to users.
• "We will add a tutorial" -- tutorials are a band-aid for poor usability.
• "Power users will figure it out" -- even power users have limited patience.

Viability Risk

Question: Can the business sustain this? Does the economics work?

What to look for:

• Assumptions about revenue impact or cost savings.
• Assumptions about customer acquisition cost and lifetime value.
• Assumptions about operational cost of maintaining the feature.
• Assumptions about regulatory or legal compliance.

Red flags:

• "We will monetize later" -- without a path, later often means never.
• "The marginal cost is zero" -- infrastructure, support, and maintenance are rarely zero.
• "Legal will be fine with it" -- check early, not after building.

Feasibility Risk

Question: Can we build this with our current team, technology, and timeline?

What to look for:

• Assumptions about technical complexity and unknowns.
• Assumptions about third-party dependencies (APIs, vendors, partners).
• Assumptions about data availability and quality.
• Assumptions about performance, scalability, and reliability requirements.

Red flags:

• "It is just a simple API call" -- integration is rarely simple.
• "We have done something similar before" -- similar is not identical.
• "It will take two weeks" -- engineer estimates are systematically optimistic.

---

Extended 8-Category Model for New Products

When building something entirely new, four additional risk categories become relevant. These are often overlooked because they fall outside the traditional product development frame.

Ethics Risk

Question: Should we build this? Could it cause harm?

Assumptions to surface:

• Data collection will not violate user privacy expectations.
• The product will not create negative externalities for non-users.
• Algorithmic decisions will not exhibit bias against protected groups.
• Users will give informed consent for how their data is used.
• The product will not enable harmful use cases.

When to prioritize: Any product involving personal data, AI/ML, health, finance, or vulnerable populations.

Go-to-Market Risk

Question: Can we reach and acquire our target customers?

Assumptions to surface:

• The target segment is reachable through specific channels.
• Customer acquisition cost will be below lifetime value.
• The value proposition can be communicated in a headline.
• Word-of-mouth or viral mechanics will contribute to growth.
• Sales cycle length is within our runway tolerance.

When to prioritize: Any new product without an existing distribution channel or customer base.

Strategy and Objectives Risk

Question: Does this align with where the company wants to go?

Assumptions to surface:

• This product/feature advances a current company objective.
• Leadership will continue to fund this initiative through completion.
• This does not cannibalize or conflict with other products.
• The competitive landscape will remain favorable.
• Market timing is right (not too early, not too late).

When to prioritize: New products, pivots, or features that represent a strategic bet.

Team Risk

Question: Do we have the right people and skills to execute?

Assumptions to surface:

• The team has the technical skills required.
• Key personnel will remain available throughout the project.
• Cross-functional collaboration will be effective.
• The team can learn new skills within the project timeline.
• We can hire for skill gaps quickly enough.

When to prioritize: Projects requiring new technologies, new domains, or stretched teams.

---

Confidence Calibration Techniques

Confidence levels are subjective. Use these techniques to improve calibration:

Evidence-Based Confidence

The Five Whys Test

For any assumption rated "High confidence," ask "Why do we believe this?" five times. If you cannot trace the confidence back to concrete evidence by the third "why," downgrade to Medium.

Pre-Mortem Check

Imagine the assumption turned out to be wrong. How surprised would you be?

• "I would be shocked" = High confidence (but verify you have evidence, not just conviction)
• "I would be disappointed but not shocked" = Medium confidence
• "I honestly do not know" = Low confidence

Calibration Exercise

Before mapping assumptions, run a quick calibration: have each team member independently rate confidence for 3-4 well-known assumptions (e.g., "Our homepage conversion rate is above 3%"). Compare ratings. If the team diverges significantly, discuss what evidence each person is using. This aligns the team's confidence scale before the real exercise.

---

Assumption Prioritization Matrix

The 2x2 Matrix

                    HIGH IMPACT
                        |
     PROCEED            |     TEST NOW
     (high confidence,  |     (low confidence,
      high impact)      |      high impact)
                        |
  ──────────────────────┼──────────────────────
                        |
     DEFER              |     INVESTIGATE
     (high confidence,  |     (low confidence,
      low impact)       |      low impact)
                        |
                    LOW IMPACT

     HIGH CONFIDENCE ◄──┼──► LOW CONFIDENCE

Decision Rules

Tripwires for "Proceed" Assumptions

Even high-confidence assumptions can be wrong. Set tripwires:

• "If churn exceeds 8% in the first month, revisit the value assumption."
• "If support tickets about this feature exceed 20/week, revisit the usability assumption."

---

Connection to Experiment Design

Assumption mapping feeds directly into experiment design:

1. Identify assumptions (this skill). 2. Prioritize to find "Test Now" assumptions. 3. Design experiments (use brainstorm-experiments/ skill) targeting the riskiest assumptions. 4. Run experiments and update confidence levels based on results. 5. Re-prioritize -- the map is a living document.

Mapping Assumptions to Experiment Types