Feature prioritisation is deciding which of the things you could build you will build next, and in what order.
Every framework for doing it is a formula, and every formula multiplies numbers somebody typed in. The argument in the room is almost never about the arithmetic. It is about whether those numbers were measured or invented, and most frameworks do not make you say which.
That is the whole subject. This page is about where the inputs come from.
What is feature prioritization?
Feature prioritization is deciding what to build next, and writing down the reasoning in a form somebody else can check. The frameworks differ in what they ask you for, not in what they do with it.
RICE asks for reach, impact, confidence and effort. Weighted scoring asks for a list of criteria and a weight for each. Cost of delay asks what a month of waiting costs. MoSCoW asks you to sort four buckets. All of them end in a number you sort on.
The formulas are simple enough that nobody argues about them. What people argue about is a five that somebody wrote down as an eight.
If the definition is easier to see than to read, the demo board is open with no account and no email.
Why do the frameworks disagree so much?
Because they weight the same guesses differently, and most of the guesses are about a future nobody has seen.
Take RICE. Three of its four inputs are predictions. Reach is how many people will hit this in a quarter, impact is how much it will move them, and confidence is your own estimate of how wrong the first two are. Only effort has any chance of being grounded, and it is an estimate too.
That is a description of what RICE costs to run rather than an attack on it. A framework built on four predictions produces a number that carries four errors, and multiplying them does not cancel anything out. It compounds.
The useful question is which inputs you could stop predicting, because you already have them.
Which inputs can you actually measure?
Four of them, if the requests live on a board people can reach. Votes, comments, views and the revenue behind the voters.
None of those is a forecast. A vote happened. A comment happened. A view happened. Somebody with a subscription clicked a button, and you can look up what that subscription is worth.
The reason a public board changes prioritisation is not that it is democratic. It is that it converts three predicted inputs into three counted ones.
Our own board turns them into one number. Demand is votes times three, plus comments times two, plus views times zero point one, with the fraction dropped. Priority is that demand divided by effort, and it stays at zero until somebody sets an effort, because dividing by nothing is not a ranking.
Effort is the invented input, and we have not hidden that. It is a five step picker rather than a text field, XS through XL, labelled a few hours, a few days, about a week, a few weeks, and a month or more.
A range is an honest way to write a guess. A decimal is not.
There is no field for impact and no field for confidence anywhere on a request. That was a decision.
A number you cannot check is a number that will be argued about with more confidence than it deserves, and we would rather the board carry four counts and one admitted estimate than six figures of mixed provenance.
How does revenue change the ranking?
It replaces headcount with money, and it is the one input that changes which request wins rather than by how much.
With weighted voting switched on, the demand formula reads the weighted vote total instead of the raw count, so the same three multiplier now sits on top of whatever multipliers your tiers carry. Twelve free accounts and three enterprise ones stop looking the same.
The revenue view goes further and sums real money per request. For each request it adds up the monthly revenue of every voter who has been assigned to a tier, and counts how many distinct voters that is.
Read that sentence twice, because the caveat is inside it. A voter with no tier assignment contributes nothing to that sum and is not counted. If half your voters have never been mapped to a tier, the revenue behind every request on that screen is understated, and it is understated unevenly.
We show you how badly. The same screen reports tier coverage, which is assigned voters divided by total voters.
It exists because a revenue ranking read at forty percent coverage is a different document from the same ranking at ninety, and the number that tells you which one you are looking at should not be buried.
One more limit worth knowing. That rollup only lists requests that have at least one vote. A request nobody has voted on has no revenue behind it by definition, so it is not missing from the screen, it is absent from the question.
What does this get wrong?
Two things, and both are about who is in the room rather than about arithmetic.
The first is that counting what happened only counts people who showed up. A board measures the customers who found the board. That is a real bias with a real name, and vocal minority bias is worth reading before you treat a vote total as a survey.
The second is that measured inputs make a number feel more solid than it is. Demand is precise. It is not the same as important.
A request with four hundred demand and no path to revenue still loses to one with eighty and a renewal attached, and no formula on this page will tell you that. The formula narrows the argument. It does not end it.
So the honest claim is narrow. Prioritisation gets better when fewer of its inputs are invented, and a board moves three of them from the guess column to the count column. The remaining guesses are still yours.
How to do feature prioritization, and what are the feature prioritization techniques?
Seven techniques worth knowing, and four steps that work whichever of them you pick.
Each one below gets a sentence and a link to the page that works it over the same twenty request board, so you can see what it does rather than read what it claims.
RICE, simple prioritization for product managers
Reach times impact times confidence, divided by effort. It is the arithmetic most teams reach for first and it is only honest when the reach number came from somewhere real.
Weighted scoring. Criteria you choose, weights you set, a score per request. The honest default, because it makes you write down what you actually care about before you rank anything.
MoSCoW. Must, should, could and will not have. Worked over twenty requests it shows its own trap, which is that the third letter absorbs everything nobody wants to argue about.
The Kano model. Sorts features by how satisfaction responds to them rather than by order. It settles a different argument, being what kind of thing a feature is.
Cost of delay. What a week of not having it costs. The one that reframes the queue when everything looks equally urgent.
Jobs to be done. Why somebody would hire the product at all. A frame rather than a ranking, and it answers questions an order cannot.
Revenue weighted voting. A vote that carries the weight of what the voter pays. It is the one this product runs, and the argument for it is that headcount and money disagree on almost every board.
The four steps, whichever technique you picked. Collect the requests in one place people can reach. Wait a fortnight before ranking anything. Set an effort on the top fifteen, which is an hour of work. Then run your technique and read the order against the plain vote count, because the gap between those two orders is where the decision actually lives.
How do you start prioritising this week?
Put the requests somewhere people can vote, and leave them a fortnight before you rank anything.
The first fortnight is not for the ranking. It is for finding out which requests attract votes from customers you have never heard from, which is the part a spreadsheet cannot produce however carefully you fill it in.
Then set an effort on the top fifteen, which takes about an hour and is the only manual input the board asks for. After that the ordering maintains itself, because the counts keep counting.
If you want to sketch the shape before you publish anything, the roadmap template on this site ships as a CSV with the effort and priority columns most templates leave out, and it uses the same formula this page describes.
A two by two matrix with six of those requests already placed in it is the other file, for when the argument is about quadrants rather than about an order.
14 days, a card at signup, then $9 or $39 a month.
What are some prioritization mistakes to avoid?
Four, and the first one is why the other three survive.
Treating the score as the decision. A score is a sort order. A team that says the score says has stopped naming the person who chose, and nobody can argue with a formula the way they can argue with a colleague.
Counting heads when heads are not what pays the bill. On the demo board the five most voted requests hold under a fifth of the weighted total, so the two orders disagree about what comes first. Five methods run over the same twenty requests is where that arithmetic is worked.
Predicting an input you already hold. Reach is the clearest case, because the votes are sitting on the board already and a forecast of them is a guess at a number you can read.
Setting no effort at all. Priority on our own board stays at zero until somebody picks one, which is a refusal to rank rather than a defect.
Which framework should you pick?
Whichever one you will still be running in three months, which in practice is the one with the fewest fields.
If you are choosing between them, weighted scoring is the honest default because it makes you write your criteria down, and RICE is worth it only when you genuinely have reach data.
When the argument is about what kind of thing a feature is rather than where it sits in an order, the Kano model is the one that settles it, and when it is about what a week of waiting costs, cost of delay is.
When the argument is about why somebody would hire the thing at all rather than where it sits in a queue, jobs to be done is the frame that answers it, and once the list of things you could build has outgrown a page, an opportunity solution tree is how the branches stay attached to an outcome.
Running RICE on invented reach is a spreadsheet that launders a hunch into a decimal.
And whichever you pick, keep the product backlog smaller than you want to. A prioritised list of four hundred items has not been prioritised. It has been sorted.