Assumption

Origin & evolution

The modern practice traces to the lean startup movement. Eric Ries, building on Steve Blank's customer development, named the riskiest beliefs a venture depends on its leap-of-faith assumptions in The Lean Startup (2011). His argument was that a startup's job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → is to convert these assumptions into knowledge as cheaply as possible, and that the minimum viable product exists to run that test. An untested leap-of-faith assumption is the thing most likely to kill the company, so it earns priority.

Jeff Gothelf and Josh Seiden carried the idea into design with the assumptions-then-hypotheses🧪HypothesisValidationA testable belief about a solutionView reference → sequence in Lean UX (2013): list what you are assuming, prioritise by risk🎲RiskComplianceA risk to the product or businessView reference →, and rewrite the riskiest as a testable hypothesis. David Bland and Alexander Osterwalder formalised the prioritisation in *Testing Business Ideas* (2019). Their Assumptions Mapping exercise sorts every belief into desirability, feasibility, and viability, then plots each on two axes, importance and the evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → you currently have. The cluster that is both important and unknown is where experiments🧫ExperimentValidationA test designed to validate a hypothesisView reference → should go.

The field landed on a steady idea: assumptions are inevitable, so the skill is not eliminating them but ranking them by exposure. A cheap-to-be-wrong assumption can ride along untested. An expensive one has to be falsified before you build.

How it works in practice

A team planning a self-serve onboarding flow lists fourteen assumptions. Most are safe. Two are not: "new users will connect their data source🛢️Data SourceData & AnalyticsA data source or integrationView reference → before reaching the dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference →" and "users trust an AI to label their data without review." The team rates each on risk. The data-connection belief scores high, because the entire activation funnel⬇️FunnelGrowthA conversion funnel tracking user progressionView reference → collapses if it is wrong, and it is currently unsupported by any evidence. Its falsifiability test is written down before anything is built: if fewer than forty per cent of trial users connect a source in week one, the assumption is dead. A two-week instrumented prototype📱PrototypeExperience DesignAn interactive mockup for testingView reference → returns twenty-two per cent. The assumption flips to invalidated, and the team reorders the roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference → around a guided-import step it had not planned to build.

Assumption vs. its neighbours

• Hypothesis: an assumption is a passive belief; a hypothesis is that belief rewritten as a falsifiable, testable claim with a success threshold. "Users want faster export" is an assumption. "If we cut export time below three seconds, weekly exports per user rise twenty per cent" is the hypothesis it becomes. The graph models exactly this with assumption_becomes_hypothesisAssumptionbecomesHypothesiscausal.
• Risk: a risk is a possible future harm; an assumption is a present belief whose wrongness creates that harm. The two connect through the risk_level property, which records what a team stands to lose if the assumption fails.
• Constraint🔒ConstraintStrategyA limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundaryView reference →: a constraint is a known boundary you accept as fixed, like a budget or a regulation. An assumption is a belief you could test and might overturn. Treating a real assumption as a constraint removes it from the set of beliefs a team continues to test.

In the graph

In the Unified Product Graph, assumption🤔AssumptionStrategyA belief taken as true that underpins a strategy sits in the Strategy & Outcomes🏆OutcomeStrategyA desired business or user outcomeView reference → region, late in the strategy creation sequence, because assumptions surface once a direction and its bets exist. It carries a four-phase lifecycle, untested to testing to validated or invalidated, so its status is queryable rather than implied. Its outbound edges point at what it puts at stake: assumption_concerns_personaAssumptionconcernsPersonasemantic, assumption_concerns_needAssumptionconcernsNeedsemantic, assumption_concerns_solutionAssumptionconcernsSolutionsemantic, assumption_concerns_featureAssumptionconcernsFeaturesemantic, and assumption_concerns_outcomeAssumptionconcernsOutcomesemantic. The pivotal edge is assumption_becomes_hypothesisAssumptionbecomesHypothesiscausal, which carries a belief into the Discovery, Research & Validation loop where evidence can settle it. An assumption that concerns a feature⭐FeatureProduct SpecificationA product capability or featureView reference → but never becomes a hypothesis is a visible, queryable bet nobody has tested.