What a product decision log is
A product decision log is a dated list of the calls your team made about what to build. Each entry says what was decided (build, defer or reject), why, on what evidence, who made the call, and what would make you look at it again.
It is not a roadmap and not a backlog. A roadmap says what you plan to do. A backlog holds what you might do. The decision log holds the reasoning, including for everything you chose not to do, which is the part that is usually lost.
Why teams need one
Six months after a decision, someone in sales asks why a request was deferred, a new PM proposes the same idea again, or an engineer asks why a feature exists at all. Without a record, the team rebuilds the context from memory, Slack threads and meeting notes, or argues the decision again from scratch.
Software architects met this problem first. In 2011 Michael Nygard wrote that “one of the hardest things to track during the life of a project is the motivation behind certain decisions”, and that someone new to a project either blindly accepts a past decision or blindly reverses it (Documenting Architecture Decisions). His answer, the architecture decision record (ADR), is a short note per decision with its context, the decision, its status and its consequences. A product decision log applies the same idea to product calls.
The cost of skipping it is real. Pendo’s 2019 Feature Adoption Report found that 80% of features in the average software product are rarely or never used, across 615 Pendo subscriptions (Pendo, 2019). A log that ties each build decision to its evidence is how you find out which bets paid off.
What to record: a template
Keep each entry short. These fields are enough:
| Field | What goes in it |
|---|---|
| Decision | One line: what you decided, about which problem. |
| Status | Build, defer or reject. |
| Date and owner | When it was decided and who made the call. |
| Evidence | Links to the customer feedback, accounts, revenue and usage it rested on. |
| Reason | Why, in a sentence or two. The trade-off you accepted. |
| Alternatives | What else was on the table and why it lost. |
| Revisit condition | What should reopen it: a date, a number of new requests, or another piece of work shipping. |
Revisit conditions: the field that makes the log useful
Most decision log templates already include a review date. Productboard’s template, for example, has a review date and a prompt for what would change the decision (Productboard). The problem is that nothing watches that field. The date passes, the requests keep coming, and nobody looks.
Write conditions that can be checked:
- A date: “Look again after 1 March.”
- A threshold: “Look again if more than 50 customers raise this.”
- A dependency: “Look again once the new permissions model ships.”
Then make sure something checks them, and that the right people hear when one fires.
Where decisions get lost
- In meetings, where the reasoning is said out loud and never written down.
- In Slack threads that nobody can find a quarter later.
- In a decision doc that was filled in once and never opened again.
- In tickets, which record what was built but not what was rejected or why.
How to keep it without extra work
- Write the entry at the moment of the decision. A reason written a week later is a reconstruction.
- Link the evidence, do not copy it. A link to the feedback and the accounts behind it stays checkable. See how to prioritize feature requests by revenue for what that evidence should include.
- Log the no’s. Deferred and rejected decisions are the ones people ask about later.
- Review deferred items when their condition fires, not on a calendar ritual nobody keeps.
- Make it readable by your AI tools too, so an agent drafting a spec knows what was already decided. See how to give AI agents product context.
How purpal keeps the log for you
In purpal, every build or defer decision on a theme is recorded, with the reason you give and the evidence it rested on. When you defer, you can set a revisit condition: a date, a count of new customer requests, or another spec being pushed. purpal watches it, and when it fires the theme comes back for review by email, in Slack and in the app, with the original reason next to the new evidence. The decisions page lists every call and why it was made.
Questions
What is the difference between a decision log and a RAID log?
A RAID log tracks risks, assumptions, issues and dependencies for a project. A product decision log tracks the reasoning behind product calls, across projects, including the work you chose not to do.
Should rejected ideas go in the log?
Yes. They are the decisions people most often argue over again, and the reason is what stops that.
How long should an entry be?
A few lines. If it takes longer than five minutes to write, it will not get written.
Who owns the log?
The person who makes the call writes the entry. Usually that is the PM or head of product.