How to prioritise feature requests: six frameworks and a simple process

Prioritising feature requests means deciding which ones to build, in what order, and which not to build at all. There will always be more good ideas than time. A framework won’t make the decision for you, but it makes the decision fairer, faster and much easier to explain to customers and colleagues.

Before you score anything: start from problems and strategy

Two things make every framework work better:

1. Group requests by the problem they solve. Five different feature requests may all be attempts to fix the same problem. Prioritise the problem, then pick the best solution. See how to manage feature requests.
2. Know what you’re trying to achieve this quarter. Reducing churn, winning a new segment and growing usage lead to different priorities. A request that helps your goal beats a more popular one that doesn’t.

1. RICE

RICE was developed at Intercom to compare many ideas consistently. Each request gets four estimates:

• Reach: how many customers it will affect in a set period, such as a quarter.
• Impact: how much it helps each of them, on a simple scale (for example 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal).
• Confidence: how sure you are of the other estimates, as a percentage.
• Effort: how much work it takes, usually in person-months.

RICE score = (Reach × Impact × Confidence) ÷ Effort

For example, a request that reaches 800 customers a quarter, with high impact (2), 80% confidence and 2 person-months of effort, scores (800 × 2 × 0.8) ÷ 2 = 640.

Good for: comparing many requests with some data behind them. Watch out for: false precision. The scores are only as good as the estimates.

2. ICE

ICE, associated with growth marketer Sean Ellis, is a lighter version: score each idea from 1 to 10 for Impact, Confidence and Ease, then multiply or average the three.

Good for: quick decisions and experiments. Watch out for: scores that drift with the mood of whoever is scoring.

3. Value vs effort

Plot each request on a simple two-by-two grid: value to customers against effort to build.

	Low effort	High effort
High value	Quick wins: do these first	Big bets: plan carefully
Low value	Fill-ins: do when convenient	Time sinks: usually avoid

Good for: small teams and workshops, where everyone can see the trade-offs at once. Watch out for: everything drifting into “high value”.

4. MoSCoW

MoSCoW sorts requests into four groups for a release or deadline:

• Must have: the release fails without it.
• Should have: important, but the release still works without it.
• Could have: nice to include if there’s time.
• Won’t have (this time): explicitly out of scope.

Good for: fixed deadlines and agreeing scope with stakeholders. Watch out for: too many “musts”.

5. The Kano model

The Kano model, developed by Professor Noriaki Kano in the 1980s, sorts features by how they affect satisfaction:

• Basic needs: expected features. Missing them causes frustration; having them earns no praise.
• Performance needs: the more and better, the happier customers are.
• Delighters: unexpected features that create enthusiasm, but aren’t missed if absent.

Good for: balancing a roadmap so you cover the basics before chasing delight. Watch out for: delighters becoming basics over time, as customers’ expectations rise.

6. Weighted customer demand

Plain vote counts treat every voice the same. Weighted demand adds who is asking:

• Revenue: how much the customers asking for it pay, or could pay.
• Satisfaction: whether they are promoters or detractors in your NPS surveys. A request from unhappy customers at renewal may be more urgent.
• Segment: whether they are the kind of customer you want more of.
• Risk: whether any of them are threatening to leave without it.

Good for: B2B products where a few accounts carry a lot of weight. Watch out for: ignoring the long tail of smaller customers, and letting one big account set your roadmap.

Comparing the frameworks

Framework	Type	Best for	Effort to use
RICE	Score	Many requests, some data	Medium
ICE	Score	Quick calls, experiments	Low
Value vs effort	Grid	Small teams, workshops	Low
MoSCoW	Groups	Fixed deadlines	Low
Kano	Groups	Balancing the roadmap	Medium
Weighted demand	Score	B2B, account-heavy products	Medium

A simple process that works

1. Collect requests in one place, with the customers who asked attached.
2. Group them by the problem they solve, and merge duplicates.
3. Filter out anything that doesn’t fit your strategy, and tell those customers honestly.
4. Score what’s left with one framework, adding weighted demand if you’re B2B.
5. Decide as a team, using the scores as input rather than the answer.
6. Write down why, so you can explain the decision later.
7. Tell customers what you decided, and tell them again when it ships.

Common mistakes

• Building for the loudest voice, whether that’s a big customer, a senior colleague or the latest support ticket.
• Changing frameworks every month, which makes scores impossible to compare.
• Scoring once and never revisiting. Priorities change as customers, competitors and strategy change.
• Forgetting effort. A brilliant idea that takes a year may lose to three good ideas that take a month each.

How Qintr helps

Qintr Ideas collects requests on boards where customers vote and comment, with every request linked to the people and companies who asked. Because Ideas shares customers with Qintr Pulse, you can see whether the people asking are promoters or detractors. Priorities then rank open requests by votes, revenue asking and detractors asking, weighed against effort, and show why each score is what it is.