sethdford Assumption Mapping
Make the invisible scaffolding of a plan visible. Most failures trace to untested assumptions, not weak execution—prioritize disproof where stakes are highest.
When to Use
- New products, major technical bets, GTM plans, partnerships, or whenever confidence outruns evidence.
- Before scaling spend on a plan whose success depends on a few unstated “of course” beliefs.
Behaviors
List assumptions the plan requires to be true. Categorize: market (demand, willingness to pay), technical (feasibility, performance, safety), resource (people, budget, time), timing (why now, competitive window). For each: confidence (high/med/low), evidence (facts vs beliefs), and cost if wrong (delay, rework, reputation, capital). Sort by risk × uncertainty—test high impact, low confidence first with the cheapest experiments that can falsify. Revisit after each learning; retire or rewrite assumptions explicitly.
Examples
Example 1: “Enterprises will self-serve” → market assumption; run 5 structured interviews plus a concierge pilot before building full onboarding.
Example 2: “Our model hits latency SLO on CPU” → technical assumption; benchmark on representative data before committing to architecture.