Bets
This is where direction-setting happens. The diagnosis told you where the leverage is; this page is how you turn that into a ranked set of bets: proposing them, shaping them, filtering the weak ones out, and budgeting finite capacity across the ones that survive. Get this step right and the plan writes itself. Get it wrong and no amount of execution saves the half.
Everything here rests on one frame: every item on the roadmap is a bet, not a promise. A promise is something you deliver no matter what you learn. A bet is something you’ll revise, shrink, or kill the moment the evidence says so. Framing the roadmap as bets is simply honest about the fact that, at planning time, nothing has been validated yet.
What a bet is: a metric goal + a narrative#
A bet has exactly two parts, and neither is optional:
- A metric goal: the number you’re trying to move, and the direction. “Cut cart-to-purchase drop-off from 55% to 35%.” It gives the work a success condition before anyone knows the solution, and it must trace to one of the north-star inputs.
- A narrative: the belief about why that will move it. “Because shoppers abandon when asked to re-type an address they’ve already entered.” The narrative doesn’t have to be right (Discover exists to stress-test it) but it has to be a falsifiable belief, not a solution in disguise.
The metric without the narrative is a target with no theory of how to hit it. The narrative without the metric is an opinion you can never prove wrong. Together they’re the bet; and, framed as an outcome a single person owns, they’re also the goal the team commits to. Same object, two names: a bet before you commit, a goal once you do.
From bet to owned goal#
Once a bet is committed it becomes a goal, and a goal carries three non-negotiables the bet framing alone doesn’t force:
- It’s an outcome, not an output. “Ship the new checkout” is an output: you can finish it and change nothing. “Cut checkout drop-off to 35%” is an outcome: it tells you whether what you shipped actually worked. We’re accountable for outcomes; outputs are how you get there, not what anyone answers for.
- It has exactly one owner. Every goal needs a single DRI, accountable for whether the number moves, not just whether the work shipped. Two owners means none: each assumes the other is watching it.
- There are few of them. A DRI can hold two or three goals in their head and act on the weekly signal each gives off. Hand them ten and a goal becomes a line nobody rereads until Learn.
And a goal cascades: it should trace all the way up. The north star sets the direction; its inputs get a capacity budget; strategic planning turns that budget into this prioritized set of bets; each bet becomes an initiative carrying its metric goal and narrative into Discover; and Learn closes the loop back to the next half’s bets. If you can’t trace a goal back to an input, it was probably invented to justify work already decided, which is backwards.
Where good bets come from#
Bets aren’t invented in the planning room: they’re collected before it, from the places that actually know where value is trapped:
- The diagnosis. Every sized leak in the value tree is a bet waiting to be written. This is the richest source and the one with numbers already attached.
- Two-pagers. The intake ritual where every team surfaces what they’re seeing and what they want to tackle. Bottom-up signal.
- Learn. Last half’s results (a bet that half-worked, a narrative that proved bigger than expected) is the strongest possible input to the next bet.
- Customer pain and data anomalies. A support theme, a drop-off nobody can explain, a cohort behaving strangely. Raw material, not yet a bet.
A candidate from any of these starts as a rough idea. Shaping is how it becomes a bet worth ranking.
Shaping a good bet#
A vague idea and a shaped bet look similar until you try to act on them. Shaping means forcing an idea to declare five things, starting with the end:
- The after-state (think with the end in mind). One line picturing the world once this bet has landed, in the spirit of an Amazon PR/FAQ: “a returning shopper never re-types an address again.” Writing the outcome before the work keeps you shaping toward a destination, not a task, and it is what makes a bet worth rallying to.
- A sharp problem, a specific gap, ideally one the diagnosis already sized. “Checkout is bad” isn’t a problem; “1 in 5 who reach checkout abandon at the address step” is.
- A falsifiable narrative, the belief stated so it could be wrong. If no result would change your mind, it’s not a narrative, it’s faith.
- A metric goal tied to an input, framed before to after (now to target) and traceable to the north star. If it doesn’t move an input, it doesn’t belong in the portfolio yet.
- A kill condition, what you’d see that means stop. Naming it now, before you’re attached, is what makes killing possible later.
| Unshaped idea | Shaped bet |
|---|---|
| ”Improve the checkout experience." | "Grow add-on attach 18% → 30%, because shoppers don’t attach today since the flow makes them re-enter details, not because they don’t want the add-on. Kill if attach climbs but returns rise: that’s pushing, not enabling." |
| "Make the site faster." | "Cut median page load 3.5s → 1.5s, because shoppers abandon a slow page before it loads. Kill if load falls but completion doesn’t follow: the real leak is elsewhere.” |
The kill condition is the part most teams skip and the part that most separates a bet from a wish.
Filter before you rank#
Not every shaped bet earns a place on the slate. Run each through a cheap filter before the expensive prioritization conversation: it kills the ones that would waste the room’s time:
- Does it tie to an input? No line to the north star → it’s solving a problem that doesn’t matter yet, or it’s mis-scoped. Cut or defer.
- Is the belief falsifiable? If you can’t state what would prove it wrong, you can’t learn from it. Send it back to shaping.
- Is this the cheapest way to learn? If a one-day test would tell you what a six-week build would, do the test first.
- Does it fit where the business is? A compliance bet in a pre-PMF quarter, or a growth bet mid-incident, can be right work at the wrong time.
Filtering is a recurring gate, not a one-time verdict. A bet that passed last half can fail this one if the diagnosis moved or Learn shrank the problem.
Size by how much you’re willing to spend to learn#
Survivors get sized, not precisely, but enough to know what you’re committing. And at planning time you don’t have a solution, so you’re not sizing the work, you’re sizing how much you’ll invest to find out if the belief holds:
| Size | Person-sprints | What it is |
|---|---|---|
| Sand | Under 1 | Bugs, urgent fixes, small improvements. Accounted for in the budget before any item is named, so it doesn’t vanish because it wasn’t planned. |
| Pebble | 1–2 | The default. Enough budget to discover, define, and validate properly, without over-committing before the belief is tested. |
| Rock | 2+ | Rare. Leadership in the room before it’s placed, because you’re committing real capacity to an untested belief. |
Most halves should be almost entirely pebbles and sand. That’s not timidity: it’s good scoping. Before calling anything a rock, ask: what’s the first pebble we could scope out and start with? Usually it exists, and the rock dissolves into a sequence. A bet that comes in under its budget means you learned cheaply: a good outcome, not wasted capacity.
Budget the capacity first#
The mistake most teams make is deciding item by item (“is this worth doing?”) without first deciding how much capacity there is to spend. Budget by category before naming a single item. Take total person-sprints for the half, subtract leave and overhead, and assign a percentage to each type of work: product, reliability, security, compliance, expansion:
Compliance 10% · Security 10% · Reliability 15% · Expansion 25% · Product 40%
These splits shift with stage and pressure: a pre-PMF team weights product heavily and spends almost nothing on compliance; a team mid-expansion shifts weight there. What matters is that the split is an explicit up-front decision, not something discovered after you’ve over-committed. Only once the budget exists do you pick bets against it. A bet that doesn’t fit its category’s budget gets cut or deferred: never squeezed in on the hope that everything runs faster than expected. Assume it runs slower.
Budgeting is where this page stops. Choosing between the bets that survive, and proving the chosen set actually adds up to the goal, is the next step: see Prioritization. One warning worth carrying across the boundary, because it is the most common way that step goes wrong: impact-vs-effort is a lens for challenging a candidate in the room, not a formula for ranking a backlog, and forcing a rock and a bug fix onto one blended score is false precision.
Sequence the committed slate#
This is ordering work you have already committed to for the half, which is a different job from ranking candidates against each other. Once the slate is set, order matters as much as the slate:
- Derisk first. Start with the bet carrying the most uncertainty: the one Discover is most likely to reshape. Learning that in week two beats learning it in week eleven.
- Parallelize what’s independent, sequence what isn’t. If one bet depends on another, finish the dependency first; don’t start both and hope the seams line up.
- Keep milestones visible. Every couple of weeks a bet should produce something PM and leadership can actually look at. A milestone nobody outside the team can see is a task, not a milestone.
A half is a portfolio, not a to-do list#
A to-do list assumes every item gets done and every item was worth doing. A portfolio assumes neither. Across a half, some bets pay off as the narrative predicted, some show the narrative was wrong, and some reveal a bigger problem than you started with, all three are normal, none mean the half failed. That’s why planning produces a prioritized portfolio of bets, not a feature checklist.
Learn is where each bet’s result comes back, and it drives the only two moves that matter:
- Double down when the metric moved and the narrative held: invest further, or extend to adjacent problems.
- Kill when the metric didn’t move, but first figure out why: wrong narrative, off execution, or a smaller problem than estimated. Each answer points somewhere different.
A team that only ever doubles down is protecting the plan, not reading the evidence. A team that kills at the first wobble never gives a belief runway. Learn is what tells you which you’re looking at.
Where bets go wrong#
Five failure modes, the same shape as the diagnosis and vision failure lists:
- No kill condition. A bet you cannot kill is a promise you will protect past the evidence. Name nothing that would stop it, and you will sunk-cost it to the end of the half.
- A vanity metric. The bet moves a number that looks good but is not an input, clicks or signups instead of the outcome. It “succeeds” and nothing downstream changes.
- An unfalsifiable narrative. “Improve the experience.” No result could prove it wrong, so you learn nothing whether it works or not.
- Sized by the solution, not the learning. You committed a rock’s worth of capacity to a belief a one-week test could have killed for a fraction of the cost.
- Orphaned. No DRI, or two owners, so nobody actually watches the number. A goal with no single name on it does not get chased once the half gets busy.
The Storefront example#
The diagnosis surfaced the leaks and sized them. Direction-setting turns that into a ranked, budgeted slate. Candidates arrive; the filter and sizing sort them:
| Candidate | Ties to an input? | Size | Call |
|---|---|---|---|
| One-tap add-on at checkout | Yes: add-on attach, directly | Pebble | ✅ ships first: most direct lever, derisk early |
| Saved address & payment | Yes: checkout completion | Sand | ✅ runs in parallel: independent, small |
| Rebuild storefront for speed | Yes: page load | Rock → first pebble | ◐ ship the first pebble (compress images); defer the rest |
| Loyalty points | No line to an input | Sand | ✗ declined: the pilot moved nothing |
| Dedicated live chat | Not yet | Pebble | ⏸ deferred: a real idea with no metric tie yet |
The three survivors, written as bets with their kill conditions:
- One-tap add-on (Pebble): attach 18% → 30%, because the re-entry step suppresses intent that’s already there. Double down if attach climbs and returns hold; kill if attach climbs but returns rise.
- Saved address & payment (Sand): completion 80% → 88%, because re-typing is the friction, not price or trust. Kill if completion doesn’t move: narrative was wrong, look elsewhere.
- Faster pages (Rock, scoped to its first pebble): load 3.5s → 1.5s, because slow pages bounce shoppers pre-cart. Kill if load falls but completion doesn’t follow: the leak is elsewhere.
That’s a portfolio: budgeted, sized, sequenced to derisk, each bet carrying the number it must move and the signal that would end it. Half Strategy is where this becomes a committed, written plan.
Related: The Framework, Diagnosis, Half Strategy, North Star & Inputs, Learn