The launch went well, so the rushed go/no-go call now looks obvious. A hire struggled, so the warning signs now look impossible to miss. The result arrived, and your memory quietly edited the reasoning that came before it.
A decision journal interrupts that rewrite. Before an important choice resolves, record the decision, the alternatives, the evidence available now, your confidence, what would prove you wrong, and when you will review it. Later, judge the process separately from the outcome.
You do not need to log every choice. Use the method for decisions that are consequential, uncertain, repeatable, or likely to become the subject of a confident story afterward.
Why memory is a poor audit trail
Once you know what happened, the outcome can feel more predictable than it did in advance. A review by Neal Roese and Kathleen Vohs describes hindsight bias as a combination of memory distortion, changed beliefs about an event's likelihood, and changed beliefs about one's own ability to predict it (Perspectives on Psychological Science).
The underlying finding is not new. In Baruch Fischhoff's classic experiments, people who learned the outcome of historical events tended to see that outcome as more foreseeable, while underestimating how much the knowledge had affected their judgment (original 1975 paper). The studies were laboratory work, not a validation of decision journals for managers, but they establish the problem the journal is designed to resist.
Outcome bias is related but different. It appears when a result changes how we evaluate the quality of the decision that produced it. In five studies, Jonathan Baron and John Hershey presented participants with decisions whose available reasoning was held constant but whose outcomes differed. Favorable outcomes led to better evaluations of the decision or decision-maker (PubMed record and abstract). A later replication and extension supported the central effect while also noting limitations in the original design and questions that remain open (replication report).
These biases do not mean outcomes are irrelevant. Outcomes matter enormously. They simply answer a different question.
- Process question: Given what was knowable at the time, was this a reasonable decision?
- Outcome question: What happened after the decision?
- Learning question: What should change in the next comparable decision?
A good process can produce a bad result because uncertainty is real. A careless process can get lucky. If you collapse process and outcome into one score, luck becomes difficult to see and learning becomes theatrical.
The Decision Before Outcome Card
The useful unit is one card written before the result is known. It should take five to ten minutes, not become a second project-management system.
1. Decision
Write the choice as a concrete commitment with a boundary.
Weak: “We need to improve onboarding.”
Stronger: “For the next four weeks, we will replace the general welcome email with a role-specific first-step email for new team accounts.”
The stronger version makes later review possible. It says what will change, for whom, and for how long.
2. Alternatives
List the options you seriously considered, including “wait,” “gather more information,” or “run a smaller test” when those were real choices.
Do not manufacture ten alternatives to look thorough. Two or three credible paths are enough. The point is to preserve the choice set that existed before the winner made every other option look foolish.
For each option, add its main advantage and cost in one line. This reveals whether you compared alternatives on the same dimensions or merely built a case for the option you already preferred.
3. Evidence available now
Record the few facts that actually carry the decision. Separate them from interpretations.
Illustrative example — the values below are fictional and show the structure only:
- Fact: 31% of invited users in last month's cohort completed setup step three.
- Fact: six support conversations mentioned uncertainty about the first task.
- Interpretation: a role-specific email may reduce that uncertainty.
- Unknown: whether email is the bottleneck or whether the in-product step is unclear.
Keep source links or document names when the decision depends on them. A number without its cohort, time window, or definition can be more misleading than no number at all.
If the problem is that too many open loops are occupying your attention, use a short cognitive-offloading pass first. The decision card is for evaluating a choice, not for storing every task around it.
4. Confidence range
Write a range for the outcome you expect, not a ceremonial “high confidence.”
Fictional example: “I think there is a 55–70% chance that completion of step three improves relative to the prior four-week baseline, without increasing support requests.”
The range does not make your judgment scientific. It exposes two useful things: how uncertain you really are and which result you predicted. Avoid false precision when the evidence is thin. “About 40–60%” can be more honest than “57%.”
If several outcomes matter, name one primary expectation and one guardrail. Otherwise, almost any result can later be described as success.
5. Disconfirming signal
Write what would make you reduce confidence, stop, or choose another path.
Examples:
- setup completion remains within its normal range after enough comparable accounts have seen the change;
- support requests rise because the email and product give conflicting instructions;
- interviews show that users understood the first task but lacked the required permissions;
- the team cannot maintain the segmentation reliably.
This is the most important part of the card. It prevents the review from becoming a search for evidence that protects the original decision.
6. Review date
Choose a date when the relevant signal could reasonably exist. Reviewing too early rewards noise. Reviewing indefinitely late invites forgotten criteria and shifting goals.
Also name the owner and the decision that the review can trigger: keep, stop, extend, or redesign. If no later action is possible, ask whether the decision needs a journal at all.
Copyable decision journal template
Paste this into any notes or journaling tool:
The card is intentionally plain text so it travels well between a company wiki, a private journal, and a later Medium-friendly reflection.
How to review the decision after the outcome
Open the original card before writing your retrospective. Do not “clean up” its wording first.
Review in four passes.
Pass 1: Reconstruct the process
Was the decision framed clearly? Were credible alternatives considered? Were facts separated from assumptions? Did the confidence range match the actual uncertainty? Was a disconfirming signal specified?
Do this before discussing the result.
Pass 2: Describe the outcome
State what happened, including the time window and the quality of the evidence. “Revenue rose” is incomplete if pricing, seasonality, channel mix, and the target cohort changed at the same time.
Do not force a causal explanation from an observational sequence. The change happened, then the outcome happened. That may support a hypothesis, but it does not automatically establish why.
Pass 3: Identify luck and missing context
Ask what was outside your control, what you failed to record, and what you could not have known. Then ask the harder question: was the missing information realistically obtainable at the time, or does it only look obvious now?
If you want to test one reversible uncertainty instead of debating it indefinitely, use the more disciplined structure in How to Run an N-of-1 Experiment Without Fooling Yourself. The same caution applies at work: change fewer variables, decide the observation window in advance, and keep causal language modest.
Pass 4: Change one future rule
Finish with one operational update.
- “For changes that affect account permissions, include one permissions check before launch.”
- “When the downside is hard to reverse, run the smaller pilot first.”
- “Do not treat a handful of support conversations as prevalence data.”
Avoid grand lessons such as “trust your instincts” or “never move fast.” They compress one outcome into a universal rule. A useful review changes one repeatable part of the next process.
What not to put in a decision journal
Do not turn it into surveillance of colleagues, a private file of sensitive personal details, or evidence written to protect yourself in an internal dispute. Record the minimum context needed for your reasoning and follow your organization's rules for confidential, regulated, or personal data.
Do not log routine, reversible choices that cost less than the journal entry. A decision log earns its place when the cost of forgetting the original reasoning is meaningful.
Finally, do not use the card to pretend uncertainty has disappeared. Its job is to preserve uncertainty honestly enough that you can learn after the result.
Use the card on one live decision today
Choose a decision already on your calendar: a hire, a launch, a pricing test, a difficult delegation, or a change to your weekly operating rhythm. Write the six fields before the result arrives. Put the review date on the calendar, then leave the entry unchanged.
The value will not be a perfect prediction. It will be a clean comparison between what you knew, what you expected, what happened, and what deserves to change next.
Sources and further reading
If you want one place to preserve a decision beside the states, routines, and later reflections around it, explore DailyLens's contextual AI journal.
