An outcome bet is a statement of intent with enough structure to be proven wrong.
Most teams write tickets. Some write specs. Almost none write down what they actually believe will happen as a result of shipping the work - stated precisely enough to evaluate after the fact.
The Outcome Bet Template is a one-page artifact filled out before development begins. It captures the hypothesis, the measurement plan, the window, and the stakes. When the window closes, the confirmation owner reads the results and files the record.
This is not a postmortem. It is a pre-mortem structure. The team writes it when they still believe in the bet, before the data makes them revise their memory of what they thought would happen.
Write it before the sprint. Before the spec. Before any code. Once the window opens, the hypothesis is locked.
The Bet
Describe the specific change, feature, or intervention being shipped. Be precise: a vague feature description produces an unfalsifiable hypothesis.
State the outcome you expect. Use observable, measurable language. Avoid 'improve', 'increase', or 'enhance' without quantification.
State the causal mechanism. Why should this change produce that outcome? This is the part most teams skip. It is also the part that breaks first.
The Measurement
The single metric that will determine whether this bet was confirmed or denied. One metric. Not a dashboard.
The current measured value of the primary metric before the window opens. If no baseline exists, the bet cannot be evaluated. Stop here and instrument first.
The specific numeric value the primary metric must reach or exceed for the bet to be confirmed. This number is set now, not after the window closes.
A supporting metric that should move in the expected direction if the primary mechanism is real. Not a substitute for the primary metric, but a useful corroboration.
The Window
The date the measurement period begins. Typically the date the change reaches 100% of the intended audience or cohort.
The date the measurement period ends. Set this before the window opens. Do not extend the window because the results are inconvenient.
The minimum number of users or sessions required before the results are statistically meaningful. If exposure is not reached before the window closes, record as inconclusive and state why.
The Structure
Yes or No. If yes: state the holdout percentage and how the holdout group will be maintained for the duration of the window. Without a holdout, you are observing, not measuring.
List every event or signal that must fire for this bet to be evaluated. Name each event explicitly. Include what it captures and when it fires. Vague instrumentation plans produce unmeasurable windows.
The name of the person who confirmed the instrumentation is firing correctly in production before the window opened. Not 'will verify' - verified. Past tense. Signed.
The Stakes
P0: Core hypothesis - denial requires immediate strategic response. P1: Important but not critical path. P2: Supporting hypothesis - outcome is informative but not decision-forcing.
What happens next? What decisions does confirmation unlock? Who will be told, and what action follows? Confirmation without a next step is just a measurement.
What happens next? Is the feature rolled back? Is the team's roadmap reconsidered? Denial must have a defined consequence or the bet was not serious.
What is the minimum condition required to re-run the bet? Is a re-run warranted? What changes: the window length, the exposure threshold, the instrumentation? Inconclusive is not the same as confirmed.
Ownership
The person who wrote this hypothesis and is accountable for its accuracy. This person is not necessarily the one who confirms it.
The person accountable for ensuring the instrumentation is live, the baseline is recorded, and the window data is pulled correctly when the window closes.
The person accountable for reading the results, filing the confirmation record, and triggering the next action. This role must be named before the window opens.
The date and calendar invite reference for the session where results are reviewed. If this event is not on the calendar before the window opens, it will not happen.
Sign-Off
The hypothesis is not falsifiable
If no possible outcome could count as denial, you have not written a hypothesis. You have written a rationalization. Rewrite the bet so that a specific result would force you to say it was wrong.
The threshold is set after the window closes
When the team sets the success threshold after seeing the results, they will always find a way to confirm the bet. The threshold must be recorded before the window opens. No exceptions.
The measurement window is too short
A window closed before meaningful exposure accumulates produces noise, not signal. If the behavior you are measuring takes time to manifest, the window must be long enough to capture it. Minimum exposure is not optional.
Instrumentation is wired after the window opens
Events added after the window opens are missing the data they were designed to capture. Verify instrumentation in staging, confirm it in production, then open the window. Never in the other order.
Start writing
your first bet
Copy the template as Markdown and paste it into your team's documentation tool. Fill it out before the next sprint begins.
Based on the framework in The Output Trap by JP LeBlanc
Free to use. No attribution required.