A decision journal practice for product teams

What is a decision journal?

A decision journalis a record you write at the moment of deciding: what you decided, what you expect to happen, and how confident you are. Later, when reality has reported back, you compare. The practice comes from the world of investors and poker players, where it exists to fight two biases with teeth: hindsight bias (“I knew it all along”) and outcome bias (judging a decision by its result rather than by what was knowable at the time).

The classic version is personal and private. Product teams can steal the mechanism wholesale, with one change: the unit of record is the team decision, not the individual one. Roadmap bets, scope cuts, build-vs-buy calls, pricing changes: these are the decisions whose quality compounds, and whose reasoning evaporates fastest.

Adapting the practice to a product team

A team journal differs from a personal one in three ways, each of which makes it more valuable and harder to keep:

• Positions replace private conviction.An individual records their confidence; a team records who stood where. “Design supported, sales opposed citing two at-risk accounts” is the team equivalent of a confidence percentage, and it is exactly what nobody remembers accurately a quarter later.
• The expected outcome must be falsifiable.“We expect this to improve activation” scores as true whatever happens. “We expect trial-to-paid conversion to recover to March levels within two cycles” can actually be wrong, which is what makes reviewing it worthwhile.
• The journal must survive turnover.A personal journal dies with its author's attention; a team journal is only useful if the next PM inherits it. That means it lives somewhere shared and searchable, not in someone's notes app.

What to record for each decision

Start from the standard five fields of a decision record (question, decision, date, people and positions, reasoning) and add the two journal-specific ones:

• Expected outcome. One falsifiable sentence about what should be true if the decision was right.
• Revisit date.When you will check. Not “eventually”: a date, set the day you decide.

Do not journal everything. A product team makes hundreds of micro-decisions a month; journaling them all produces a write-only archive. The threshold that works: journal any decision you would bother arguing about in a quarterly review, typically two to five per month. For the capture mechanics, the same options apply as for any decision documentation: a convention or a tool. Withose (our product) fits this practice well: it drafts the record from the Slack or Teams thread where the debate happened, records stakeholder positions explicitly, and lets you set a revisit reminder when you finalize, which covers the revisit field; the falsifiable expectation is one sentence you write into the record itself. The product teams page walks through a scope-cut example end to end.

The revisit is the practice

Here is the uncomfortable truth about decision journals: writing entries feels like the practice, but the entries are just the setup. The practice is the revisit, the fifteen minutes a quarter where the team reads what it expected and compares it to what happened. Skip the revisits and you have built a slightly unusual decision log (still useful, but a different thing).

The revisit conversation has exactly three outcomes, all valuable. The expectation held: notice what the reasoning got right and trust that reasoning style more. The expectation broke: find the assumption that failed, without punishing the decider, because the point is calibrating judgment, not assigning blame. Or the expectation turned out to be unfalsifiable after all: write a sharper one next time. Teams that run this loop for two or three quarters report the same effect the investors do: arguments get shorter, because everyone has seen, in writing, how confident wrongness sounds.