Post-Decision Reviews: Process Over Outcome

By Better Wise

You have framed the decision, compared options, attacked your plan with a pre-mortem, and used AI to widen the option space rather than to decide. Now the decision is made and the outcome is arriving. This lesson is about the last step that most people skip: closing the loop honestly. Getting good at reviews is what turns a single decision into compounding judgment.

By the end of this lesson you will be able to:

• Separate decision quality from outcome quality using a simple 2x2.
• Explain why "resulting" corrupts your learning.
• Run a review that probes the process, not the story.
• Extract exactly one process change and resist rewriting history.
• Time-box the review so it stays cheap and repeatable.

Two Axes, Four Stories

The core idea fits on one diagram. A decision is good or bad by the quality of the process you ran with the information you had. An outcome is good or bad by what happened. These are independent, which gives four cases:

The trap is the top-right and bottom-left cells. A lucky win teaches you nothing and often teaches you the wrong thing. A well-reasoned loss makes you abandon a sound process.

flowchart TD
    D["🎲 Decision made"] --> Q{"Was the process sound<br/>given what was knowable?"}
    Q -->|Yes| G1{"Outcome?"}
    Q -->|No| G2{"Outcome?"}
    G1 -->|Good| R1["✅ Earned win<br/>Repeat the process"]
    G1 -->|Bad| R2["🎲 Bad luck<br/>Keep process, note variance"]
    G2 -->|Good| R3["⚠️ Lucky win<br/>Dangerous: do not learn from it"]
    G2 -->|Bad| R4["🔧 Deserved loss<br/>Change one thing"]

Annie Duke calls the error of judging a decision by its result resulting. The fix is not to ignore outcomes, it is to judge them last and separately.

Important: A review is not a verdict on you. It is a diagnostic on a process. If the review feels like a trial, you will start writing the minutes to protect yourself, and the reviews become worthless.

Separating Skill From Luck

Before you judge anything, ask: how much of this outcome was within the decision's control? A sales call, a hiring bet, a product launch, and a vendor choice all mix skill and luck in different proportions.

Three questions that pull the two apart:

1. What did we know at the time? Reconstruct the information set, not your current knowledge. If the fact that sank the project was genuinely unavailable in the brief, that is variance, not error.
2. Was the reasoning valid given that information? You can have a sound chain of reasoning that leads to a bad result.
3. How repeatable is this situation? In a one-off decision, luck dominates and you should be gentle with yourself. In a repeated decision (weekly hiring, routine pricing), a bad run is a real signal, because the noise averages out.

That third question matters more than most people think. A single coin flip tells you nothing about the coin. Twenty flips tell you a lot. Reviews on repeated decisions should be run on batches, not one event at a time.

Note: Reversibility changes the review's weight. A cheap, reversible decision that went badly deserves a five-minute note. An irreversible decision deserves a scheduled, written review even if it went well.

Exercise 1: Sort your own outcomes

Take three decisions from the past year: one that went well, one that went badly, one that went surprisingly well. For each, write one line naming which cell of the 2x2 it belongs in, and one line on what you actually learned from it at the time.

Guidance

Most learners find at least one "lucky win" they had been treating as proof of skill, usually in the surprising-well column. If you cannot reconstruct what you knew at the time, that is itself a finding: you were not keeping a record, so every review will be a story you tell yourself afterward. The remedy is the decision brief you will build in the next lesson.

The Review Agenda: Six Questions

Run reviews against a fixed agenda. Fixed questions are what stop the session from drifting into self-justification. Thirty minutes is enough.

1. Restate the decision: what was chosen, when, by whom, and what the alternatives were.
2. Rebuild the information set: what did we know then, and what would we have needed to know?
3. Test the reasoning: where were the assumptions, and which ones failed?
4. Name the luck: what happened that was outside the decision's control?
5. Score the process separately from the outcome, with one sentence of justification each.
6. Choose exactly one process change for next time.

Question 6 is the discipline. One change, written down, with a trigger ("next time a vendor switch comes up, I will ask for the exit cost before the price"). A review that produces seven improvements produces none, because none get implemented.

Tip: Invite one person who does not share your conclusion. A reviewer who agrees with you will confirm the story. A reviewer who disagrees forces you to say the reasoning out loud, which is where the gaps show.

Exercise 2: A 30-minute review of the same decision

Pick the bad-outcome decision from Exercise 1 and run the six questions. Timebox it. Then answer two questions in writing: what was the process error, if any, and what is the single change?

Guidance

If your answer to "what was the process error" is a character judgment ("I was too optimistic"), push one level down to a checkable behavior: "I did not list the top three things that had to be true." If your answer is "there was no error, it was bad luck," that is a legitimate result, provided you can point to the specific unavailable information. And note: nobody is allowed to answer "I should have known" without naming what the record shows you could have known.

Do Not Rewrite History

The most common failure in a review is hindsight editing: the outcome makes the past feel predictable, and you rewrite your own reasoning to match. The sunk certainty feels like insight but is a story.

Two defenses:

• Write the decision down before the outcome. A one-paragraph brief with the reasoning, the confidence level, and the top risks. You cannot revise a document you sealed. This is what the project in lesson 3.3 formalizes.
• Score confidence in advance. If you said 70% likely, then in ten similar decisions you should be wrong about three times. Reviews are how you find out whether your 70% means anything.

Then the review's job is to compare what you wrote with what happened, not to compose a better explanation now.

Warning: Beware the reverse error too: using "it was bad luck" as a blanket defense. Bad luck is a claim about information you could not have had. If the information was in the brief and you ignored it, that is a process error wearing a disguise.

Reviewing Well: Rules of Thumb

• Judge the process first, the outcome second. Never let a good result end the conversation early.
• One change per review. Write it with a trigger and a date, or it did not happen.
• Separate the two scores out loud. "Process: sound. Outcome: bad. Classification: variance."
• Pull luck apart before blame. Rebuild the information set at the time, not now.
• Batch repeated decisions. Ten hiring cycles get one review, not ten.
• Invite a dissenter. Agreement confirms; disagreement diagnoses.
• Timebox to 30 minutes. Long reviews drift into storytelling.

Common mistakes: treating a lucky win as validation, abandoning a good process after one bad result, writing a review that is really a defense, and producing a list of improvements nobody owns.

Quick check

Fill in the blanks, then cover the answers and try again tomorrow.

The error of judging a decision by its result is called _____.

A good process with a bad outcome is best classified as _____ (variance).

A bad process with a good outcome is the most dangerous cell because it _____.

A disciplined review ends with exactly _____ process change.

To defend against hindsight editing, _____.

The Loop Closes Here

Reviews are where judgment compounds. The four-cell view lets you keep a good process through a bad result, and distrust a bad process even when it worked. Separating skill from luck starts with rebuilding what you knew, and ends with one owned change rather than a list. Record the decision before you know how it turns out, then compare notes with your past self instead of narrating over them.

Next, you will put all of it on paper: the project builds a decision brief with a pre-mortem and a scheduled review plan, so the review you just learned to run is set up before the outcome arrives.

Front: What does 'resulting' mean? Back: Judging the quality of a decision by its outcome instead of by the process that produced it.

Front: In the decision/outcome 2x2, what is a good process with a bad outcome called? Back: Bad luck, or variance: keep the process and check whether the situation repeats.

Front: Which cell of the 2x2 is most dangerous for learning? Back: Bad process with a good outcome, because a lucky win reinforces a process that will eventually fail.

Front: Why should an irreversible decision get a scheduled written review? Back: Its cost of error is high and the lesson cannot be recovered cheaply later.

Front: First question when separating skill from luck? Back: What did we actually know at the time, reconstructed from the record rather than from current knowledge?

Front: Why review repeated decisions in batches? Back: Noise averages out, so a pattern across many events is signal rather than a single coin flip.

Front: How many process changes should a review produce? Back: Exactly one, written down with a trigger for when it applies.

Front: What is hindsight editing in a review? Back: Rewriting your past reasoning to match the known outcome, so the past feels predictable.

Front: Best defense against hindsight editing? Back: Write the decision brief with reasoning, confidence, and top risks before the outcome is known.

Front: How does pre-scored confidence help a review? Back: It lets you check calibration: a stated 70% should be wrong roughly three times in ten.

Front: Why invite a dissenting reviewer? Back: Agreement confirms your story; disagreement forces the reasoning out and exposes gaps.

Front: What turns 'bad luck' into a process error? Back: The information was available in the brief and you ignored or underweighted it.

Front: Time budget for a decision review? Back: About 30 minutes against a fixed agenda, to keep it cheap and prevent storytelling.

Front: How should a review treat the person who made the decision? Back: As a process to diagnose, not a person to convict; fear of judgment corrupts the review.