Feature prioritization: five frameworks on one list of requests

Feature prioritization is deciding which feature requests to build first when there are more good ideas than time. There are dozens of frameworks for it, and most guides describe each one with its own made-up example, so you never see two of them disagree. This guide does the opposite: five frameworks, one list.

The list is twelve requests for Plant Diary, a made-up plant care app, the same one used in the guides to each framework. Each section below says what the framework asks, what it decided for that list, and links to the full guide.

The short answer

Use MoSCoW when a release has a fixed date and too much to fit, RICE when you need a strict order, the Kano model when you can't tell a basic from a nice extra, an impact effort matrix for a quick first sort, and votes from paying users when revenue decides. Most teams end up combining two of them.

The list: twelve feature requests

Eleven requests from Plant Diary's feedback board, each with its votes from the last quarter, plus one bug from support. Every item has a rough estimate in days of work.

MoSCoW: what ships by the date

MoSCoW sorts everything into Must have, Should have, Could have and Won't have this time, and keeps the Musts under 60% of the work. With 40 days for version 2.0, three Musts survived the question "would we cancel the release without it?": the double reminders fix, watering intervals and sync, which had been announced. The widget, fertilizer reminders and dark mode became Shoulds. Plant ID by photo, despite 33 votes, became a Won't, because 20 days would eat half the release.

Good at fitting a release to a date and saying no out loud. Weak at ordering anything inside a bucket. Full walkthrough: MoSCoW prioritization.

RICE: a strict order

RICE multiplies reach, impact and confidence, then divides by effort. With votes as reach, watering intervals scored 256, far ahead of the widget at 81.6, sync at 75.2, plant ID at 49.5 and dark mode at 38. Sync came in below the widget, because the formula knows nothing about the promise that made it a Must.

Good at turning a long list into one ranking. Weak at commitments, dependencies and anything the four numbers can't hold. Full walkthrough with a calculator: RICE prioritization.

Kano model: what kind of want

The Kano model asks users how they would feel with a feature and without it, and sorts the answers into must-be, one-dimensional, attractive and indifferent. In a survey of 120 voters, reminders that fire once and dark mode came out must-be, watering intervals one-dimensional, the widget and plant ID attractive, and CSV export indifferent.

Good at spotting a missing basic that a score underrates, like dark mode. Weak at cost, which it ignores. Full walkthrough with an evaluator: Kano model.

Impact effort matrix: a quick first sort

Two rough scores, impact and effort, put every request into one of four boxes. With votes as impact and lines at 30 votes and five days, the quick wins were the widget, fertilizer reminders and dark mode, ten days of work in total. Watering intervals, sync and plant ID were big bets, and the Apple Watch app was the only money pit.

Good for a first pass in an hour. Weak wherever effort is underestimated, which is most places. Full walkthrough with a template: impact effort matrix.

Votes from paying users: demand weighted by revenue

Raw votes count every voice the same. For a business, the people who pay are worth hearing twice, so the fifth method counts what the voters for each request pay. Plant Diary Pro costs $2.99 a month. Adding up the subscriptions of everyone who voted gives each request a revenue figure:

The order changes a lot. Sync jumps to first place, because two out of three people who asked for it pay, mostly people with an iPhone and an iPad. Sharing with a partner climbs from ninth by votes to third: households pay for one subscription and want to use it together. Dark mode falls from fifth to eighth, since most of its voters are on the free plan.

Watch the caveats. Free users today are paying users next year, so revenue alone starves growth. One large customer can outweigh a hundred small ones. And a new paid feature can't show demand from customers you don't have yet. Use revenue as a tiebreaker or as a second column next to votes, not as the only number.

Five frameworks, five answers

Here are the five requests that appear in almost every guide, side by side. The paid votes column shows each request's revenue figure and its rank among the eleven requests.

• Watering intervals is the one request every framework rates highly. When five methods agree, there is nothing left to discuss. Build it.
• Dark mode gets the most mixed verdicts: last in RICE, a must-be in Kano, a quick win on the matrix, eighth by revenue. Cheap and expected beats a low score. Ship it in the next release.
• Sync is a Must, first by revenue and a big bet. Paying customers want it and it was promised, so it gets planned even though RICE ranks it third.
• The widget delights the people who use widgets and is a quick win, but paying users care less. A good fill for a release, not the headline.
• Plant ID is attractive and expensive. The frameworks that look at cost put it behind cheaper requests. It waits for a release that can afford 20 days.

Which one to use when

The picker at the top of this guide, in words:

• MoSCoW when a release has a fixed date and the list doesn't fit. It decides what ships and what waits.
• Kano model when you can't tell whether people expect a feature or would love it. It costs a survey, so use it for the close calls.
• Impact effort matrix when you have an hour and a long list. It sorts, it doesn't rank.
• Votes from paying users when revenue decides the roadmap, as it does for most products that sell subscriptions.
• RICE when you need a strict order and can estimate reach, impact, confidence and effort for every item.

Combining frameworks

The frameworks answer different questions, so pairs work well:

1. MoSCoW, then RICE. MoSCoW decides what must ship. RICE orders everything below the Musts.
2. Impact effort, then Kano. The matrix sorts the whole list in an hour. A Kano survey settles the few requests near the lines.
3. Votes plus revenue. Keep both columns side by side, and act when they agree. When they disagree, like sync and dark mode here, say which one wins and why.

Collect votes and revenue in one place

Every framework above starts from the same input: a list of requests with an honest measure of demand. Votes give you that measure without a meeting, because users post ideas and vote on each other's, and the count is there when you sit down to prioritize. A feature request template makes sure each request also arrives with the problem behind it and a way to reply.

WishKit collects those votes on a feedback board for websites and SaaS products, and inside iOS apps with a native SDK. If your iOS app tells WishKit what each user pays, with WishKit.updateUser(payment:), the list of upvoters on every request shows each voter's monthly revenue next to their name.

Frequently asked questions