Prioritization.

Key terms

Backlog

The list of ideas and work a team might do, in order of priority.

RICE

A scoring method from Intercom: (Reach × Impact × Confidence) ÷ Effort.

Person-month

The work one person can do in a month. RICE uses it as the unit for effort.

ICE

A lighter scoring method, credited to Sean Ellis: Impact, Confidence, and Ease, each usually scored from 1 to 10.

Kano model

Noriaki Kano’s way of sorting features by how they affect customer satisfaction: must-be, one-dimensional, attractive, indifferent, and reverse.

MoSCoW

Must have, Should have, Could have, Won’t have this time: a way to agree the scope of a release with a fixed date.

The idea

Every product team has more good ideas than time. That’s normal. The trouble starts when the order is set by whoever asks loudest, or most recently, or has the biggest title.

Prioritization methods are a fix for that. Each one asks you to say out loud what you believe about an idea: how many people it reaches, how much it helps, how sure you are, what it costs. Then others can check your thinking. None of these methods knows your product better than you do. They make your judgment visible, so it can be argued with and improved.

And every yes means saying no to other good ideas. Apple’s short film “Intention”, which opened its developer conference in 2013, puts it in one line: “There are a thousand no’s for every yes.” The methods in this lesson help you reach those no’s fairly, and explain them.

The lesson, in seven parts

1. 1Start with one goal, one period, and one list.

   Before you score anything, settle three things. Without them, any method just dresses up opinions.

   • One goal. What are you trying to change? At the made-up store: more first-apartment movers buy a sofa with confidence, and fewer sofas come back for size.
   • One period. Ideas are compared over the same stretch of time, usually a quarter.
   • One list. Every idea goes on it, including the ones from leaders and sales. Next to each, write the problem it solves, not just the feature name.

   Then bring in the people who know each part. Engineers estimate effort. Designers and researchers know where customers struggle. Data analysts know how many people reach each page. Prioritizing alone, at your desk, misses most of what you need to know.

2. 2Sort fast with value versus effort.

   The quickest method is a two-by-two chart. Up the side: value, meaning how much an idea helps customers and the goal. Along the bottom: effort, meaning how much work it takes. Nielsen Norman Group describes running a chart like this as a team exercise:

   • Write each idea on its own sticky note.
   • Agree the two criteria and the scale. The criteria should come from your goals; the scale can be as simple as high and low.
   • Let each person vote only in their own area: engineers on effort, designers and researchers on value. You run the session, keep everyone on the goal, and bring the data on how many people each idea would reach.
   • Place the notes, then talk through the surprises: ties, ideas nobody voted for, ideas at the edges. Move notes as you agree.

   High value and low effort goes first. High value and high effort needs a plan. Low value and high effort deserves a hard question. The chart is fast, and anyone can read it. Its weakness: “value” hides several guesses in one word. When the calls get close, or the stakes get high, break value apart. That’s what RICE does.

3. 3Score ideas with RICE, step by step.

   Sean McBride described RICE on the Intercom blog in 2018, as the scoring system his team settled on “after lots of testing and iteration.” You rate each idea on four factors, using his scales:

   • Reach: how many people will this affect in a set period? Count people or events per period, like customers per quarter, from real data where you can.
   • Impact: how much will it move the goal for each person? Pick from 3 (massive), 2 (high), 1 (medium), 0.5 (low), or 0.25 (minimal).
   • Confidence: how sure are you of your estimates? 100% (high), 80% (medium), or 50% (low). Below that, McBride calls it a “total moonshot.”
   • Effort: how much work from everyone, product, design, and engineering, in person-months. Use whole numbers, or 0.5 for anything well under a month.
   • The score: (Reach × Impact × Confidence) ÷ Effort. In McBride’s words, it measures “total impact per time worked.”

   Idea	Reach	Impact	Confidence	Effort	RICE score
   Doorway-and-room size check	6,000	2	80%	2	4,800
   Delivery date on product pages	8,000	0.5	100%	1	4,000
   Room-size filter on search	9,000	0.5	80%	1	3,600
   3D room planner	3,000	3	50%	6	750
   Chatbot for product questions	4,000	1	50%	4	500

   The made-up store’s backlog, scored. Reach is sofa shoppers per quarter who would meet the change; effort is in person-months.

   Here’s the reasoning behind the numbers. The size check reaches fewer shoppers than the filter, but interviews showed fit is their biggest worry, so its impact is high; confidence is 80% because that impact is still an estimate. The delivery date is cheap and backed by support data, so confidence is 100%, but it helps each shopper only a little. The 3D planner could help a lot, but it’s months of work and untested. The chatbot reaches only shoppers who ask, and nobody knows how well it would answer fit questions. Then read the result with care:

   • Sort, then sanity-check. McBride’s advice: if a score seems too high or too low, reconsider your estimates, or accept that your gut instinct may be wrong.
   • Treat close scores as a tie. 4,800 and 4,000 are close; change one guess and they swap. Decide close calls on other grounds.
   • Break the order when there’s a reason. McBride names two: one project may be a dependency for another, or a feature may be “table stakes” for some customers. The score shows you’re making that trade-off on purpose.
   • Raise confidence cheaply. A quick prototype test of the size check could move its confidence up before you commit two person-months.

4. 4Use ICE for quick experiments.

   ICE is a lighter score, made for ranking lots of small tests. Sean Ellis, founder of GrowthHackers, described his team’s version in a 2016 talk: impact (if this works, how much will it move the needle?), confidence (how much data supports it?), and ease (is it quick to test, or weeks of engineering?).

   Each factor is usually scored from 1 to 10. Sources differ on how to combine them: some teams average the three, and others multiply them, as product coach Itamar Gilad does (Impact × Confidence × Ease). Either works, as long as your team uses the same rule every time.

   Experiment	Impact	Confidence	Ease	Average
   Show the delivery date next to the Add to cart button	4	8	9	7.0
   Add a “measure your doorway” tip with a diagram	6	6	8	6.7
   Free returns for size, for one month	7	4	3	4.7

   Made up. Multiply instead of averaging and the first two tie at 288, with the third at 84. That’s why you pick one rule and keep it.

   Reach for ICE when ideas are small and quick to test, and running the test beats debating the estimate. The trade-off: 1 to 10 scores are looser than RICE’s counts, so two people can score the same idea very differently. Agree what a 3 and an 8 mean before you start.

5. 5Use Kano to learn how customers feel about a feature.

   RICE and ICE rank ideas by your own estimates. The Kano model starts from customers instead. Noriaki Kano and his colleagues published it in 1984, in a paper called “Attractive quality and must-be quality.” The idea: features don’t all affect satisfaction the same way.

   Category	What happens	Made-up furniture store example
   Must-be	Missing it makes customers unhappy; having it only gets you to neutral	Accurate product sizes
   One-dimensional	The more of it, the happier customers are	Faster delivery
   Attractive	Missing it is fine; having it delights	Seeing the sofa in your own room on your phone
   Indifferent	Customers don’t care either way	Which warehouse the sofa ships from
   Reverse	Some customers are less happy when it’s there	A chat window that pops open by itself

   Categories from Kano and colleagues (1984), as explained in the Center for Quality of Management Journal (1993).

   To find a feature’s category, ask customers rather than guessing. A Kano questionnaire asks about each feature twice: once if it’s there (“If the product page shows whether the sofa fits your doorway, how do you feel?”) and once if it isn’t (“If it doesn’t, how do you feel?”). Each answer is one of five: I like it that way, it must be that way, I am neutral, I can live with it that way, or I dislike it that way. The three in between (must be, neutral, can live with it) are the middle answers. The pair gives the category. “Like” plus “dislike” means one-dimensional. “Like” plus a middle answer means attractive. A middle answer plus “dislike” means must-be. Middle answers to both mean indifferent. “Dislike” when it’s there plus “like” when it isn’t means reverse. And “like” to both usually means the question was misread. A useful habit: cover the must-bes first, then add a few attractive features to stand out. And ask again from time to time, because what customers expect can change over time.

6. 6Use MoSCoW to agree what a release must include.

   MoSCoW answers a different question. Not “what first?” but “with a fixed date, what must this release include?” Dai Clegg developed it in 1994, and it’s part of DSDM (the Dynamic Systems Development Method), a project framework published by the Agile Business Consortium. The letters stand for Must have, Should have, Could have, and Won’t have this time; the o’s are only there to make it pronounceable.

   • Must have: the Minimum Usable SubseT (MUST). Ask “what happens if this requirement is not met?” If there’s no point releasing without it, it’s a Must. If there’s any way around it, even a painful manual one, it isn’t.
   • Should have: important but not vital. Painful to leave out, but the release still works, perhaps with a workaround.
   • Could have: wanted, but less important. These are the first to drop if the deadline is at risk.
   • Won’t have this time: agreed as out of scope for now, and written down, so it doesn’t sneak back in.

   Requirement for the size check launch	Priority	Why
   Accurate door and room checks for every sofa in the range	Must	A wrong “yes” means a sofa that doesn’t fit
   Works well on phones	Must	Most first-apartment movers shop on their phones; without it, most of them can’t use the check at all
   Remembers your measurements for next time	Should	Helpful, but shoppers can type them again
   Checks stairs and tight corners	Could	Useful, but the doorway check helps most shoppers
   Armchairs and beds	Won’t have this time	Sofas first; look again next quarter

   A made-up example.

   Keep the Musts honest. DSDM recommends that Must Haves take typically no more than 60% of the effort, with a pool of Could Haves around 20%. That spare room is what lets the team keep the date. If everything is a Must, nothing is.

7. 7Choose the method, and explain the result.

   No method is best for everything. Match it to the decision, using the table below. You don’t need all of them. Pick the two or three that fit the decisions your team makes most often.

   Then explain the result. A ranked list on its own won’t convince anyone, and a score can feel like a verdict from a machine. Walk people through it in this order:

   • Start with the goal everyone agreed on, not the scores.
   • Show the list, the scores, and the key assumptions behind them, so people can challenge a number instead of the whole conclusion.
   • Say what you’re not doing, and why, in plain words.
   • Say what would change your mind: new data, a test result, a change in the goal.
   • Give the people whose ideas ranked lower a path: what you’d need to see, or when you’ll look again.

   Situation	Reach for	Why
   A long list, a first pass, little time	Value versus effort	Fast, visual, easy to do as a team
   Choosing a few bigger projects for a quarter	RICE	Separates reach, impact, and confidence, so the guesses are visible
   Many small experiments to run quickly	ICE	Light enough to score dozens of ideas
   Unsure which features customers expect and which they’d love	Kano	Uses customers’ answers, not your estimates
   A fixed date, and a release to scope	MoSCoW	Agrees what must ship, and what can drop
   Waiting itself has a cost, like a seasonal deadline	Cost of delay, or Weighted Shortest Job First (WSJF)	Puts a price on waiting, so urgent work rises. In the Scaled Agile Framework (SAFe), WSJF divides the relative cost of delay by the relative job duration.

   Other methods exist too, such as Jeff Patton’s user story mapping, which lays out user stories along the user’s journey through the product.

   The template

   Our goal this quarter is [goal]. We scored [number] ideas against it. We’re doing [top ideas] first, because [main reason]. We’re not doing [idea] yet, because [reason]. We’ll look again if [what would change our mind].

   Filled in, for the made-up furniture store

   Our goal this quarter is more first-apartment movers buying a sofa with confidence, and fewer size returns. We scored five ideas against it. We’re doing the doorway-and-room check first, then the delivery date on product pages, because they do the most for the goal for the work they take: fit is shoppers’ biggest worry, and the delivery date is cheap and proven. We’re not building the chatbot yet: it reaches only shoppers who ask, and we don’t know how well it would answer fit questions. We’ll look again if size returns don’t fall, or if support hears new kinds of questions.

   Send the note before the meeting, not after. A “not now” is easier to hear when people can see the reasoning, and know what would bring their idea back.

With AI: AI can help with the groundwork: pulling reach numbers from your analytics, grouping a long list of requests, drafting first-pass scores, or summarizing customer feedback for each idea. But a score is only as good as the estimates inside it, and AI will happily produce confident numbers for things nobody knows yet. Treat its scores as a first draft for the team to argue with. The decision, and explaining it to the people it affects, stays with you.

GOAL (what should change):
PERIOD (for example, this quarter):

RICE SCORING
Reach: people or events per period (use real data where you can)
Impact per person: 3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal
Confidence: 100% high, 80% medium, 50% low
Effort: person-months across product, design, and engineering
Score = (Reach x Impact x Confidence) / Effort

Idea | Problem it solves | Reach | Impact | Confidence | Effort | Score
1.
2.
3.
4.
5.

CHECKS
[ ] Close scores treated as ties
[ ] Dependencies and table-stakes items noted
[ ] Effort estimated with engineers
[ ] Scores that rest on guesses marked; one guess to test:

IF THE DATE IS FIXED: MoSCoW
Must (no point releasing without it; about 60% of effort at most):
Should (important, has a workaround):
Could (first to drop; about 20% of effort):
Won't have this time:

NOTE TO STAKEHOLDERS
Our goal this quarter is ___. We scored ___ ideas against it.
We're doing ___ first, because ___.
We're not doing ___ yet, because ___.
We'll look again if ___.

Ask AI about this lesson

All lessons