/ Library/ Not Enough Meaning/ Outcome Bias
Connect Bias № 112 · Last updated 6 June 2026

Outcome Bias.

"Good outcome, good decision — bad outcome, bad decision. Not always."

01Overview

Outcome bias evaluates decisions retroactively by whether they worked — not whether they were reasonable given what was known. A lucky gamble is praised; a sound bet that lost is condemned.

Design retrospectives lionise launches that succeeded for external reasons and punish teams who followed good process with bad luck. Outcome bias couples with hindsight — "we should have known" — to rewrite decision history and distort what the organisation learns.

02Detailed explanation

Outcome-weighted learning appears everywhere:

  • A/B winner declared smart even when test was underpowered and effect spurious.
  • Research-led redesign blamed for revenue dip caused by seasonality.
  • Dark pattern lift celebrated; ethical alternative killed for one losing week.
  • Designer promoted for viral feature whose success was algorithmic luck.

Moral luck adds ethical judgment to the same structure. Outcome bias is the neutral decision-quality version — equally corrosive to learning.

03Why it exists

Outcomes are salient and easy to score. Process quality is harder to audit.

Leaders need stories. "We made a good decision that failed" is an unsatisfying narrative.

The short version

Given only pre-ship information, was the decision defensible — win or lose?

04Effects on users

Users inherit products shaped by lucky bad practices — copied because they "worked once" — and lose features killed by unlucky good ones.

They also suffer when teams learn from outcome alone — doubling down on manipulative patterns with short-term lifts.

05Effects on designers & teams

Teams reward outcomes in rituals:

  • Metric-only retros. No decision log review.
  • Hero narratives. Individuals credited for variance.
  • Killing ethical options early. One bad week ends experiment.
  • Copying competitor outcomes. Without context of their process or luck.

06Practical takeaways

  • Log decisions at ship time. Hypothesis, evidence, risks known.
  • Judge process in retros. Separate luck from quality.
  • Extend ethical test windows. Don't kill on noisy early outcomes.
  • Teach stakeholders outcome bias. Before post-mortems blame design.
  • Document external shocks. Market, algorithm, outage — in narrative.
  • Promote learning, not just winning. Reward well-evidenced failures.

07Design examples

A/B testing

Lucky winner

Variant wins at p=0.04 with 500 users. Ships company-wide; effect vanishes. Team records "data-driven win" — outcome bias canonised noise.

Redesign

Blamed for seasonality

Checkout redesign launches before holiday slump. Revenue dips. Rollback ordered. Analytics later show category-wide dip — outcome bias punished good work.

Ethics

Dark pattern celebrated

Manipulative urgency copy lifts conversion one week. Ethical variant killed. Long-term trust damage unmeasured — outcome bias picked short window.

Research

Ignored when lucky

Team skips research; launch succeeds on PR bump. Research team budget cut. Failure to learn that skip was bad process with good outcome.

08Ethical risks

Celebrating outcome without process rewards manipulation and luck — users pay long-term costs teams do not score.

Punishing ethical decisions with bad luck incentivises harmful shortcuts that occasionally win.

Self-test: Which bad process got praised because the metric moved — and which good process was killed because it didn't?

10Suggested reading

Browse recommended reading →