Prioritization frameworks: RICE, ICE, MoSCoW, Kano and what to use instead
The short answer
A prioritization framework is a repeatable way to compare work. RICE, ICE, MoSCoW, Kano and cost of delay each answer a different question, and none decides for you. A small team with customers and agents can rank inside its bets: what is broken first, then what customers asked for, then ideas. Annsa keeps that order on one list.
A prioritization framework is a repeatable way to compare pieces of work, so you pick the next one on purpose.
TL;DR
- RICE, ICE, MoSCoW, Kano and cost of delay each answer a different question. None of them decides for you.
- Their weak spot is the same: the inputs are guesses, and customer evidence is usually missing.
- A small team with customers and agents can skip the formula. Rank inside your bets: what is broken first, then what customers asked for, then ideas.
When to use one: when you cannot explain why item A is ahead of item B, or when two people rank the list differently. When not: skip a score if you have fewer than ten items. Just order them and say why.
What is a prioritization framework?
It is a short list of questions you ask of every item, in the same order. The answers can be numbers (RICE, ICE), groups (MoSCoW, Kano) or money (cost of delay). The point is consistency. For the short definition, see feature prioritization framework and feature prioritization.
Which frameworks are there, and what does each one answer?
| Framework | Question it answers | Output | Best when |
|---|---|---|---|
| RICE | How much good per unit of work? | A score | A long list and some usage data |
| ICE | Which quick bet first? | A score | Fast triage of ideas or experiments |
| MoSCoW | What is in this release, and what is not? | Four groups | A fixed date or budget |
| Kano | What do customers expect, and what delights them? | Categories | Deciding where to invest in quality |
| Cost of delay | What does waiting cost us each week? | Dollars per week | Work where time has a price |
RICE
Reach, impact, confidence and effort. Multiply the first three and divide by effort. Sean McBride of Intercom wrote it up in January 2018. In that post, impact runs from 0.25 (minimal) to 3 (massive) and confidence is 100%, 80% or 50%. Anything below 50% is, in his words, a moonshot.
Honest take: confidence is the best idea in it, because it makes you say how much of the number is a guess. The weak part is reach and impact, which need data a new product does not have. See RICE framework.
ICE
Impact, confidence and ease, each scored 1 to 10. Sean Ellis, who coined "growth hacking," is credited with it, as a quick way to rank experiments. Versions differ on whether you multiply or add the three.
Honest take: fast and rough. Two people will score the same idea very differently, and ease is the score an agent has changed most.
MoSCoW
Must have, should have, could have, won't have this time. Dai Clegg developed it in 1994, and it became part of the DSDM method. It sorts work rather than ranking it.
Honest take: the "won't have" group does the real work, because it writes the exclusions down. Its known weakness: it does not help you choose between two musts, and everything drifts into must. Cap the musts. See MoSCoW method and scope creep.
Kano
Noriaki Kano and colleagues published it in 1984. Features fall into must-be (expected, noticed when missing), one-dimensional (more is better), attractive (unexpected delight) and indifferent. You find the category by asking customers two questions per feature: how would you feel if it were there, and how would you feel if it were not.
Honest take: it is research, not a score. It needs a survey and a fair number of answers, so it fits a feature you are unsure about, not the whole list. See Kano model.
Cost of delay
Don Reinertsen, in The Principles of Product Development Flow (2009), argues that the one number to know is what a month of delay costs. Divide it by how long the work takes and you get CD3, a way to do the most valuable short jobs first.
Honest take: the right question for work tied to money or a date, such as a renewal or a launch. For most small teams the dollar figure is a guess too.
Why do formulas fall short for a small team?
- The inputs are guesses. A 7 for impact is a feeling with a number on it.
- Customer evidence is missing. The score rarely shows the request in their words, or how many accounts. Voting favors people who write in, and revenue favors large accounts. Pick the rule on purpose. See customer feedback prioritization.
- Broken things do not fit. A bug that blocks a customer is not a lower RICE score. It is a different category.
- Effort moved. When Claude Code, Cursor, Codex or Grok do the building, some work shrinks from a sprint to an afternoon and some does not. Old effort numbers reorder the list wrongly.
- A formula can hide the argument. The useful part is the disagreement underneath the score.
How does a founder with customers and agents really decide?
Use an order, not a formula.
- Your bets. Write down two or three things you are trying to make true this quarter, in order. Work that serves the first bet beats work that serves the third. See bets.
- What is broken. Inside a bet, if a person has marked it broken, it goes first. A customer who cannot do the job is a bigger problem than any new feature.
- What customers asked for. Then count separate accounts, then revenue, then how urgent. Keep their exact words on the row.
- Ideas. Yours, your team's and your agents' findings. Good ideas move up when customer evidence shows up.
Use a score only to break ties inside one group. If two items sit in the same place, ask the cost-of-delay question: what does waiting a month cost?
This is the order Annsa follows. It is a sentence you can say out loud, which is the test of a good rule.
A prioritization template
The approach above, as a sheet: one row per item. Fill in the bet and the evidence first. The score comes last and only breaks ties.
Prioritization template (one row per item)
Item: [what becomes true, in the customer's words]
Bet it serves: [bet 1 / bet 2 / bet 3 / none]
Broken? (yes / no): [if yes, it goes first within its bet]
Evidence: [names and accounts]
Their words: [exact quote]
Separate accounts: [count]
Revenue behind it: [$ per month, if known]
Why now: [what happens if it waits a month, in dollars or in customers]
Effort, as of today: [hours or days, with the agent you would use]
Confidence (high/med/low): [and what it rests on: calls, data or gut]
Tie-break score (optional): [impact 1-10 x confidence 1-10 / effort]
Decision and date: [do now / next / later / not doing, and why]
If two people fill in "why now" differently for the same item, that is the conversation worth having.
How does Annsa do it?
Annsa is AI agent management, and the source of direction for your agents. A person makes the call.
- Priorities are ranked within your bets, in your order. What a person marked broken (P0 or P1) comes first, then what customers asked for, then ideas.
- After that: severity, how many accounts asked, revenue and urgency.
- A person's severity always wins. You choose; Annsa never decides for you.
- Every row keeps the customer behind it, their exact words, the account and its revenue, so you can check the reason in a click.
- Claude Code, Cursor, Codex and Grok read the same ranked list over MCP and claim the top job.
See Choose what to build and, for where the ideas come from, idea management software.
Sources
- RICE: Sean McBride, RICE: Simple prioritization for product managers, Intercom, 5 January 2018.
- MoSCoW: MoSCoW method, Wikipedia (Dai Clegg, 1994; DSDM).
- Kano: Kano model, Wikipedia, citing Kano, Seraku, Takahashi and Tsuji (1984), "Attractive quality and must-be quality," Journal of the Japanese Society for Quality Control.
- Cost of delay: Cost of delay, Wikipedia, citing Don Reinertsen, The Principles of Product Development Flow (2009).