COMMON PITFALL
Product decision log: a verdict is not a reason
A log entry is worth keeping only if it records why the call was made, not just what was decided.
By Michael Tor · October 2026
A product decision log is only worth keeping if each entry records why the call was made, not just what was decided. A line like "Decided: ship SSO before audit logs" tells the next person the verdict and nothing they need to keep it or change it on purpose. When the call changes, you write a new entry that supersedes the old one.
Who is this for?
Product managers, product leads, and product-minded founders who already keep a decision log. You might use a Notion page, a Slack channel, or "Decided:" lines at the bottom of meeting notes. The tension is that the log exists, so the team believes its calls are documented. But a new PM, an executive, or the same team six months later can read what was decided and not why. As Michael Nygard put it in his 2011 essay on documenting decisions, without the rationale, the only moves left are to blindly accept the decision or blindly reverse it.
What is the verdict-only failure mode?
The verdict-only log records outcomes after the meeting. Entries like "Decided: X" carry no question, no losing options, no reasons, and no reopen trigger. It looks like memory, but it is a list of outcomes that hindsight is free to rewrite. As Shane Parrish of Farnam Street notes about decision journals, our brains edit the past. Two symptoms follow. First, the same debate restarts because nobody can see what was already ruled out. Second, when the call changes, someone edits the old line, erasing the history of how the team got here.
What makes a decision log entry worth keeping?
A useful entry is written before the work starts.
The question is written down.
Record what was being decided, not only the answer, framing the problem before you act (Farnam Street).
The serious alternatives are listed.
Note the options that lost and why they were rejected, as Martin Fowler recommends.
Evidence and assumptions are labeled separately.
Split what the team actually knew from what it was betting on.
A reopen trigger and a confidence level are set.
Define what context change would make the team look again, and how sure it was (Fowler).
It is written before the work starts.
Write it before you act, not reconstructed after (Farnam Street), so you stop shipping your way out of thinking.
A changed call is superseded, not edited.
A new entry links back to the old one, preserving history (Nygard, Fowler).
Consider a hypothetical example. The verdict-only line says: "Decided: SSO before audit logs." The full entry looks like this: Question - which enterprise requirement do we build first this cycle? Options that lost - audit logs first (lost: fewer deals in the pipeline ask for it); build both at half depth (lost: neither would be complete, and discovery is for killing ideas). Evidence - which deals asked for SSO. Assumptions - that SSO is the blocker, not price. Confidence - medium. Reopen if - a deal is lost on audit logs. Written - before the sprint started.
When does a decision log help?
It helps when entries are short and written before the work. As Fowler notes, the act of writing clarifies group thinking. It helps when a newcomer can see the options that lost and stop reopening settled questions. The reopen trigger tells the team exactly when a call should be revisited, and superseded entries keep the history intact.
When does it hurt?
It hurts when it becomes after-the-meeting minutes nobody reads. It fails when every small call gets an entry and the log turns into noise; keep it for consequential calls. It hurts when entries are long documents nobody updates, as Nygard warns, or when old entries are quietly edited so the log always looks right.