Assumption Register
What Is an Assumption Register?
An assumption register is a maintained record of beliefs a team relies on when making product decisions, together with their evidence, ownership, current status, and review conditions. It makes uncertainty visible over time so a belief does not become an unquestioned fact simply because it appeared in an earlier plan.
In product work, the register may track assumptions about customers, demand, pricing, behavior, delivery, or operating constraints. “Assumption log” is a common related label. Formats vary, and the fields described here are a practical approach rather than a universal product-management standard.
What Does the Register Record?
An entry should make the belief precise enough to inspect and connect it to a consequential choice. Useful fields include:
- Assumption: what the team currently believes, including the relevant customer or context.
- Importance: which decision depends on it and what changes if it is wrong.
- Evidence: links to observations, tests, and known limitations.
- Owner: who maintains the entry and coordinates the next investigation.
- Status: the team's current assessment and its rationale.
- Next action and review trigger: what will be checked, by when, or after which event.
Use a stable identifier when several decisions or requirements depend on the same belief. Keep the date and context of important changes so a later reader can distinguish the original assumption from the current assessment.
Status labels should have agreed meanings. “Untested,” “partly supported,” “contradicted,” and “no longer relevant” are possible choices. A label such as “validated” still needs to state the conditions and evidence it covers; it should not imply permanent certainty.
Assumption Register vs. Assumption Mapping
Assumption mapping helps surface and rank beliefs by importance and evidence, often to choose the next tests. A register keeps the selected beliefs and their evolving state available after that exercise.
The two can work together without becoming the same artifact. A map can guide the first experiment; the register records what happened and whether the resulting evidence changes the decision. Mapping every minor belief is unnecessary if it does not affect a meaningful choice.
Keeping Evidence and Interpretation Separate
Validation evidence records what was observed under particular conditions. The register also captures the interpretation: how much that observation supports the belief and what remains uncertain.
When an assumption can be investigated, express it as a testable hypothesis and link an appropriate product experiment. The entry should make clear what evidence would challenge the belief, not collect only encouraging signals.
A review may be triggered by a test result, a new segment, a pricing change, or a dependent decision approaching commitment. The owner updates the assessment and identifies which plans may need reconsideration.
Assumption Register Example
In a hypothetical reporting product, a roadmap depends on the belief that agency managers review client results weekly. The register records the target segment, supporting interview accounts, the owner, and a planned check of actual review behavior.
The next study finds that several agencies review monthly instead. The team narrows the belief to a particular account type and revisits its proposed weekly workflow. A decision log records the resulting choice; the assumption entry preserves the belief and evidence behind it.
The register is useful because the finding changes a decision. Updating status fields without reviewing dependent choices would leave the uncertainty documented but unmanaged.