Product prioritization frameworks: RICE, MoSCoW, Kano, ICE

Product prioritization frameworks are scoring or sorting methods that help a team decide what to build first. RICE multiplies reach, impact and confidence and divides by effort. ICE scores impact, confidence and ease. MoSCoW sorts requirements into Must, Should, Could and Won't. Kano classifies features by how customers react when they are present or absent.

What is the RICE framework?

RICE is a scoring model from Intercom's product team that rates each idea on reach, impact, confidence and effort. Sean McBride described it on Intercom's blog on 5 January 2018, saying the team built its own system from first principles after finding few methods that let different ideas be compared consistently.

Reach is the number of people or events affected in a set period, such as customers per quarter, taken from real product metrics where possible. Impact is scored on a fixed scale: 3 for massive, 2 for high, 1 for medium, 0.5 for low and 0.25 for minimal. Confidence is 100% for high, 80% for medium and 50% for low, and anything below that is a "total moonshot". Effort is counted in person-months across product, design and engineering, in whole numbers or 0.5 for work well under a month.

Reach, impact and confidence multiply, and effort divides, so the score reads as total impact per unit of time worked. The page shows the formula as an image, and ProductPlan writes it as Reach Impact Confidence / Effort.

How do you calculate a RICE score?

Multiply reach, impact and confidence, then divide by effort, and sort the list. The table below uses a hypothetical product team in Pune running a food-ordering app; every input is invented, and the scores were computed in Python.

The same calculation as a short script:

features = [
    ("Saved addresses at checkout", 6000, 1, 1.0, 1),
    ("One-tap reorder", 4000, 2, 0.8, 2),
    ("Dark mode", 9000, 0.25, 1.0, 1),
    ("UPI autopay", 2500, 3, 0.5, 4),
    ("Referral rewards", 1500, 2, 0.5, 3),
]

def rice(reach, impact, confidence, effort):
    return reach * impact * confidence / effort

for name, *inputs in sorted(features, key=lambda f: -rice(*f[1:])):
    print(f"{rice(*inputs):>7g}  {name}")

   6000  Saved addresses at checkout
   3200  One-tap reorder
   2250  Dark mode
  937.5  UPI autopay
    500  Referral rewards

Two things stand out in the result. Dark mode has the lowest impact per user and still outranks UPI autopay, because it reaches nine thousand users for one person-month. UPI autopay has the largest impact per user, but a 50% confidence and four person-months pull it down. If customer interviews raised confidence to 80%, its score would rise from 937.5 to 1500, which is the practical use of the confidence factor: it rewards the team for doing research before building.

What is the ICE scoring model?

ICE scores each idea on impact, confidence and ease, each from one to ten. In ProductPlan's version the three scores are multiplied, and write-ups differ on how to combine them. ProductPlan credits it to Sean Ellis, known for coining "growth hacking", and its example gives an item scored 7, 6 and 5 a total of 210 and an item scored 9, 7 and 2 a total of 126, so a low ease score can pull a high-impact idea below a modest one.

ICE drops reach and swaps effort for ease, which makes it quick and also more subjective. ProductPlan says scores vary with who does the scoring, that few people can judge all three inputs, and that teams need a shared definition of what a 7 means. It suits pre-work and quick relative ranking of experiments better than ordering a full roadmap.

What is MoSCoW prioritisation?

MoSCoW sorts requirements into Must Have, Should Have, Could Have and Won't Have this time. The Agile Business Consortium describes it as a technique within DSDM projects where time is fixed, with Must Haves forming the Minimum Usable SubseT that the project commits to deliver.

The Consortium's test for a Must Have is to ask what happens if the requirement is not met. If the answer is to cancel the project, it is a Must. If there is a workaround, even a manual and painful one, it is a Should or a Could. Should Haves are important but not vital, Could Haves are desirable and have less impact, and Won't Haves are agreed not to be delivered in this timeframe, which keeps them from creeping back in informally.

DSDM recommends typically no more than 60% Must Have effort and a pool of Could Haves of around 20%, so that the Must Haves are protected by contingency. It also says the difference between Should and Could can be subjective, so teams should agree criteria at the start. In the Pune example, reordering delivered orders and warning about unavailable items would be Musts, saved addresses a Should, order notes a Could, and scheduled orders a Won't for this release.

What is the Kano model?

The Kano model classifies features by how customers feel when a feature is present and when it is absent. It comes from a 1984 paper, "Attractive Quality and Must-Be Quality" by Noriaki Kano and three co-authors, published on 15 April 1984 in the Journal of the Japanese Society for Quality Control, which proposed a two-dimensional view of quality instead of a single scale.

A Kano survey asks two questions about each feature: how would you feel if it were there, and how would you feel if it were not. A peer-reviewed 2022 study in JMIR mHealth and uHealth used five answer options, from being very pleased to being really bothered, and sorted features into attractive (presence delights, absence does not hurt), must-be (absence causes strong dissatisfaction, presence adds little), performance (satisfaction tracks how much is delivered) and indifferent (no effect).

Two more categories cover odd answers: reverse, where the feature's presence displeases and its absence pleases, and questionable, where the two answers contradict each other. The study notes that both can come from badly worded questions.

Kano answers a different question from RICE. It says what kind of feature something is, not how much effort it deserves. It also needs a survey, and that study found that assigning each feature the most common category left all nine attributes in one category, which made prioritising among them impossible without extra analysis.

Which prioritization framework is best?

No framework is best in general; the better choice depends on the data available, the decision being made and how fast it must be made. The table gives the criterion for each.

In practice teams combine them. MoSCoW sets the scope of a fixed release, RICE orders the Should and Could items, and a Kano survey checks whether a candidate delighter is something customers actually care about. The guide to product manager interview questions shows how prioritisation questions are asked, and the guide to north star and AARRR metrics covers how to choose the impact measure that RICE and ICE depend on.

How do you run a scoring session without gaming it?

Score against one agreed goal, and treat the numbers as a conversation aid.

1. Agree the goal and the metric that impact is measured against before any scoring.
2. List candidates at a similar size, so a small tweak is not scored against a platform rebuild.
3. Estimate reach and effort from real data or engineering input, and write the source beside each number.
4. Score confidence honestly: low confidence on a large idea is a reason to research first.
5. Sort, then sanity-check the top and bottom. Intercom suggests reconsidering estimates that look too high or too low, or accepting that gut instinct may be wrong.
6. Record every exception. Intercom says a lower-scoring project may go first when it is a dependency for another project or is "table stakes" for certain customers, and that scoring makes such trade-offs visible.

What are the limits of scoring frameworks?

Scores look precise and are built from estimates. Atlassian says RICE can be time-consuming and subjective, and that the methods for judging each factor can change, which makes results inconsistent. The same guide lists survey effort as the cost of Kano and unclear criteria for Should Have, and for whether Won't Haves stay in the backlog, as the weakness of MoSCoW.

Scoring also ranks only what is on the list. A framework cannot say whether the right problems were found, which is the job of discovery, and a team that games confidence or effort can steer any model to the answer it already preferred. Scoring the same candidates in two models, such as the hypothetical features above in both RICE and ICE, is a useful check: when the two disagree, the gap may point to a weak estimate worth revisiting. For a wider survey of tools, see the top product management tools and frameworks guide.

Where do prioritisation frameworks fit in a product management programme?

Certificate Programme in Product Management in the Agentic AI Era is a live online programme from IIM Tiruchirappalli (IIM Trichy), run with Masai as the implementation partner, covering product foundations, platform strategy, AI for product managers, agentic AI and a team capstone to design and pitch an agentic-AI-powered product. Its listed topics include PM frameworks, experimentation and roadmapping, in modules such as Foundations in Product Management.

Frequently asked questions

What is the RICE framework?

RICE is a prioritisation model from Intercom that scores each idea on reach, impact, confidence and effort. Reach, impact and confidence are multiplied and the result is divided by effort, giving a score for total impact per person-month. It was described by Sean McBride in a 2018 Intercom article.

Which prioritisation framework is best?

None is best in every case. RICE suits comparing several ideas when usage data exists, ICE suits quick ranking of experiments, MoSCoW suits fixed-deadline scope, and Kano suits judging which features customers expect or enjoy. Pick by the decision being made, and expect to combine two of them.

What is the difference between MoSCoW and Kano?

MoSCoW sorts requirements by how necessary they are to a delivery, using the question of whether the project would be cancelled without them. Kano sorts features by customer reaction to their presence and absence, measured by survey. MoSCoW is set by the team; Kano answers come from customers.

Is ICE better than RICE?

ICE is faster because it has three inputs and no reach estimate, but it is more subjective, since each score rests on opinion. RICE asks for a reach number and an effort estimate in person-months, which takes longer and can be checked against data. ProductPlan suggests ICE for pre-work and quick ranking.

Where does MoSCoW come from?

MoSCoW belongs to DSDM, the agile project framework whose guidance the Agile Business Consortium publishes, and the Consortium describes it as a technique for projects where time is fixed. The Consortium's description of the technique names no individual inventor.

Next step

Scoring becomes useful once the team can estimate reach and impact from real product data. To practise these frameworks on case work, see the Certificate Programme in Product Management in the Agentic AI Era page.