Decision Log Template
A running log of product decisions — what was decided, why, who approved it, and what alternatives were considered. Prevents re-litigation of closed debates and builds institutional memory. Free to copy, download, and use. No signup required.
# Decision Log **Product / Feature:** [Product or initiative name] **PM Owner:** [Name] **Last Updated:** [Date] --- ## How to Use This Log Add a new entry every time a non-trivial decision is made — one that would cause confusion or re-litigation if forgotten. Include decisions that were overruled or reversed (those are the most important ones to document). --- ## Decision Entries --- ### Decision #001 **Date:** [Date] **Status:** [ ] Open · [ ] Decided · [ ] Reversed **Decision:** [One sentence — what was decided] **Context:** > [1–3 sentences: the situation that required a decision. What was the background?] **Options Considered:** | Option | Pros | Cons | |---|---|---| | **Option A** — [Label] | [Pros] | [Cons] | | **Option B** — [Label] | [Pros] | [Cons] | | **Option C** — [Label, if applicable] | [Pros] | [Cons] | **Decision Rationale:** > [Why this option was chosen. What was the deciding factor? What was explicitly accepted or traded off?] **Approved By:** [Name(s) + role] **Stakeholders Informed:** [Who was told and how] **Constraints / Assumptions:** - [e.g. "Assumes backend migration is complete by Q3"] - [e.g. "Valid only if usage stays under 10K requests/day"] **Reversal Criteria:** [What would cause you to revisit this? e.g. "If error rate exceeds 1% in first 30 days"] --- ### Decision #002 **Date:** [Date] **Status:** [ ] Open · [ ] Decided · [ ] Reversed **Decision:** [One sentence] **Context:** > [Background] **Options Considered:** | Option | Pros | Cons | |---|---|---| | **Option A** — [Label] | | | | **Option B** — [Label] | | | **Decision Rationale:** > [Why this option] **Approved By:** [Name + role] **Stakeholders Informed:** [Names] **Constraints / Assumptions:** - [Assumption 1] **Reversal Criteria:** [Trigger to revisit] --- ### Decision #003 **Date:** [Date] **Status:** [ ] Open · [ ] Decided · [ ] Reversed **Decision:** [One sentence] **Context:** > [Background] **Options Considered:** | Option | Pros | Cons | |---|---|---| | **Option A** | | | | **Option B** | | | **Decision Rationale:** > [Rationale] **Approved By:** [Name] **Stakeholders Informed:** [Names] **Reversal Criteria:** [Trigger] --- ## Reversed Decisions > Move entries here when a decision is overturned. Include a note on why it was reversed. | # | Original Decision | Reversed On | Reason for Reversal | |---|---|---|---| | #00X | [What was decided] | [Date] | [Why it changed] | --- ## Open Decisions (Parking Lot) > Questions that need a decision but haven't been resolved yet. | # | Question | Owner | Due | |---|---|---|---| | | [e.g. "Should we build the export feature in v1 or v1.1?"] | | | | | | | |
How to use this Decision Log template
Add an entry at the moment the decision is made
The decision log decays fast if you try to backfill it. The best time to write an entry is within 24 hours of the decision being made. Pull in the meeting notes or Slack thread and distill it into the template. 10 minutes now saves 2 hours of archaeology later.
Write the decision as a single declarative sentence
Not 'we discussed the modal approach' — 'we will use a slide-out panel instead of a modal for the insight detail view'. The test: could a new team member read this in 6 months and know exactly what was decided without asking anyone?
Always record the alternatives
The alternatives section is the most important part. If you only record what was decided, you'll re-open the same debate in 3 months. Recording what was *not* chosen and why is what closes debates permanently.
Set reversal criteria upfront
For every decision, ask: what signal would make us change our minds? If it's 'error rate > 1%' or 'three enterprise customers request this' — write it down. This makes revisiting decisions feel principled, not political.
Link the decision log to your PRD or epic
Add a 'Decision Log' section in your PRD that links to the relevant entries. Engineers and designers should know where to look when they're unsure why something was built a certain way. The log is only useful if people can find it.
Want a Decision Log grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
How is this different from meeting notes?
Meeting notes capture what was discussed. The decision log captures what was decided. Most meetings discuss many things and decide few. The log distills the outcome, the rationale, and the alternatives — in a format designed to be read in 30 seconds, not 30 minutes.
How granular should entries be?
Log decisions that, if forgotten or reversed without context, would cause confusion, rework, or conflict. 'We'll use UTC timestamps everywhere' is worth logging. 'We'll use a 14px font in the tooltip' is probably not. A good rule: if someone will ask 'why did we do it this way?' in 6 months, log it.
What about decisions made in Slack?
Slack is where decisions get made; the log is where they get recorded. Copy the key message thread into the context section, summarize it into one sentence, and add it to the log. Don't rely on search — Slack threads get buried and context is lost.
Should every team member maintain this log, or just the PM?
The PM owns the log, but anyone can add entries. Eng leads often make technical decisions that the PM needs to know about (e.g. 'we'll use a background job instead of synchronous processing'). Make the log collaborative — shared doc, Notion page, or section of the PRD.
What happens when a decision is reversed?
Don't delete the original entry. Move it to the 'Reversed Decisions' section and add a note explaining why it changed. Seeing a reversal is itself valuable context — it tells the team that the issue was properly considered twice, and under what conditions the team changed direction.
Other free templates