Hypothesis log
A template for running continuous discovery: capturing assumptions as falsifiable hypotheses, choosing the cheapest test that can settle each one, and recording the verdict — validated, killed or inconclusive.
The log is created during team mobilization, empty, alongside the backlog. It fills as soon as the team starts forming opinions about what to build — and gets its first real harvest during strategic event storming, where a fresh event map exposes a room full of assumptions at once. The product manager and product designer own it; the tech lead joins for feasibility spikes.
Writing a hypothesis
A hypothesis is not a feature request or a to-do. It’s a claim about the world that could turn out to be false, written so the team knows in advance what evidence would change its mind.
| Field | What goes here |
|---|---|
| Hypothesis | The falsifiable claim, in the form above. One claim per entry — compound hypotheses can’t be settled. |
| Source | Where it came from: an event-storming hotspot, a customer request, production telemetry, a support theme, a stakeholder’s conviction. Sourcing matters — patterns in where wrong assumptions originate are worth noticing. |
| Risk | Which of the four product risks this addresses: value, usability, feasibility or viability. Names the owner implicitly — value and viability sit with the product manager, usability with the product designer, feasibility with the tech lead. |
| Test | The cheapest activity that can settle it: customer interview, clickable prototype, fake door, concierge test, feasibility spike, telemetry query. If the cheapest available test is “build it and see,” say so explicitly — that’s a signal, not a plan. |
| Cost | Time-box for the test. Most entries should read in hours or days. An entry measured in weeks needs a cheaper test or a smaller claim. |
| Verdict | Validated, Killed, Inconclusive or Testing — plus the date and a one-line summary of the evidence. |
| Outcome | What changed because of the verdict: a candidate feature entering increment selection, a value map update, a replacement hypothesis, or nothing at all (which is a legitimate outcome for a killed idea). |
Verdicts
| Verdict | What it means, and what happens next |
|---|---|
| Testing | The test is running. Entries shouldn’t sit here long — if an entry has been “testing” for more than a couple of weeks, the test was too expensive. |
| Validated | The evidence supports the claim. The candidate feature carries that evidence into value mapping and increment selection. Move the entry to Hypothesis history once the work is selected. |
| Killed | The evidence contradicts the claim. Remove the candidate from consideration, note what you learned and — where the test surfaced a better idea — write the replacement hypothesis immediately. Move to Hypothesis history. |
| Inconclusive | The test didn’t settle it. Decide deliberately: sharpen the claim and re-test, or accept the risk and note that the decision is being made without evidence. Don’t let inconclusive entries drift — an unexamined “maybe” behaves exactly like an unexamined “yes.” |
Hypothesis log
| Verdict | Hypothesis |
|---|---|
| Testing 2026-03-04 | We believe brokers lose significant time to one-at-a-time document upload because the intake tool has no batch capability. If we add multi-file upload, we expect median intake completion time to drop by a third. We’ll know we’re wrong if watching brokers work shows the time is going somewhere other than the upload step.
|
| Validated 2026-02-19 | We believe first-time applicants abandon the application at income verification because they don’t have documents on hand. If we let them save and resume from a link, we expect completion rate for started applications to rise above 60%. We’ll know we’re wrong if abandonment stays flat or applicants don’t return to the link.
Evidence: 68% of applicants who used the link returned within 48 hours. Outcome: save-and-resume selected into the next increment. |
| … |
Hypothesis history
Settled hypotheses are retained here. The history is worth keeping: it shows the team what it used to believe, and a run of kills from the same source is a useful signal about where assumptions come from.
| Verdict | Hypothesis |
|---|---|
| Killed 2026-01-30 | We believe claims handlers want a configurable dashboard because they’ve asked for “more visibility.” If we ship a widget-based dashboard, we expect daily active use above 70%. We’ll know we’re wrong if handlers can’t articulate what they’d put on it.
Evidence: none of the five could name a widget they’d add. All five described the same single missing number — current queue age. Outcome: dashboard dropped. Replacement hypothesis written and validated the same week; the number shipped in the following increment as a header field. |
| … |