As product teams grow, assumptions, customer evidence, decisions, delivery work and outcomes drift into different tools. Nobody can say why a bet exists or what happened after it shipped. Productboard's survey is not among the sources I can link, but its finding stands: around 70% of enterprises with more than 2,000 employees say key product decisions take one to two months or more, against 30% of mid-market organisations.
This guide covers what an experiment board is, what to put on it, how to run it, and how to connect learning to decisions.
Key Takeaways
- An experiment board makes assumptions, hypotheses, evidence and decisions visible.
- Track learning flow, not completed tasks.
- Entry and exit rules, WIP limits and dedicated analysis keep experiments from going stale.
- The best boards link customer evidence to strategy, delivery and outcomes.
What Is an Experiment Board?
A working definition
An experiment board is a visual system for turning uncertain product assumptions into structured tests, evidence and decisions. Grace Ng of the Lean Enterprise Institute describes the original board as a tool for turning ideas into experiments and recording pivots.
The typical flow:
- Idea or assumption
- Prioritisation
- Experiment design
- Execution
- Analysis
- Decision: continue, change direction, or gather more evidence
What it is used for
The board makes experimentation visible, clarifies ownership and preserves what the team learned. It differs from a roadmap or task tracker because its primary unit is an uncertain belief being tested, not a delivery activity being completed.
Outcome-oriented roadmaps describe the problem to solve. Kanban visualises a workflow. An experiment board asks a different question: should we keep going?
Why it matters more as teams scale
When several teams test related assumptions from different evidence sources, confusion follows. A shared board should answer four questions:
- Why does this experiment exist?
- What evidence informed it?
- What happened?
- What decision followed?
Designing an Experiment Board
Choose stages that match the real learning flow
Start small: Assumptions, Ready, Running, Analysis, Decision/Archived. Give every column an entry and exit rule. An experiment shouldn't enter Running until its hypothesis, method, owner and evidence plan are clear.
Add columns such as Blocked, Recruiting or Ready for Delivery only when a real problem demands them.
Define the experiment card
One card is one meaningful experiment, not a bundle of research and delivery tasks. Each card carries:
- Customer or segment
- Problem and assumption
- Hypothesis and test method
- Owner and timebox
- Success criteria
- Evidence links
- Resulting decision
Prioritise the riskiest assumptions
Strategyzer's Assumptions Map plots evidence against importance. Focus first on important assumptions with the least evidence, the ones that could sink the bet. Also weigh how cheaply and quickly you can get useful evidence.
Manage work in progress
Cap experiments in Running and Analysis. The Kanban Guide requires explicit WIP control but names no universal number, so pick a limit your team can actually execute and interpret. Finishing one experiment before opening three more is how learning flows.
Design for traceability
Link each experiment to the customer evidence that prompted it, the strategic bet it supports and any delivery work that follows. More columns won't help future teammates. Preserved reasoning will.
How to Create and Populate an Experiment Board
Start with a decision, not a solution
Name the decision first: is this customer problem worth solving, or does this behaviour solve it?
Hypothetical B2B SaaS example: a team sees churn among accounts that run scheduling. Instead of designing a feature, they ask whether dispatchers, who never appear in the product model, are a real daily user group. The decision: pursue that problem or not.
Turn assumptions into testable hypotheses
"Customers want this feature" is untestable. Rewrite it with the customer, behaviour, context and the evidence that would shift confidence:
We believe that dispatchers at mid-sized logistics accounts will share a schedule link with a colleague within a week of first use, because they coordinate daily with drivers.
Where relevant, separate assumptions by type: customer, problem, solution, desirability, usability, feasibility and business model. Cagan's four risks (value, usability, feasibility, viability) are a common starting set.
Select the smallest useful experiment
Match the method to the question:
- Interviews
- Prototype tests
- Concierge trials
- Landing pages
- Pre-sales conversations
- Behavioural analysis
Evidence gets stronger the closer a test is to a real buying situation. A pre-sale says more than an interview opinion.
Agree on success criteria first
Decide what supports, weakens or leaves the hypothesis unresolved before collecting data. This is a decision rule, not a guarantee. It protects interpretation from hindsight and confirmation bias.
Capture evidence and the decision
Record the essentials before you close the loop:
- Source links, dates and participants or data scope
- Key observations and limitations
- The conclusion and next step
A reusable card, adapted from Strategyzer's Test and Learning Cards:
Title:
Customer / segment:
Problem:
Assumption:
We believe that...
To verify that, we will...
And measure...
We are right if... / We are wrong if...
Owner / timebox:
Evidence links:
We observed:
From that we learned:
Decision and next step:
The card ends with a decision, not a parking spot in Done.
Running Experiments as a Team
Establish a working agreement
Define what each stage means, who can move a card, who owns execution and who makes the final call. Agree labels for blocked work, unresolved evidence, cancelled tests and follow-ups.
Use a cadence that supports flow
- Replenish Ready with experiments the team can start
- Review experiments in progress
- Unblock stalled work
- Schedule analysis while findings are fresh
- Hold a regular learning review
Add a short retrospective on what helps experiments move, where they stick and which rule should change. Teresa Torres's continuous discovery definition includes at least weekly customer touchpoints, so build that rhythm into the cadence.
Treat analysis as part of the experiment
Finishing interviews or collecting responses isn't the end. Separate raw observations from themes, interpretations, confidence and the decision the evidence supports. Affinity diagramming helps cluster findings into themes.
Make blocked work visible
Flag blockers such as unavailable customers, missing data access, compliance questions or another team's dependency. Give each an owner and next action so the board explains slow flow.
Move from learning to action
Legitimate outcomes include:
- Continue the bet
- Modify the hypothesis
- Test a different customer or problem
- Stop
- Move to delivery with named remaining risks
Feed results into the next experiment and update strategy, roadmap or outcome reviews. Don't treat "validated" as permanent when evidence is narrow, old or from another customer context.
Improving the Board as the Team Scales
Avoid common failure modes
- Using the board as a second task tracker
- Writing experiments with no decision to inform
- Running too many tests at once
- Moving cards to Done without analysis
- Vague criteria and premature "validated" claims, which create false confidence
Improve the system through evidence
Review the board for signals that the process is breaking down:
- Ageing experiments
- Repeated blockers
- Abandoned cards
- Analysis queues
- Decisions without evidence
Add a column, label or approval step only when it fixes a demonstrated problem.
Connect the board to a broader product integrity system
Isolated boards, documents and feedback repositories eventually fall short. Shorter Loop is built for product organisations that need to keep customer evidence, assumptions, strategy, delivery work, decisions and outcomes connected as teams grow. It treats outcomes as evidence for the next decision: the same loop a good experiment board is meant to start.
Frequently Asked Questions
How much does the board console cost?
Pricing depends on the product behind the board. Experiment boards usually ship inside a product-management platform, so check that vendor's current pricing page for the plan you need.
What is board software used for?
It helps teams visualise work, coordinate activity, assign ownership and preserve progress. An experiment board focuses on learning and product decisions.
What should an experiment board include?
Capture the assumption, hypothesis, customer or problem, test method, owner, success criteria, evidence, analysis and the resulting decision.
What is the difference between an experiment board and a Kanban board?
Kanban manages workflow. An experiment board manages uncertainty, evidence and decisions, though it can use Kanban-style flow.
How do you prioritise experiments?
Weigh risk, uncertainty, potential impact and the speed or cost of getting useful evidence. Test assumptions that could invalidate the bet first.
When should an experiment move to done?
Only once evidence is captured and analysed enough to support a documented decision or next step.
