A decision is a bet

Overview

Lesson 2 gave you the tool to separate facts from assumptions. This lesson gives structure to what you found: a product bet has a thesis —the central claim the team believes is going to happen if it builds the bet ("showing personalized recommendations is going to raise GMV per buyer")— and that thesis rests on a stack of assumptions (the assumption stack), each of which could be wrong. The more untested assumptions holding up the thesis, the bigger the leap of faith the team is taking by building it.

This isn't a vocabulary technicality: it changes how you judge whether a decision was good. Poker player and author Annie Duke coined a term for the most common mistake when evaluating decisions under uncertainty: "resulting" — judging a decision's quality by its result's quality, instead of by the quality of the reasoning that supported it at the moment it was made. A well-thought-out bet can fail due to bad luck; a poorly-thought-out bet can turn out well by coincidence. Confusing the two —as you're about to see in today's example— makes teams learn the wrong lesson from their own results.

How this connects to the module. Lesson 2 taught you to separate fact from assumption; this lesson organizes those assumptions around the thesis they support, and gives you the criterion for judging whether a bet was well made —without waiting to know whether it turned out well—. Lessons 4 and 5 take exactly this same assumption stack and find which one, of all of them, weighs the most.

An analogy: the poker hand that doesn't depend on winning

Annie Duke played professional poker before writing about decisions. In poker, every bet is made without seeing the opponent's cards: you bet with the best possible read on the situation —your cards, the ones already shown, how the opponent has played so far—, and even with the best possible read, you can lose the hand. The opponent might have, against all odds, exactly the card they needed. That doesn't make your decision to bet a bad one — your decision was correct given what you knew at that moment; the result, this time, just didn't line up with the probability.

And the reverse happens all the time too: someone bets big with a weak hand, with no solid reason, and wins anyway because the card they needed came up by pure luck. They won the hand. They didn't make a good decision — they made a bad decision that had a good result. If that player learns from that hand "betting big with weak hands works", they're going to lose a lot more money over the next hundred hands than they won on that one.

Building a product bet works exactly the same way: you bet with the best possible read —your facts, your assumptions, your evidence—, without seeing "the opponent's cards" (what the market is actually going to do). If recommendations raises GMV, that doesn't automatically prove the bet was well thought out — it could have gone up because of a high season that coincided by chance. If recommendations doesn't move GMV, that doesn't prove the bet was poorly thought out either — the thesis could have been reasonable and failed due to a factor nobody could have foreseen. The only thing you can evaluate, before knowing the result, is whether you identified your thesis clearly and whether you tested the assumption most likely to sink it.

Worked example: two bets, two sizes of leap of faith

Not every bet in Mercado's backlog is equally uncertain. Compare fasterCheckout with recommendations: both are bets —neither is an absolute certainty—, but the size of what they're assuming is very different.

// describeBet(bet): counts how many assumptions support a bet's thesis, and
// how many of those remain untested. It doesn't weigh anything yet (that's
// lesson 5); it only makes the SIZE of the leap of faith behind each bet visible.
function describeBet(bet) {
  const untested = bet.assumptions.filter((a) => !a.tested).length;
  return {
    thesis: bet.thesis,
    totalAssumptions: bet.assumptions.length,
    untestedAssumptions: untested,
  };
}

const fasterCheckoutBet = {
  thesis: 'Reducing checkout from 3 steps to 1 is going to raise conversion',
  assumptions: [
    { text: 'Users abandon mainly due to friction, not price', tested: true },
    { text: 'A 1-step checkout does not increase payment errors', tested: false },
  ],
};

const recommendationsBet = {
  thesis: 'Showing personalized recommendations is going to raise GMV per buyer',
  assumptions: [
    { text: 'Users are going to buy more if they see personalized recommendations', tested: false },
    { text: 'The team can build a basic engine in 3 person-months', tested: false },
    { text: 'Sellers are not going to complain about less visible products', tested: false },
    { text: 'Showing recommendations does not slow down load speed', tested: false },
  ],
};

console.log('=== Two Mercado backlog bets, seen as bets ===\n');
[fasterCheckoutBet, recommendationsBet].forEach((bet) => {
  const d = describeBet(bet);
  console.log('  "' + d.thesis + '"');
  console.log('  assumptions: ' + d.totalAssumptions + '  |  untested: ' + d.untestedAssumptions + '\n');
});

console.log('fasterCheckout rests on 2 assumptions, 1 already tested: a small leap of faith.');
console.log('recommendations rests on 4 assumptions, all 4 untested: a big leap of faith.');
console.log('Both are bets -- neither is a certainty -- but not the same size.');

What to expect. When you run the file with Node, the output is exactly this:

=== Two Mercado backlog bets, seen as bets ===

  "Reducing checkout from 3 steps to 1 is going to raise conversion"
  assumptions: 2  |  untested: 1

  "Showing personalized recommendations is going to raise GMV per buyer"
  assumptions: 4  |  untested: 4

fasterCheckout rests on 2 assumptions, 1 already tested: a small leap of faith.
recommendations rests on 4 assumptions, all 4 untested: a big leap of faith.
Both are bets -- neither is a certainty -- but not the same size.

Notice something describeBet() does not do yet: it doesn't say which of recommendations's assumptions matters more than the other three — it only counts how many there are and how many are untested. That's intentional: before asking "which one weighs more?" (lessons 4 and 5), you need to see the full size of the leap of faith. fasterCheckout has one untested assumption ("a 1-step checkout doesn't increase payment errors"); if that assumption were false, it would be a real problem, but a bounded one — the team already has solid evidence about the main cause of abandonment (tested: true). recommendations has four untested assumptions at once: the leap of faith isn't just bigger, it's structurally different — nothing supporting the thesis has a verified base yet.

The "resulting" mistake applied to a product bet

Imagine two scenarios, both possible for recommendations.

Scenario A. The team builds the full engine without testing any assumption first, launches it, and GMV goes up 8% that month — but it turns out that month coincided with a discount campaign the marketing team launched in parallel, uncoordinated. GMV went up because of the campaign, not the recommendations (nobody can know for sure, because the effect was never isolated). The team concludes: "building without validating worked, let's do it that way again next time." That conclusion is "resulting" in its purest form: the result was good, but the decision process —betting everything without testing the risky assumption— was the same bad process, disguised by an external coincidence.

Scenario B. The team tests first, cheaply, whether personalization changes purchase behavior (something you'll see how to do in lesson 6), gets a clear positive signal, builds the MVP informed by that signal, and GMV still doesn't move — because, without anyone knowing, a competitor launched an aggressive promotion that same month that absorbed demand. The team concludes: "we tested, we had real evidence, and it still failed — the decision was well made, the result was taken by an external factor we couldn't control or foresee." That's the correct reading: the process was good, even though the result wasn't.

The difference between the two scenarios isn't in the final GMV — it's in whether the team identified its thesis, named its assumptions, and tested the riskiest one before committing resources. That's the only thing you can control when making the decision; the result, you can't.

Common mistakes

Falling into "resulting": judging the decision by the result. What happens: as in the example's Scenario A, a bet built without validating anything turns out well for an unrelated reason, and the team learns "no need to validate" — or the reverse, a well-thought-out bet fails due to an external factor, and the team learns "this doesn't work, let's not try it again." Why it happens: the result is the only thing visible and measurable after the fact; the decision process that preceded it is invisible if nobody documented it. How to spot it: a bet's retrospective focuses entirely on "did the metric go up or not?" and never on "did we correctly identify the thesis and test the right assumption before building?". How to fix it: evaluate the decision process separately from the result — document, before knowing the result, what the thesis was and which was the riskiest assumption tested (or not), and use that, not just the final number, to decide whether to repeat the process next time.

Falling in love with the bet and not wanting to look for the assumption that kills it. What happens: whoever defended recommendations at the planning meeting resists, without realizing it, naming their own idea's most fragile assumption — they explore it less, question it less, and instead focus on the assumptions most comfortable to defend. Why it happens: questioning your own idea feels like sabotaging it; it's more pleasant to talk about why "it's going to work" than about why "it might not." How to spot it: whoever is most excited about a bet is, almost always, the one who asks the fewest questions about their own assumptions — while asking hard questions about everyone else's bets. How to fix it: separate the role of "whoever defends the bet" from the role of "whoever looks for its riskiest assumption" — or, if it's the same person, explicitly demand they do lessons 4 and 5's exercise on their own idea before defending it at the meeting. Finding the crack in your own bet before reality finds it is cheaper.

Treating every bet as equally uncertain. What happens: the team applies the same level of scrutiny and caution to fasterCheckout (1 untested assumption, on a solid base) as to recommendations (4 untested assumptions, on a new thesis), as if "everything is a bet" meant they all weigh the same. Why it happens: "a bet is a bet" is a simple sentence that invites treating them uniformly, even though the real size of the leap of faith is very different. How to spot it: at the planning meeting, fasterCheckout and recommendations receive the same amount of questions and the same level of prior validation, despite having assumption stacks of completely different sizes. How to fix it: use describeBet() —or simply count the untested assumptions— to calibrate how much scrutiny each bet needs before committing significant resources. A bet with a big leap of faith needs more validation before building than one with a small leap of faith, even though both are, technically, "bets."

Exercises

Exercise 1 — Name the thesis. For Mercado's backlog improvedSearch bet, write in a single sentence what you think its thesis would be —the central claim the team is betting is true—.

See solution

A reasonable thesis: "Improving search result relevance is going to reduce session abandonment without a purchase and raise conversion." Notice the sentence's shape: it names an action (improve search) and an expected result (less abandonment, more conversion) — exactly the same structure as fasterCheckout ("reducing checkout... is going to raise conversion") and recommendations ("showing recommendations... is going to raise GMV"). Every thesis in this module follows that pattern: "if we do X, we expect Y."

Exercise 2 — Identify the "resulting". A coworker says: "We launched sellerTools last quarter without validating anything first, and GMV went up — so for next quarter we don't need to spend time testing assumptions, let's go straight to building." Which of this lesson's mistakes are they making, and what question would you ask before accepting their conclusion?

See solution

They're committing "resulting": they're judging that the decision process ("build without validating") was good just because the result (GMV went up) was good, without having verified whether the result was really due to sellerTools or to something else. The right question before accepting the conclusion: "how do we know GMV went up because of sellerTools and not because of something else that happened that same quarter —a high season, a marketing campaign, a competitor's price change—?". If there's no way to isolate the effect, the conclusion "we don't need to validate" isn't backed by the result — it's exactly the same mistake as Scenario A in the worked example.

Exercise 3 — Compare two leaps of faith. Without running Node, for these two hypothetical bets, say which has the bigger leap of faith and why, using describeBet()'s same logic:

• Bet X: 3 assumptions, all already tested (tested: true).
• Bet Y: 2 assumptions, none tested (tested: false).

See solution

Bet Y has the bigger leap of faith, even though it has fewer total assumptions. describeBet() doesn't measure the leap of faith's size by the total number of assumptions, but by how many are untested — Bet X has 3 assumptions but 0 untested (untestedAssumptions: 0), while Bet Y has 2 assumptions and both untested (untestedAssumptions: 2). This exercise anticipates something important: a bet with many named and already validated assumptions can, in practice, be safer than a bet with fewer assumptions but completely untested. Naming the assumptions is the first step; testing them is what actually reduces the leap of faith.

Summary and next step

In this lesson you learned to see a product bet with the same structure Annie Duke teaches you to see a poker hand: a thesis —what you believe is going to happen— supported by an assumption stack —the beliefs that have to be true for the thesis to hold—. And you learned the most dangerous mistake when evaluating those bets after the fact: "resulting", judging a decision's quality by its result's quality, when the result can depend on factors that were never under your control. With describeBet() you compared the size of the leap of faith between two real Mercado backlog bets — fasterCheckout, with a mostly tested foundation, and recommendations, with four open assumptions at once.

Before moving on you should be able to: name any backlog bet's thesis in one sentence; explain "resulting" with your own example; and tell apart the size of a bet's leap of faith by counting its untested assumptions.

Lesson 4 goes into recommendations's assumption stack and answers the question describeBet() still doesn't answer: of the four untested assumptions, which one, if false, sinks the entire thesis?

Resources

• Annie Duke, Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts — annieduke.com/annie-duke-thinking-in-bets. The source of this lesson's central vocabulary: treating decisions as bets, and the danger of judging them by their result. In English.
• Nautilus, "The Resulting Fallacy Is Ruining Your Decisions" — nautil.us/the-resulting-fallacy-is-ruining-your-decisions-236901. An article focused specifically on "resulting", with examples outside poker that help you see the pattern in other contexts. In English.
• Marty Cagan / SVPG, Silicon Valley Product Group blog — svpg.com/articles — on why the best product teams treat every bet as a hypothesis to test, not a certainty to defend. In English.