How to Prioritize Features

Most feature prioritization advice is a list of frameworks and an invitation to pick one. That is why teams argue about whether to use RICE or MoSCoW: they are treating tools that answer different questions as rivals. A North Star metric answers "which direction?", RICE answers "which of these features first?", an impact and effort matrix answers "what are we trading off?", and MoSCoW answers "what is the smallest version worth shipping?". Run them in that order and the output of each becomes the input of the next.

RICE was built at Intercom, and Sean McBride's original write-up gives the scales most teams still use: Impact runs from 3x for massive down to 0.25x for minimal, and Confidence is 100, 80 or 50 percent. He is also clear about its limits: "RICE scores shouldn't be used as a hard and fast rule." That caveat is why the sequence below does not stop at the score.

What should you decide before you prioritize anything?

Pick the metric the ranking will serve. Without it, every stakeholder scores Impact against a different goal, and the RICE table becomes a proxy for an argument about strategy. A useful North Star is a single number that reflects value the customer actually gets, moves within weeks rather than years, and can be changed by the team doing the prioritizing. Revenue fails the first test; page views fail the second.

To keep this concrete, take a fictional product: Shiftly, an app hospital nurses use to swap shifts with colleagues. Nurses post shifts they cannot work, colleagues with the right qualification pick them up, and a ward manager approves the swap. The team picks completed shift swaps per week as its North Star, because every completed swap is a nurse who got the time off they needed and a ward that stayed staffed. More examples of how to choose one are in North Star metric examples.

How do you rank features with RICE?

List the candidate features, then score each on the four RICE factors using the scales from Intercom's RICE article. Reach is people affected per quarter, Impact is the effect on the North Star per person, Confidence is how much evidence backs those two guesses, and Effort is person-months. The score is Reach times Impact times Confidence, divided by Effort.

Shiftly's five candidates, with invented but plausible numbers:

Feature	Reach (per quarter)	Impact	Confidence	Effort (person-months)	RICE score
A. Push alert when a matching swap is posted	4,000 nurses	1	80%	1	3,200
B. One-tap approval for ward managers	1,500 swaps	2	80%	2	1,200
C. Auto-suggest swap partners by qualification	3,000 nurses	2	50%	4	750
D. In-app chat between nurses	2,000 nurses	0.5	80%	3	267
E. Payroll export for managers	200 managers	1	100%	1	200

The ranking is A, B, C, D, E. Two things in the table matter more than the order. Feature C has high Impact but only 50 percent Confidence, which means nobody knows yet whether auto-suggestions would change behaviour. And Feature E scores last, but if hospitals refuse to buy without a payroll export, it is table stakes, which is exactly the exception McBride names. The full factor-by-factor detail is in the RICE prioritization framework guide, and ICE scoring is the lighter alternative when Reach is hard to estimate.

How does an impact and effort matrix change the decision?

A RICE score collapses four numbers into one, which hides the shape of each bet. Plotting the same features on a two-by-two of impact against effort brings it back:

	Low effort	High effort
High impact	Quick wins: A (push alert), B (manager approval)	Big bets: C (auto-suggest)
Low impact	Fill-ins: E (payroll export)	Money pits: D (in-app chat)

Now the conversation is different. A and B are quick wins and go first. C is a big bet with low confidence, so it becomes discovery work, not build work: interview ten nurses, or fake the suggestions by hand for one ward, before anyone commits four person-months. D is a money pit and gets parked with a note explaining why. E stays in the fill-in quadrant unless sales evidence shows it blocks deals. The prioritization matrix glossary entry covers the quadrants in more depth.

How do you scope the winning feature with MoSCoW?

Take the top item, the push alert, and split it into parts using MoSCoW: Must have, Should have, Could have, Won't have this time. The DSDM handbook from the Agile Business Consortium, which documents MoSCoW as part of the DSDM framework, defines a Must have as part of the "Minimum Usable SubseT" and sets a limit on how much of the work can sit there: "The safe percentage of Must Have requirements, in order to be confident of project success, is not to exceed 60% Must Have effort."

Priority	Scope item	Effort (days)
Must have	Alert when a posted shift matches the nurse's ward and qualification	8
Must have	Setting to turn alerts off	2
Should have	Quiet hours so nurses on nights are not woken	4
Could have	Daily email digest for nurses who turn push off	3
Could have	Alert preview showing pay grade of the shift	2
Won't have this time	SMS alerts	not estimated

Must haves come to 10 of 19 estimated days, about 53 percent, under DSDM's 60 percent line, and the 5 days of Could haves give the team room to absorb a slip without cutting anything essential. SMS is written down as Won't have this time rather than left unspoken, which stops it reappearing mid-sprint. The MoSCoW method entry has the category definitions.

Why does the order of the four steps matter?

Each step removes a kind of argument before the next one starts. With the North Star agreed, nobody can argue Impact against a private goal. With RICE scores on the table, disagreements become disagreements about a specific number ("is Reach really 4,000?"), which can be checked. The matrix separates the features that need evidence from the ones that need a decision. MoSCoW then turns one decision into a release the team can actually finish.

Running them in a different order produces predictable failures:

• MoSCoW across the whole backlog, before ranking, makes everything a Must have, because every requester defends their own item.
• RICE without a North Star turns Impact into whatever each scorer personally cares about.
• A matrix without scores places features by gut feel, which is the problem prioritization was meant to fix.

What is the strongest objection to a scored process?

The inputs are still guesses. A RICE score of 3,200 looks precise, but Reach and Impact are estimates, and two PMs can score the same feature an order of magnitude apart. The answer is not to drop the numbers but to use them for what they are good at: making assumptions visible so they can be tested. When a score flips the ranking, check the one input driving it. When Confidence is low, the next step is research, not a bigger debate. And when a stakeholder pushes a low-scoring feature, the table gives you a specific reason to say no that is about the numbers rather than about them.

Once the order is settled, put it where people can see it. A Now-Next-Later roadmap fits the output of this sequence well: the scoped push alert in Now, manager approval in Next, and the auto-suggest bet in Later until discovery raises its Confidence.

Where to practise prioritization on a real problem

Product Manager Foundations is a 2 week Builders Camp bootcamp with 4 live sessions, taught by Andre Albuquerque and part of the Product Management Starter Track. Prioritization and MVP thinking is one of its six published topics, described as using practical prioritization frameworks to scope an MVP and trade off value, effort and risk, and its practical challenge takes a problem you choose from problem statement through research, a PRD and a metrics framework with a North Star.

See the Product Manager Foundations bootcamp