Assumption Testing¶

Why It Matters¶

Every solution rests on a stack of assumptions - about user behavior, technical feasibility, market conditions, organizational capacity. Most failures trace to an invalid assumption that was never tested because it seemed obviously true. Assumption testing forces you to externalize and challenge what you're taking for granted, focusing resources on validating the beliefs most likely to be wrong and most consequential if wrong.

The Key Move¶

Before implementing any solution, list all assumptions it requires to succeed. For each assumption, assign: (1) confidence level (how sure are you?), (2) impact if wrong (what breaks?). Prioritize testing low-confidence, high-impact assumptions first. Design the cheapest test that could falsify each assumption - not prove it right, but reveal if it's wrong. Run tests in order of risk, and be willing to pivot or abandon based on results.

Classic Application¶

Lean Startup methodology applied this explicitly. Dropbox assumed people wanted cloud file syncing but faced a high technical build cost. Instead of building the full product, Drew Houston created a 3-minute screencast video showing how it would work and posted it to Hacker News. The key assumption - "people want this enough to sign up before it exists" - was tested with a waiting list. 75,000 signups overnight validated the assumption at near-zero cost.

Surprising Application¶

Dissertation topic selection. Students assume they need years of reading before proposing a topic. Key assumptions: "I need comprehensive knowledge first," "my advisor will reject premature proposals," "changing topics later is catastrophic." Testing these: write a one-page proposal after one month of reading and share with advisor. This tests whether incomplete knowledge actually blocks useful feedback (usually doesn't) and whether early proposals create commitment (they don't - they start conversation). Testing reveals the assumptions were wrong, saving months.

Failure Modes¶

Testing only trivial assumptions while leaving crucial ones unexamined because they're uncomfortable to question. Designing tests that can't actually falsify the assumption - confirmation bias in test design. Testing assumptions sequentially when you should test in parallel (wastes time). Treating test failure as implementation failure rather than successful learning. Continuing to build after assumptions fail because of sunk cost bias.

Go Deeper¶

Ries, The Lean Startup, Chapter 4; Osterwalder et al., Testing Business Ideas: A Field Guide for Rapid Experimentation