Product decision log: what to record, a template, and how to keep it current.

What a decision log is for

Every product team makes decisions faster than it records them. The decision happens in a standup, a planning call, a customer conversation, or a Slack thread, and then it lives in the memory of whoever was there. Six weeks later, someone who was not there asks why the export is capped at 5,000 rows, and the answer is either a twenty-minute search through recordings or a shrug and a re-decision.

A decision log exists so that question has an answer. Not a list of everything that was said, and not a wiki page someone has to maintain, but one row per decision that a person can find by the part of the product it concerns.

The second job, which teams discover after they have kept one for a month, is showing which decisions were never actually made. A surprising number of things a team treats as settled turn out to be assumptions nobody wrote down.

The five fields, and the one that matters

What was decided. One sentence, in plain words, the way you would say it to a new joiner. "Collapse the profile step into step two." Not a paragraph.

Because. The reason, in one or two sentences. "Activation stalled at step three, the profile form." This is the field that gets skipped, and it is the whole point. Without it, the decision is a fact you can find; with it, the decision can be re-evaluated when the reason changes, and defended when it is challenged. When engineering asks six weeks later whether they can add a field back to the profile step, the reason answers them; the decision alone does not.

Who decided. A name, not a team. Decisions without a name get re-litigated because nobody feels entitled to defend them.

When. The date. Useful for ordering, and for spotting decisions that have quietly gone stale.

Source. Where the decision was made, precisely enough to go back to it: the meeting and, if you have a recording, the timestamp. "Standup, 19 March, 08:12." This is what turns the log from someone's word into a record. Anyone who doubts a row can check it.

Then one more, which is not a field about the decision but about the log: status. Active, superseded, or reopened. When the export cap moved from 10,000 rows to 5,000, the 10,000 row did not get deleted; it got marked superseded and the new row points back to it. That is how the log keeps its history, and history is what makes it trustworthy.

The template

Two formats, same columns. The CSV opens in Google Sheets or Excel; the Markdown pastes into a Notion or Confluence page as a table. Three sample rows are filled in so the shape is obvious; delete them and start with your last planning meeting.

A few rules that make it work:

• One row per decision, not per meeting. A meeting with three decisions is three rows.
• Group by product area, not by date. Sort by date within an area if you like, but the first filter is always "which part of the product."
• Never delete. Supersede, and link the rows.
• Log open questions too, in the same table, with status "open" and an owner. Half of what feels like a decision is a question nobody closed.

Why decision logs die, and what to do about it

Most decision logs are abandoned within a quarter, and it is never because the team stopped valuing them. It is because the log has one input: a person, usually the product manager, writing it up after every meeting. The first week they do. The third week a customer escalation lands on a Tuesday, the standup goes unlogged, and now the log has a gap, and a log with gaps is one nobody trusts, so nobody reads it, so nobody writes to it.

The fix is not more discipline. The fix is changing the input. Every decision in the log was said out loud in a meeting that was almost certainly recorded. The transcript already contains the what, the who, the when, and the source, and the reason is usually in the two minutes before the decision was announced. The manual step is copying those into rows. That is the step that can be automated, and it is the only step that was ever hard.

Where Wisibl fits

This is the specific thing Wisibl does. It reads meeting transcripts, from Fireflies or by upload, and documents, and produces the decision log you would have written: the decision, the reason it was given, who said it, when, and the moment in the transcript, filed under the product area it concerns. When a later meeting changes the decision, the earlier row is superseded, not lost. When someone asks "why is the export capped?", the answer comes with the row and the clip.

It does the open questions too, which is the part people underestimate: the things that were asked in a meeting and never answered, sitting in the same table as the decisions, waiting for an owner.

Start with the template if you want to see what your team's decisions look like on paper. Start with Wisibl if you already know, and want the log to write itself.