Glossary · Teams & Leadership

Decision Log

What Is a Decision Log?

A decision log is a structured record of important decisions made during product work. It captures what was decided, who owned the decision, why it was accepted, which evidence informed it, and whether it is still active.

A useful decision log preserves the reasoning behind a choice without reproducing every conversation that led to it. It gives team members a reliable place to check a decision after the meeting, message, or AI session where it was made.

What Should a Decision Log Include?

Each material decision should have its own entry containing:

Decision ID: A stable reference that can be linked from requirements, roadmap items, or backlog work.
Decision statement: A direct description of what was accepted.
Status: Proposed, accepted, superseded, reversed, or withdrawn.
Decision owner: The person with authority to make or approve the decision.
Date: When the decision was accepted and, when relevant, when it takes effect.
Context: The problem, constraint, or opportunity that required a decision.
Rationale: Why the chosen option was preferred.
Evidence: Research, data, customer feedback, or validation evidence that informed the choice.
Alternatives: The meaningful options considered and why they were not selected.
Affected work: Requirements, roadmap items, designs, backlog items, or metrics changed by the decision.
Review trigger: The evidence, date, or condition that should cause the team to revisit the decision.

How Does a Decision Log Work?

The team creates an entry when a decision creates a meaningful commitment, changes product direction, resolves a disputed question, or affects downstream work. Draft recommendations should not be presented as accepted decisions.

Clear product decision rights identify who may approve the choice. A responsibility framework such as DACI can distinguish the decision’s driver, approver, contributors, and people who need to be informed.

Once accepted, the entry should link to the artifacts it affects. If the team later changes the decision, it should create or link the replacement and mark the earlier entry as superseded. The old rationale remains available instead of being silently rewritten.

Decision Log vs. Meeting Notes

Meeting notes describe a discussion, including questions, updates, and possible actions. A decision log records the accepted outcome and the context needed to understand it later.

A meeting can produce several notes but no decision. It can also produce a decision that should remain discoverable long after the meeting notes become difficult to find. The log should link to the original discussion when useful, but it should not require a reader to reconstruct the outcome from a transcript.

Decision Log vs. Decision Traceability

A decision log stores the decisions themselves. Decision traceability connects those decisions backward to their evidence and assumptions and forward to the requirements, designs, code, releases, and outcomes they influenced.

The log is therefore one part of a wider traceability system. Recording a decision without linking its sources or consequences preserves history, but it does not provide a complete end-to-end trail.

Decision Log vs. Architecture Decision Record

An Architecture Decision Record documents one significant software architecture decision, including its technical context and consequences. A product decision log has a broader scope and may include customer, strategy, prioritization, pricing, roadmap, policy, and delivery decisions.

Architecture Decision Records may form part of a wider decision log, but product and technical decisions should keep the level of detail appropriate to their audiences and consequences.

Decision Log Example

A product team is deciding whether its first release should support guest checkout. Research shows that invited buyers often abandon registration, but the engineering estimate reveals that guest checkout would delay the release by six weeks.

The product lead accepts a narrower decision: keep account creation for the first release, reduce the required fields, and revisit guest checkout if registration drop-off remains above the agreed threshold after launch. The log records the owner, evidence, rejected options, affected onboarding requirement, and review trigger.

If new evidence later supports guest checkout, the team links the replacement decision and marks the original one as superseded. Future contributors can see that the earlier choice was conditional, not an unexplained permanent rule.

Why Is a Decision Log Useful?

A maintained decision log helps teams:

Stop reopening settled questions without new evidence.
Understand who had authority to make a decision.
Preserve rationale when team members change.
Identify work affected by a changed decision.
Give people and AI systems current decision context.

A decision log can act as the source of truth for accepted product decisions. It does not replace requirements, roadmaps, or delivery tools; it records the choices those artifacts should reflect.