Find each bet's riskiest assumption

Description

You already know how much GMV each of the five bets sizes (lesson 4). But that number —$185,625/month for recommendations, for example— only holds if the bet works the way the team expects. Behind every bet there are several assumptions, not just one, and they don't all carry the same weight: some, if they turn out false, barely scratch the result; others, if false, sink the whole bet. This lesson applies rankAssumptions —module 6's model— to each of the quarter's five bets, to name, with an explicit criterion rather than the first assumption someone comes up with in the meeting, which one is that central assumption in each case.

Connection to the module. This is Layer 4 of the seven. rankAssumptions sorts a list of candidate assumptions by riskScore (risk × impact) and leaves you with the riskiest one on top — exactly the model you built in module 6. What this lesson adds is applying it across all five bets together, each with two candidate assumptions, not just one obvious one — because, as you're going to see, the riskiest assumption isn't always the one that looks riskiest at first glance. This winning assumption is also the direct input for lesson 6: the MVP you're going to design there exists, specifically, to test the assumption you identify here, not any other.

An analogy: inspecting the site before deciding what to shore up

Go back to the module presentation's construction schedule. Before deciding what to reinforce first, a structural engineer doesn't check the part of the building that "looks" most fragile to the naked eye —she checks which part, if it fails, brings the rest down with it. Sometimes that part is obvious (a visibly cracked column); sometimes it isn't (a buried, invisible pipe section that, if it fails, floods the whole building's foundation). The job isn't to list everything that could go wrong —that's an infinite list—, it's to find, among several reasonable candidates, the one that actually decides whether the building holds up or not.

Worked example: rankAssumptions over the quarter's five bets

For each bet, the team wrote two candidate assumptions —not just one—, each with its risk (how likely it is to be false, from 0 to 1) and its impact (how bad it would be for the bet if it turns out false, from 0 to 1):

// L05: we identify each bet's riskiest assumption with rankAssumptions (module 6).
function rankAssumptions(assumptions) {
  return assumptions
    .map((a) => ({ ...a, riskScore: Math.round(a.risk * a.impact * 100) / 100 }))
    .sort((a, b) => b.riskScore - a.riskScore);
}

const assumptionsByBet = {
  fasterCheckout: [
    { text: 'cutting from 5 to 3 steps removes real friction that causes abandonment, not just cosmetic steps', risk: 0.6, impact: 0.9 },
    { text: 'mobile buyers abandon because of the number of steps, not distrust in the payment method', risk: 0.4, impact: 0.6 },
  ],
  recommendations: [
    { text: 'showing complementary products in the cart makes more buyers add a second product before paying', risk: 0.5, impact: 0.9 },
    { text: 'buyers trust an automatic recommendation as much as their own search', risk: 0.3, impact: 0.5 },
  ],
  sellerTools: [
    { text: 'if sellers see which products are turning over slowly or running out of stock, they adjust price or stock in time, and that reduces lost sales', risk: 0.65, impact: 0.8 },
    { text: 'a weekly email report is visible enough for the seller to act, without needing a real-time alert', risk: 0.4, impact: 0.5 },
  ],
  reviews: [
    { text: 'seeing a visible rating on the product page increases the odds that a buyer completes the purchase', risk: 0.55, impact: 0.85 },
    { text: 'buyers trust the number of reviews (volume) more than the average star rating', risk: 0.3, impact: 0.4 },
  ],
  improvedSearch: [
    { text: 'correcting spelling errors and synonyms makes buyers find what they were looking for and reach the cart', risk: 0.5, impact: 0.75 },
    { text: 'most search abandonment happens because of typos or synonyms, not because of missing relevant inventory in the catalog', risk: 0.55, impact: 0.8 },
  ],
};

console.log('=== The riskiest assumption for each bet ===\n');
const riskiestByBet = {};
for (const [feature, list] of Object.entries(assumptionsByBet)) {
  const ranked = rankAssumptions(list);
  riskiestByBet[feature] = ranked[0];
  console.log(feature + ':');
  ranked.forEach((a, i) => console.log('  ' + (i === 0 ? '-> ' : '   ') + 'riskScore=' + a.riskScore + '  ' + a.text));
  console.log();
}

What to expect. Running the file with Node, the output is exactly this:

=== The riskiest assumption for each bet ===

fasterCheckout:
  -> riskScore=0.54  cutting from 5 to 3 steps removes real friction that causes abandonment, not just cosmetic steps
     riskScore=0.24  mobile buyers abandon because of the number of steps, not distrust in the payment method

recommendations:
  -> riskScore=0.45  showing complementary products in the cart makes more buyers add a second product before paying
     riskScore=0.15  buyers trust an automatic recommendation as much as their own search

sellerTools:
  -> riskScore=0.52  if sellers see which products are turning over slowly or running out of stock, they adjust price or stock in time, and that reduces lost sales
     riskScore=0.2  a weekly email report is visible enough for the seller to act, without needing a real-time alert

reviews:
  -> riskScore=0.47  seeing a visible rating on the product page increases the odds that a buyer completes the purchase
     riskScore=0.12  buyers trust the number of reviews (volume) more than the average star rating

improvedSearch:
  -> riskScore=0.44  most search abandonment happens because of typos or synonyms, not because of missing relevant inventory in the catalog
     riskScore=0.38  correcting spelling errors and synonyms makes buyers find what they were looking for and reach the cart

Four of the five bets behave as you'd expect: the "central" assumption, the one describing the bet's main mechanism, wins by a wide margin over the secondary one. But look carefully at improvedSearch, because it's the case worth pausing on: the assumption that wins isn't "correcting spelling errors and synonyms makes buyers find what they were looking for" —the one that sounds, at first glance, like the bet's central assumption. The one that wins is a more uncomfortable and more fundamental one: "most search abandonment happens because of typos or synonyms, not because of missing relevant inventory in the catalog."

Notice the difference between the two. The first asks whether the solution works: if you fix the typos, do people find what they were looking for? The second asks something earlier and more dangerous: is the problem you're solving even the real problem? If most of Mercado's search abandonment happens because the catalog simply doesn't have what people are searching for —not because they misspelled the word—, then improvedSearch can work technically to perfection (typos get corrected, synonyms get recognized) and still barely move conversion at all, because it was solving a secondary problem while the real one —catalog coverage— stayed untouched. That kind of assumption —about whether you correctly diagnosed the problem, not about whether your technical solution works— is, often, the riskiest of all, and it's also the one most easily overlooked, because it doesn't feel like part of the "engineering work" — it feels like something "everyone already knows."

Why the riskiest assumption isn't always the most obvious one

This pattern —the winning assumption being about diagnosing the problem, not about the solution— is more common than it seems, and it's worth naming precisely: there are two layers of assumption behind any bet. The first is "does my solution work?" (does the recommendation engine show relevant products? does the spelling correction detect typos well?). The second, almost always less visible, is "am I solving the right problem?" (is search abandonment really mostly about typos, or about missing inventory?). An engineering team, by training, tends to spend all its energy verifying the first —because it's the one you can test with a unit test, a demo, an algorithm precision metric— and takes the second for granted, without ever having put it to the test. rankAssumptions, with risk and impact estimated honestly for both layers, is what forces you to compare the two in the same table, instead of assuming by default that the technical layer is the one that matters.

Common mistakes

Writing only the "obvious" assumption and not looking for a second candidate. What happens: when applying rankAssumptions, someone writes a single assumption per bet —the first one they thought of— and declares it "the risky one" with nothing to compare it against. Why it happens: thinking up a second candidate assumption, different and also plausible, takes extra effort that feels unnecessary when the first one "already sounds right." How to spot it: if your list of assumptions per bet has a single element, you're not using rankAssumptions as a ranker —you're using your first hunch without checking it against any alternative. How to fix it: as you saw with improvedSearch, the second candidate sometimes wins. The exercise of writing at least two per bet —one about the solution, one about the problem diagnosis— is what makes the model worth anything.

Calibrating risk and impact so the assumption "already believed" to be the risky one wins. What happens: someone, already convinced beforehand of which is the central assumption, adjusts the risk and impact numbers until the ranking confirms what they already thought, instead of estimating them honestly first. Why it happens: it's the same temptation to manipulate a score you already saw with RICE in module 3, now applied to risk and impact. How to spot it: if you change a assumption's numbers after seeing that the ranking didn't come out as expected, and you don't have a new reason (evidence, not convenience) for the change. How to fix it: estimate each assumption's risk and impact before calculating the ranking, and only revise them if new, real information shows up — the same legitimate sensitivity discipline you saw in module 3's project.

Treating the winning assumption as the only one that matters, and discarding the second one. What happens: once the riskiest assumption is identified, the team completely forgets the second candidate, even though it also had a considerable riskScore (for example, 0.38 in improvedSearch, not far from the 0.44 that won). Why it happens: rankAssumptions produces a clear winner, and it's easy to read that as "the rest don't matter." How to spot it: if the MVP you design in the next lesson only tests the winning assumption and leaves no trace of evidence about the second, even when including it would be cheap. How to fix it: the winning assumption decides what to test first, not what to ignore entirely — when the cost of capturing evidence about the second one is nearly zero (as often happens with a well-designed MVP), it's worth designing it so it also yields signal about it.

Exercises

Exercise 1 — Calculate a third candidate's riskScore. For fasterCheckout, the team proposes a third candidate assumption: "the 3-step checkout doesn't introduce any new bug that causes abandonment for a different reason (a technical error, not a design one)," with risk: 0.3, impact: 0.9. Calculate its riskScore and say whether it would displace the current winning assumption (riskScore: 0.54).

See solution

riskScore = round(0.3 × 0.9 × 100) / 100 = round(27) / 100 = 0.27. It doesn't displace the current winner (0.54) — in fact, it lands above the original second candidate (0.24) but below the first. This makes sense: even though a technical bug would be serious if it happened (impact: 0.9, high), it's much less likely (risk: 0.3) than the design mechanism being wrong —bugs get caught with QA and monitoring before scaling to all traffic, while "does the 3-step design actually reduce friction?" is a question no automated test answers. rankAssumptions rewards the combination of both factors, not just severity.

Exercise 2 — Design the two candidates for a sixth bet. The team adds, late, a sixth bet to the backlog: "add cryptocurrency payment." Propose two candidate assumptions —one about whether the technical solution works, another about whether the problem it solves is real for Mercado's buyers— with their estimated risk and impact, and say which one you'd expect to win.

See solution

A reasonable proposal: (a) "integrating with a crypto payment gateway processes payments as reliably as the current checkout" (risk: 0.3, it's a technical integration well known in the market, moderate risk; impact: 0.6, a payments bug is serious but can be mitigated with monitoring) → riskScore: 0.18. (b) "there's a significant share of Mercado's buyers who today don't buy, or buy less, specifically because they can't pay with cryptocurrency" (risk: 0.7, high probability that this is false or exaggerated — there's no prior signal of this demand in the backlog; impact: 0.95, if it's false, the whole bet loses its reason to exist) → riskScore: 0.665. The second wins, and by a wide margin: it's the same pattern you saw with improvedSearch — the question of whether the problem is real almost always outweighs the question of whether the technical solution works, especially in a new bet with no prior signal of demand.

Exercise 3 — Explain why improvedSearch is the interesting case. In 3-4 sentences, explain to a teammate who only read the improvedSearch bet's title why, according to the model, its riskiest assumption isn't about whether the spelling correction works well.

See solution

A possible answer: "It feels natural to think improvedSearch's risk is whether the spelling-correction-and-synonyms algorithm works well technically. But the model, with risk and impact estimated honestly, says something else: the riskiest assumption is whether Mercado's search abandonment really comes, mostly, from typos or synonyms —and not from the catalog simply not having the product people are searching for. If that assumption is false, we could build the best spelling correction in the world and conversion would barely move, because we were solving the wrong problem. That's why lesson 6's MVP shouldn't just test whether the algorithm works —it should, above all, measure how much of that failed search is actually explained by typos, before investing in the full solution."

Summary and next step

In this lesson you identified, for each of the quarter's five bets, its riskiest assumption —the one that, if false, sinks the bet— using rankAssumptions over two candidates per bet. Four of the five confirmed the initial intuition; one, improvedSearch, revealed something more uncomfortable: its biggest risk isn't whether the technical solution works, but whether the problem it attacks is even the real problem behind search abandonment.

With each bet's riskiest assumption now named, lesson 6 designs, for each one, the cheapest experiment that puts it to the test —the MVP, with compareApproaches from module 5— before committing the quarter to building any of the five in full.

Resources

• Rob Fitzpatrick, The Mom Test — momtestbook.com. On why assumptions about the problem (not the solution) are the ones most often validated poorly, with questions that bias the answer toward what you already want to hear.
• Teresa Torres, Continuous Discovery Habits — producttalk.org/continuous-discovery-habits-book. The opportunity-and-assumption map, to practice this same separation (problem vs. solution) with your own backlog.
• Marty Cagan (Silicon Valley Product Group), "Risks" — svpg.com/articles. On the four types of risk in a product bet (value, usability, viability, feasibility), a broader framework that complements this lesson's risk × impact.