Pick the Bet

A backlog feels responsible. It's a tidy list of good ideas, ranked-ish, always growing. It's also where decisions go to die.

The problem with a backlog is that it lets you avoid the only question that matters: if I could run exactly one experiment this week, which one would it be? A list of forty ideas never forces that answer. So teams pull whatever's on top, or whatever's easiest, or whatever the loudest person wants, and call it prioritization.

Real prioritization produces a ranking, not a list. A ranking has a clear number one and the discipline to act on it. One bet a week, chosen well and actually shipped, beats ten half-built ideas every time, because a shipped bet teaches you something and a backlog item teaches you nothing.

The best bet is not the biggest idea or the easiest task. It's the one with the most leverage: the most expected movement per unit of work. You can estimate it honestly with four inputs:

• Impact: if this works, how much does the target metric move?
• Confidence: how sure are you it'll work, given what you actually know?
• Reach: how many users flow through the thing you're changing?
• Effort: how much work to ship a test that can answer the question?

Expected value ≈ (Impact × Confidence × Reach) ÷ Effort

You don't need false precision. You need to force every candidate through the same lens so you're comparing them on one axis. The moment you do, the list stops being forty equally-plausible ideas and becomes a ranking with an obvious top.

Notice what this kills: the beautiful, high-effort, low-confidence redesign that everyone loves and no one can justify. And what it surfaces: the small, boring, high-reach change nobody was excited about, sitting quietly at the top.

If you can't estimate the lift, you can't rank the bet, and you're about to spend a week on a coin flip.

The estimate doesn't need to be right. It needs to exist, and it needs to be made of real numbers from Chapter I. Work it back from the leak:

• 3,000 new users a week reach the empty dashboard.
• 62% of them leave without activating.
• You believe surfacing the setup checklist recovers a third of those.
• That's ~620 users a week who now activate instead of bouncing.

Now you have something to rank, something to beat, and something to check against reality after you ship. A bet with a written-down expected lift is a bet you can be wrong about, which is exactly what makes it useful. A bet with no number is just a preference wearing a lab coat.

The softest input is confidence, and it's where most rankings go wrong, because "I'm confident" usually means "I like this idea."

Confidence should come from evidence, and evidence has a hierarchy:

• A prior test. You, a competitor, or a well-known case study tried something similar and it worked. Highest confidence.
• A strong analog. The pattern is proven elsewhere in a comparable context.
• Quantitative signal. Your own data points at this leak clearly and consistently.
• Qualitative signal. Users have literally told you this is a problem.
• A hunch. It feels right. Lowest confidence, and fine, as long as you label it honestly.

The trick isn't to only bet on high confidence. It's to know which one you're holding, so a seductive hunch doesn't get scored like a proven result. Write the evidence next to the bet. If the strongest thing you can write is "feels right," that's a signal, not a disqualification, but a discount.

Once you have a ranking, the discipline is to bet on the top of it and stop.

Running three experiments at once feels efficient. It isn't. Overlapping changes contaminate each other's reads: when the number moves you won't know which change moved it, and you'll have learned nothing from three weeks of work. Worse, splitting attention across three bets usually means none of them ships clean.

Sequence instead of parallelize. Ship the number-one bet, get a clean read, feed the result back into the ranking (that's Chapter IV), and let it re-sort. The bet that was second this week is often not second next week, because what you learned changed the odds. A ranking you act on one row at a time is worth more than a roadmap you admire all at once.

Before you commit the week, run a thirty-second pre-mortem: it's two weeks from now and this bet flopped. Why?

The answers come fast, and they're cheap here. Maybe the metric can't actually move that much. Maybe the leak is real but this change doesn't address its cause. Maybe you can't get a clean read in the time you have. Maybe the effort estimate was fantasy.

A pre-mortem is the last cheap moment to kill a bad bet. After this, the cost of being wrong is a week and a shipped change; right now it's one honest question. If the top bet survives it, commit fully. If it doesn't, drop to number two, the ranking already did the hard part.