← Writing

The Assumption Map: A Simple Way to Decide What to Test First

May 15, 2025 · PM × Design

The Assumption Map: A Simple Way to Decide What to Test First

When a project feels risky, teams default to “more discovery.” That can become endless. A better approach is to map assumptions explicitly and test the ones that matter.

An assumption map is a 30-minute exercise with design and engineering. You list assumptions across five buckets:

  1. User/Problem
  • “This pain happens frequently.”
  • “This user segment cares.”
  1. Value
  • “This will save time / increase revenue / reduce errors.”
  1. Behavior
  • “Users will change their workflow.”
  • “They will do this step without prompting.”
  1. Solution/UX
  • “Users will understand this mental model.”
  • “They can complete the flow without help.”
  1. Engineering/Delivery
  • “We can get the data reliably.”
  • “Performance will be acceptable.”

Then you score each assumption on two axes:

  • Confidence: how sure are we?
  • Blast radius: how bad if we’re wrong?

Your top tests come from low-confidence, high-blast-radius assumptions.

Example: If you’re building an “AI-generated report summary,” your highest risk might not be model quality. It might be:

  • “Users trust the summary enough to send to clients.” That’s a trust risk, not a technical one.

So your test could be:

  • show 3 versions to users
  • ask what they’d edit
  • measure willingness to share
  • learn what “trust” requires (citations, tone, data context)

The power of the assumption map is speed:

  • it prevents over-scoping research
  • it aligns design + eng on what matters
  • it gives you a clear testing plan

Interview line:

“I use an assumption map to identify the highest blast-radius risks, then run the lightest test to reduce them. It keeps teams fast and honest.”