A Winning Move Can Still Be a Bad Decision: Expected Value Versus Outcome Bias

A single victory doesn't prove you made the right move—sometimes, a winning result can come from a bad decision. The real test is expected value: looking at the probable outcomes before the result is known, not after. This matters in every strategic game, from poker to business negotiations, where judging yourself (or others) by the outcome alone can lead to costly mistakes.

Why Winning Isn't Proof of Good Play

We all want to judge decisions by their results. Did the move work? Did it win? But in games—and life—luck plays a role. Sometimes, a poor decision pays off just because things broke your way. That's where outcome bias creeps in: we judge the quality of a choice by how things turned out, not by how good the choice really was at the time.

Expected value (EV) is the tool for this. EV asks: "If I made this move many times, what would I expect to gain or lose on average?" It weighs the probabilities and payoffs, not the one outcome you happened to see.

Hypothetical Example: The Risky Capture in Chess

Imagine you're playing a tight chess match. You see an opportunity: you can take your opponent's pawn, but doing so opens your king to a possible attack. You quickly calculate that in 80% of cases, your opponent will find the right response and your position will deteriorate. In 20% of cases, your opponent might miss it, letting you keep the extra pawn and win.

The expected value calculation might look like this (using illustrative numbers):

• 80% chance: lose the game (value: -1)
• 20% chance: win the game (value: +1)

Expected value = (0.8 × -1) + (0.2 × 1) = -0.6

This move has negative expected value: on average, it loses points. But if you go for it and your opponent misses the best response, you win. The outcome is a win, but the decision was poor.

Why This Matters: The Real Cost of Learning the Wrong Lesson

If you judge moves only by whether they won or lost, you reinforce risky habits. In any repeated game—poker, negotiation, even investing—this leads to trouble. Short-term wins from bad decisions teach you to keep making them, until you eventually pay the price.

How to Spot Outcome Bias in Your Own Play

Can you trust your post-game analysis, or are you just rationalizing the outcome? Analytical players already log their thought processes and replay critical moves—so why do biases persist? The answer is that reviewing your own decisions with full knowledge of the results subtly rewires your memory of what you "knew" at the time. To guard against this, use blinded and probabilistic review techniques.

• Blinded Review: Before you check the outcome, export the game state (or hand, or turn) at each decision point into a separate file or record. Use a tool like SCID for chess, PokerTracker for poker hands, or even a simple spreadsheet for business scenarios. Label each position or scenario with context only—do not include results. Shuffle and review these as a batch, or trade with a partner for double-blind analysis. Only after annotating your reasoning and preferred action should you reveal what actually happened.

• Probabilistic Annotation: For each critical move, explicitly write down your estimated probability of success and your reasoning. For example, in poker: “I estimate villain folds to a river shove 60% of the time, so the EV of betting is X.” In a strategic business pitch: “There’s a 20% chance the client will overlook the risk, but if they discover it, the expected cost is Y.” Later, compare these probabilities to empirical frequencies from your database or public datasets—this is the only way to calibrate your intuition.

• Mistake to Avoid: Reviewing only when surprised by an outcome (big win or loss) creates a feedback loop where only outliers get analyzed. Instead, sample and review a fixed percentage of both ordinary and pivotal decisions, regardless of result. In practice, set up an automation: for example, PokerTracker’s hand filtering or a chess engine’s random sampling script.

Hypothetical Example: Annotated Poker Hand

You’re dealt AK offsuit in the cutoff. You face a 3-bet from the button. Before looking at the showdown or outcome, record: “Given BTN’s 3-bet frequency (15%), I put their range at TT+, AQ+. Estimate fold equity on a 4-bet is 40%. EV of shove vs. flat-call is +$14. I choose to 4-bet.” Archive this, review a week later, and compare your fold equity estimate to aggregate data from your database. This process surfaces recurring misjudgments and inoculates you against outcome bias.

These techniques require discipline, but they’re the only reliable way to spot and correct for outcome bias in your analysis.

How This Changes Your Next Move

Focus on making the decision that has the best expected value, not the one that simply worked last time. Review your choices, not just your results. Over time, this mindset leads to more consistent success, especially in environments with uncertainty and risk.

Questions readers ask

What if I can't calculate the exact expected value?

You don’t need a closed-form solution. Use a quick breakdown: list each possible outcome, assign a ballpark probability, and multiply by the payoff or loss. For instance, in poker, if you’re facing an all-in bet, estimate your win chance (say, 35%) and the pot odds. Use tools like Flopzilla or Equilab (for poker hands), or a spreadsheet for trading scenarios. If you’re unsure, set up a Monte Carlo simulation—Python’s `random` module suffices—to sample outcomes and rough in the EV. The key is to make your uncertainty explicit: is your input range wide? Note it. That’s far better than ignoring the calculation entirely.

How can I explain a "bad" outcome from a good decision to my team?

Bring specifics. After the fact, reconstruct the decision: “We were a 60% favorite given the information at hand; the loss was a 40% branch.” Share your estimation process. For trading: “Our position sizing was based on a 1.2 Sharpe over historic backtest, drawdown risk capped at 2%.” In games: “The move blocked their main threat, and 7 out of 10 times in our sims, it wins.” Show your pre-move notes or code if you have them. In post-mortems, focus on process metrics (e.g., ‘decision time,’ ‘input accuracy’) as much as results—most teams skip this and spiral into hindsight bias.

Is there ever a time when outcome bias is actually useful?

Almost never for repeated, skill-based domains. The one defensible case: when dealing with fat-tailed, catastrophic risks that can’t be backtested well (think: nuclear safety, portfolio blowup). There, outcome review is a failsafe against model blindness, but it only works if you’re explicit: label it as a “tail risk review,” not as a critique of day-to-day process. For everything else—especially where sample sizes are large—lean hard on expected value, not outcome, or you’ll anchor the team to luck instead of skill.