Hypothesis Board

Origin & evolution

There is no single inventor of the hypothesis board as an artefact. Its lineage runs through two overlapping traditions.

The first is the Lean Startup movement, popularised by Eric Ries in his 2011 book The Lean Startup. Ries argued that a startup's job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → is to test assumptions as quickly and cheaply as possible, and that every product decision rests on hypotheses that can be validated or invalidated. The vocabulary of hypothesis, experiment, and learning🧠LearningValidationAn insight gained from an experimentView reference → entered mainstream product practice through this framing.

The second is the continuous discovery practice described by Teresa Torres, particularly in her 2021 book Continuous Discovery Habits. Torres introduced the opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference → tree as a way to keep product trios aligned on what they are testing and why, and her work brought rigour to the process of connecting assumptions to specific experiments and outcomes🏆OutcomeStrategyA desired business or user outcomeView reference →.

The hypothesis board as a concrete column-based tool, structurally similar to a Kanban board but organised around the lifecycle of a belief, with a column for each stage of that lifecycle, grew out of teams applying these ideas in practice. The columns vary across teams. The most common arrangement tracks a hypothesis from draft through to designed, running, and analysed, matching the natural rhythm of a product discovery cycle.

How it works in practice

A hypothesis board is typically a table or board with four columns.

• Draft holds hypotheses that have been articulated but not yet scoped into an experiment. The standard form is: "We believe [this thing is true]. We will know we are right if [we observe this signal]." Writing the signal down forces precision. A hypothesis that cannot be falsified is an opinion, not a bet.
• Designed holds hypotheses that have a concrete experiment attached. The experiment describes exactly what will be built or tested, who the participants🙋ParticipantUser ResearchA person participating in researchView reference → are, how long it will run, and what the success metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → is.
• Running holds hypotheses whose experiments are live. At this stage the board is a status view: what is in the field right now, and when does it conclude?
• Analysed holds hypotheses whose experiments are complete and whose results have been written up as a learning. The learning is the value the board produces. It should be a specific, generalisable finding, not just "the test passed" or "the test failed."

A worked example. A team building an onboarding flow has three hypotheses on the board. In Draft: "We believe new users abandon setup because they don't understand why we need🫀NeedUserA user need, pain, desire, or constraintView reference → their payment details upfront. We will know we're right if 40% of exit-survey respondents cite this reason." In Designed: "We believe showing a timeline of what happens after setup increases completion. We will test this by adding a four-step progress indicator to the setup flow for 50% of new users over two weeks. Success is a 10% increase in completion rate." In Running: an email-versus-in-app prompt experiment. In Analysed: a learning from last sprint that confirmed users complete setup faster when onboarding is split across two sessions.

When to use it (and when not)

A hypothesis board is most useful when a team is in active discovery, testing new features⭐FeatureProduct SpecificationA product capability or featureView reference → or flows before committing to full development, or when a product is in a growth phase where conversion, activation, and retention assumptions are being stress-tested systematically.

It is also useful as a cultural artefact. A visible board signals that the team treats beliefs as testable, not settled, and makes it harder for loudly held opinions to drive decisions unchallenged.

The board works less well as the only source of planning truth. It captures experiments, not all the work a team does, and engineering tasks☑️TaskProduct SpecificationA unit of work within a story or epicView reference →, bug🐛BugProduct SpecificationA defect or unexpected behaviourView reference → fixes, and operational work belong elsewhere. A team that forces every task into hypothesis form ends up with awkward drafts and a board that is hard to read.

The other failure mode is a board that fills up and never moves. Hypotheses that sit in Draft for months were never scoped tightly enough. A hypothesis without a named owner and a planned experiment date is a wish, not a bet.

In the Unified Product Graph

The hypothesis board is a table framework in the validation category. Each column in the board corresponds to a status state on a specific entity type in the Unified Product Graph, allowing the board's contents to connect outward to the rest of the product graph.

• The Hypothesis column contains hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → entities. A hypothesis in the Unified Product Graph carries the belief statement, the falsification condition, and the status that reflects which column it currently occupies.
• The Experiment column contains experiment_run▶️Experiment RunValidationAn execution instance of an experiment that records actual conditions, observations, and raw results.View reference → entities, each linked to the hypothesis it is testing. An experiment_run captures the method, duration, sample, and outcome.
• The Success Metric column references metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → entities. A metric can be shared across multiple experiment_runs, so the same conversion rate used to judge one test can be reused as the success condition for another.
• The Learning column contains learning🧠LearningValidationAn insight gained from an experimentView reference → entities, the documented findings that flow from a completed experiment_run. A learning can connect forward to the decisions it influenced, making the reasoning chain visible after the fact.

Modelling a hypothesis board this way means learnings from completed experiments become reusable knowledge in the graph, not text buried in a sprint retrospective🪞RetrospectiveTeam & OrganisationA team retrospectiveView reference → document.