The Decision Log: Ending the 'Why Did We Build This?' Amnesia

A product decision log is a running record of the choices a team made, the options it rejected, and the reasoning behind each call — captured at the moment of decision, not reconstructed later from memory. It answers "why did we build this?" without a meeting. The lightest version borrows its shape directly from software engineering's Architecture Decision Records.

Quick Answer: Log every consequential decision as context → options considered → choice → rationale → a revisit trigger. Store it where the team already works, keep entries under a page, and review the log before proposing anything that resembles a past decision.

Six months after a launch, someone asks why the team chose a monolith over microservices, or why onboarding skips email verification, or why the pricing page dropped the annual toggle. Nobody in the room was there, or they were there and forgot. The Slack thread is gone, the meeting notes were never taken, and the person who made the call switched teams. So the debate restarts from zero — and often lands somewhere worse than where it started, because the constraints that shaped the original decision aren't visible anymore.

This is not a memory problem. It's a capture problem. Teams generate rationale constantly, in real time, when it's cheap to write down — and then let it evaporate because nothing about the workflow demands it survive.

Why Decisions Get Re-Litigated Instead of Referenced

Teams re-litigate settled decisions because the rationale was never written down separately from the outcome — so all that survives is "we built X," with none of the constraints, trade-offs, or context that made X the right call at the time. Six months later, X looks arbitrary, and arbitrary-looking decisions invite challenge.

This is a predictable failure of institutional memory, not a character flaw in any particular team. A few forces compound it:

• Turnover erases context faster than product surface area accumulates. The person who decided leaves; the decision remains, orphaned.
• Meeting notes capture action items, not reasoning. "We'll ship the simpler flow" gets recorded; "because legal flagged the compliance cost of the alternative" doesn't.
• Slack and email are write-once, read-never. Rationale exists somewhere in a thread, but nobody can search for it six months later, and even if they find it, the thread lacks the surrounding context.
• New team members have no way to distinguish a deliberate trade-off from an accident. Without a record, every existing behavior looks equally arbitrary and equally up for debate.

Nobel laureate Herbert Simon's work on bounded rationality is useful here: decisions are made under real constraints — incomplete information, limited time, competing priorities — and are "satisficing," not optimal. A decision log is the artifact that preserves which constraints were binding at the time, so a future reader can tell whether those constraints still hold. Without it, every past decision looks like it was made in a vacuum, which makes it look wrong by default.

The Cost Shows Up as Repeated Work, Not Just Repeated Debate

The visible cost is the meeting where the same argument happens again. The larger, less visible cost is the work done in the gap: a new hire builds a feature the team explicitly rejected eighteen months ago, or an engineer reverses a deliberate trade-off because the ticket only recorded the "what." Teams that treat product operations as a discipline — not just a title — build decision capture into the operating system precisely because this failure mode compounds with headcount and roadmap age.

What a Lightweight Decision Record Actually Looks Like

A lightweight decision record has five fields — context, options considered, choice, rationale, revisit trigger — and fits on one page. It's modeled directly on the Architecture Decision Record (ADR) pattern that Michael Nygard popularized in 2011, adapted from code-level architecture calls to product-level calls.

The ADR format survived over a decade of software practice because it resists two opposite failure modes: it's too heavy to be a full spec, and too structured to devolve into a vague paragraph nobody re-reads. Product decisions need the same discipline, because "should we gate this feature behind a paywall" carries the same weight as "should we use Postgres or DynamoDB" — it shapes everything built downstream.

The Five-Field Template

A filled-in example, kept intentionally short:

Context: Onboarding conversion dropped after adding a mandatory email verification step; support tickets about lost verification emails were rising. Options considered: (1) Keep verification, improve deliverability. (2) Make verification optional, gate sensitive actions instead. (3) Remove verification entirely. Choice: Option 2 — verification becomes optional at signup, required only before payment or data export. Rationale: Verification's real value is protecting payment and export flows, not gating account creation; deliverability fixes alone didn't move conversion in a two-week test. Revisit trigger: If fraud or chargeback rate on unverified accounts exceeds 0.5%, or by Q3 planning, whichever comes first.

What Belongs in the Log vs. What Doesn't

Not every choice deserves a decision record — logging the color of a button wastes the same discipline that makes the practice work for decisions that matter. A reasonable filter: log it if reversing the decision later would cost real time, money, or trust, or if you can already predict someone will ask "why" in six months.

• Log: pricing model changes, build-vs-buy calls, scope cuts under deadline pressure, architecture choices with multi-quarter lock-in, anything reversing a prior public commitment.
• Skip: copy tweaks, one-off bug triage calls, decisions fully reversible within a sprint with no external dependency.
• Borderline — use judgment: feature prioritization calls that trade off named customer requests against roadmap capacity; these often deserve a shorter entry rather than none.

The Shift: Capturing the "Why," Not Just the "What"

The shift that makes a decision log work is writing down why, not just recording what was decided — because the "what" is usually still visible in the product itself, while the "why" is the only part that disappears. A changelog tells you a feature shipped; only a decision record tells you what it was traded against.

This is a genuine behavior change, not just a new document type. It requires treating rationale as a deliverable of the decision-making process itself, alongside the decision. A few practices make that stick:

1. Capture at the moment of decision, not after. Rationale is cheap to write down in the meeting where it's discussed and expensive to reconstruct a week later, once the reasoning has already blurred in everyone's memory.
2. Assign a single owner per entry. A decision record with no named owner tends to never get written; ambiguous ownership is the most common reason logs go stale.
3. Write the rejected options down, not just the winner. The alternative that lost is exactly what a future team member will re-propose — heading it off in the record saves the re-debate entirely.
4. Keep it to one page. A decision record that requires ten minutes to read gets skipped; the discipline only survives if writing one costs less than the value of the search it will save.
5. Link the record to the artifact it governs — the PRD, the ticket, the roadmap item — so anyone looking at the output can find the reasoning without hunting for it separately.

Harvard Business School's research on decision journals (popularized by writer and investor Michael Mauboussin's work on decision quality) finds a similar effect in a different domain: teams and individuals who log their reasoning before an outcome is known make measurably better-calibrated decisions over time, because the record separates decision quality from outcome luck. A good decision can still produce a bad outcome — the log is what lets you tell the difference in hindsight.

The Revisit-Date Practice: Decisions Aren't Permanent, They're Time-Boxed

A revisit trigger turns a decision from a permanent fact into a time-boxed hypothesis, forcing a scheduled check on whether the original constraints still hold. Without one, decisions either calcify long past their usefulness or get challenged at random by whoever happens to notice them.

How to Set a Good Revisit Trigger

A revisit trigger is either a date ("re-check at Q3 planning") or a condition ("re-check if churn on this segment exceeds X"), whichever is more naturally tied to how the decision could become wrong. Vague triggers like "revisit if needed" defeat the purpose — they never fire because nobody is watching for "needed."

• Date-based triggers suit decisions tied to a planning cycle, a contract renewal, or a known external event (a platform policy change, a competitor's roadmap).
• Condition-based triggers suit decisions tied to a metric — churn, error rate, support volume — where the threshold is a better signal than the calendar.
• Combine both when either could independently invalidate the decision, as in the onboarding example above.

The practice mirrors what MIT researcher Amy Edmondson's work on organizational learning calls "reflective reconsideration" — deliberately scheduled review, rather than review triggered only by crisis. A team that only revisits decisions when something breaks is running its decision-making entirely in reactive mode.

Reviewing the Log Before New Proposals

The revisit trigger only pays off if someone actually checks the log before proposing something that resembles a past decision. Make this a lightweight, boring habit rather than a governance step: a two-minute log search before a PRD kickoff or roadmap review, tied into the PM workflows worth automating rather than left as one more thing to remember.

Where the Decision Log Fits in the Org

A decision log is only as durable as the process around it — who owns entries, where they live, and who's accountable for keeping them current. This is squarely product-ops territory: the practice needs a home, not just a template.

Teams without dedicated product ops often let decision logs die because no one is accountable for maintaining them across projects — a symptom covered in when to hire your first product ops person. Once that role exists, decision-log ownership usually sits with product ops rather than individual PMs, precisely because it needs to survive any one person's tenure — a structural question addressed in how product ops org structure and reporting lines should work in practice.

A Note on Where Decision Logs Intersect Other Practices

Decision logs work best alongside other durable-context practices rather than in isolation. A team already mapping customer jobs to be done or tracing a customer journey has adjacent muscle memory for writing context down instead of trusting recall — the decision log is the same discipline applied to internal choices instead of customer behavior.

How Prodinja Supports This Practice

Key Takeaways

• A decision log separates the "what" from the "why" — the what usually stays visible in the product; the why is what disappears without a record.
• Use a five-field template: context, options considered, choice, rationale, and revisit trigger, kept to one page per entry.
• Log decisions that are costly to reverse or predictably questioned later, not every minor call — over-logging kills the habit as fast as never logging.
• Write down the rejected options, not just the winner — the rejected path is what future teams tend to re-propose.
• Set a revisit trigger on every entry — a date or a metric threshold — so decisions get a scheduled check instead of calcifying or getting challenged at random.
• Assign a single owner per entry and review the log before new proposals so the practice compounds instead of decaying.
• Give the practice organizational ownership, typically through product ops, so it survives individual turnover.