Prioritization

When everything looks worth doing, prioritization is the skill that decides what actually gets done. It’s the last step of product sense and the one with the sharpest teeth, because, as Constraints & Cost lays out, saying yes to one thing means saying no to ten others, out loud, to people who wanted those ten. A product person who can’t prioritize isn’t neutral; they’re just letting whoever complains loudest set the roadmap.

Prioritizing well takes two things: a clear goal to measure against, and the honesty to say no. This doc gives you a method for both.

This page is the step after Bets. Bets is where candidates are proposed, shaped, filtered, and where the half’s capacity is budgeted by category. This page starts from that budget and those survivors, and decides which ones actually get built now.

Why This Is Hard#

Everything on a feedback list has someone behind it who wants it. Every item is “important” to the person who raised it. Without a method, prioritization collapses into one of a few bad defaults, and all of them feel reasonable in the moment:

• Loudest wins: whoever complains most gets built for. The roadmap belongs to the most persistent voice, not the biggest opportunity.
• Easiest wins: the team does the quick things because they’re satisfying to finish, and the hard high-impact work never starts.
• Newest wins: whatever was mentioned in the last meeting jumps the queue.

The whole point of a method is to replace these with one question, asked the same way every time: what moves the goal the most, for the least effort?

The Method: Score Against the Goal#

What’s expected: You can take a list of candidate features and produce a defensible order, with the reasoning visible.

Prioritization is a filter you run in one direction, from goal to feature, never the reverse:

Score each candidate on two things:

• Impact on the goal. How much would this move the number you care about? Rate it high, medium, or low, and be able to say why. A fix that recovers abandoned checkouts is high. A cosmetic tweak is low, however annoying it is.
• Effort to ship (time to market). How much work is it, including complexity and the technical debt it leaves behind? This maps directly to how we size work in How We Build: sand, pebble, or rock.

Then order by the balance of the two: the most impact for the least effort goes first. This is judgment, not a formula, you’re weighing impact against effort by eye, not computing a precise score. A high-impact sand-sized fix beats a high-impact rock every time, because you can ship it now and move the goal this sprint. When two items tie, break it with two rules: the one serving your prioritized persona wins, and a confirmed pain beats an assumed one (go cheaply confirm the assumed one first, see Earning the Opinion). This is the same instinct behind defaulting to pebbles: the win you ship this month beats the bigger win you’re still scoping next quarter.

A Worked Example#

Take the six items from the Storefront walk-through, now that Pain Points & Winning has told us what each one really is. Score them:

The list that arrived as six equal bullet points is now a sequence with a reason behind every rank. Items 1 and 2 lead because they’re where orders actually leak, and we’ve sized each one from evidence: saved address and pay is worth ~+190 orders/week, faster pages ~+160. They tie on impact and effort, so the bigger sized prize goes first. Instrumenting the exact drop step is third, Sand-cheap, and it sharpens everything after it, including the bet. Search is a real fix but not where the money is bleeding. And the images, icons, and footer, the entire original list, land last, because fixing them moves no orders at all. That flat 1,900 is the receipt: every prior cycle went to that bottom row.

None of this took special expertise. It took a goal, an honest read of impact, and the willingness to put the loud, low-impact item where it belongs. The winning bet, the full one-tap checkout rock, is deliberately absent from this queue; it’s handled separately, below.

The Sufficiency Test: Does It Add Up to the Goal?#

What’s expected: Before you commit to a plan, you check that if every item on it succeeded, it would actually close the gap to the goal, and you go back if it wouldn’t.

Ranking tells you the order. It does not tell you whether the list is enough. This is the test the Storefront failed for two straight halves: teams shipped real improvements, executed them well, and orders stayed flat at ~1,900, because nothing they shipped was ever sized against the gap. Doing everything on a list, perfectly, and still missing the goal is not an execution failure. It’s a planning failure, and this test catches it before the half starts, not after.

The test is arithmetic, and it borrows straight from Diagnosis:

1. State the gap in the currency of the goal. The Storefront needs +350 orders/week to break the plateau (1,900 toward the +18% target).
2. Size what each bet is worth, in that same currency. Saved address & pay ≈ +190/wk. Faster pages ≈ +160/wk. Sizes come from evidence, a prior A/B, a benchmark, a driver model, not round numbers.
3. Add them up and compare to the gap. +190 + +160 = +350. The plan clears the gap. It is sufficient.

Now watch what the test would have caught. If the plan had been “saved address & pay” alone, that’s +190 against a +350 gap: done flawlessly, it still misses by 160. The list was wrong, and no amount of execution fixes a list that doesn’t add up. And if the plan had been the original six cosmetic items, worth ~0 orders between them, the test screams immediately: this plan, fully shipped, moves the goal by nothing. That is exactly how a store stays flat while everyone stays busy.

Two ways to fail the test, and the move for each:

• The bets don’t sum to the gap. You’re under-scoped. Find more leverage, a bigger bet, another sized leak, or admit the target isn’t reachable this cycle and reset it honestly. Do not pretend a +190 plan hits a +350 goal.
• You can’t size the bets at all. Then you don’t have a plan, you have a wish. Go back to Earning the Opinion and put numbers on the leaks before you commit capacity to them.

A plan that passes this test is one you can stand behind: if we do these things, and we do them right, we will be in a measurably better place. A plan that skips it is a hope with a schedule attached.

Sequencing and the Winning Bet#

What’s expected: Your order reflects not just quick wins but the bet that makes us the best.

This is ranking candidates against each other, which is distinct from ordering an already-committed slate (Bets covers that). Pure impact-over-effort scoring optimizes for the near term, and left alone it will starve the big bet forever, because the winning move is usually a rock and rocks never win a ratio contest against sand. So hold two lists in tension:

• The near-term queue: ranked by impact over effort. Keeps the product improving every sprint and clears the high-impact cheap fixes fast.
• The bet: the one bigger investment that makes us the best in the world at something, the one-tap checkout seam. It rarely wins on ratio alone, so it gets protected deliberately: a lane of its own, sequenced across sprints, not left to lose every prioritization round to a pile of quick wins.

A roadmap that’s all quick wins is a product that gets slightly better forever and never wins. A roadmap that’s all big bets ships nothing for a quarter. The judgment is holding both: bank the cheap high-impact fixes and protect the bet at the same time.

Saying No#

What’s expected: You can decline a request clearly, with a reason, without leaving the person feeling dismissed.

Most of prioritization is saying no, and how you do it decides whether people keep bringing you signal. The rule from How Systeric Works holds: every decision not to build is as deliberate as a decision to build, and it gets said clearly.

• Name the goal you’re prioritizing against, so the no is about the goal, not the person.
• Acknowledge the request is real, low priority is not the same as invalid.
• Say where it sits and what would change its rank. “This is a real fix and it’s fifth; it moves ahead if we see it costing us orders.”

Done this way, a no keeps the relationship and keeps the feedback coming. Done badly, people stop telling you things, and then you’re prioritizing blind.

Next: Case Study: The Storefront