Assumption Testing

Breaking a candidate solution into the underlying assumptions that must hold for it to work, desirability, viability, feasibility, usability, then testing the riskiest of those assumptions quickly and cheaply rather than building and testing the whole solution. You attack the belief most likely to be wrong and most damaging if it is, before committing.

Why it Matters

Testing a whole solution is slow and conflates many bets into one pass or fail, so you learn little about why. Decomposing it exposes the specific beliefs it rests on and lets you target the one that would sink it, getting the most learning per unit of effort. It is verification applied to ideas: establish that the assumptions are sound before authoring the solution that depends on them.

Signals

• A solution committed on a chain of unstated "this will work if..." beliefs.
• Big tests that pass or fail without revealing which assumption was wrong.
• The most fragile assumption left untested because it is uncomfortable to confront.

Benefits

Fast, focused learning aimed at the belief that matters most, cheap failure before expensive commitment, and clarity about exactly why an idea did or did not hold.

Risks

Testing easy assumptions instead of risky ones; mistaking a weak test for real evidence; decomposing endlessly without ever deciding.

Tensions

Identifying the riskiest assumption is itself a judgment that can be wrong, and thorough testing competes with momentum; the aim is enough evidence on the decisive assumption, not certainty on all of them.

Examples

Before building a feature, testing the single assumption that customers will supply the data it needs; probing a risky technical dependency before designing around it.