The short version
- A framework collapses several dimensions into one so a list can be sorted.
- Five frameworks over the same twenty requests, and eleven of them move ten places or more.
- Which framework is right is the wrong question.
- One input changes everything: whether a vote is a person or an amount of money.
A prioritisation framework is a rule for turning several numbers about a request into one number you can sort by. That's all it is, and saying it plainly makes the next part obvious. The framework doesn't decide anything. The choice of which numbers to feed it does.
Five frameworks were run over the same twenty requests to see how much that choice matters. The top item is different in three of the five, and one request moves nineteen places between two of them.
What does a prioritisation framework actually do?
It collapses several dimensions into one, so that a list can be sorted.
Every framework on this page takes some subset of four things, being how many people want it, what those people are worth, how much work it is, and how confident you are. Then it combines them with an arithmetic rule. The rule is the framework. The inputs are the decision.
There's a queue carrying those inputs if you want to see where they come from, and the demo is open without an account.
Doing this in a tool rather than a spreadsheet? Twenty one feature request tools and the eight units they bill on. The unit decides the bill, not the headline price.
The five, run over the same twenty requests
The dataset is twenty invented requests, each with a vote count, the monthly revenue of the accounts behind it, a reach, an impact, a confidence and an effort in person months. Every figure below is produced by a script in this repository and running it reproduces them.
| Framework | The rule | Its top pick |
|---|---|---|
| Raw votes | Sort by the number of people who asked | Dark mode |
| RICE | reach × impact × confidence ÷ effort | Tag colours |
| Revenue behind the request | Sort by the monthly revenue of the accounts that asked | Single sign on |
| Revenue per person month | Revenue ÷ effort | API rate limit increase |
| Weighted scoring | 40% revenue share, 30% vote share, 30% inverse effort | Dark mode |
Three different answers to "what should we build first" from the same twenty requests. Nobody changed the data between runs.
Where they disagree most
Eleven of the twenty requests move ten or more places between the best and worst framework for them. Two examples carry the whole argument.
| Request | Votes rank | RICE rank | Revenue rank | Revenue per effort | Weighted |
|---|---|---|---|---|---|
| Dark mode | 1 | 7 | 19 | 20 | 1 |
| Single sign on | 13 | 20 | 1 | 10 | 20 |
Dark mode is first by votes and twentieth by revenue per unit of effort. It carries 15% of all the votes on the list and 0.5% of the revenue.
Single sign on is first by revenue and twentieth by RICE. It has the most money behind it of anything on the list and it costs three person months, which is six times the median.
Those two rows are the same disagreement seen from both ends. One framework counts people and the other counts money, and on this list those two populations barely overlap.
So which framework is right?
Wrong question. The right one is which input you're willing to be wrong about.
| If you believe | Use |
|---|---|
| Every user counts the same | Raw votes |
| Revenue is the thing you are optimising | Revenue behind the request |
| You are capacity constrained above all | Revenue per person month, or RICE |
| You want a defensible blend nobody can game | Weighted scoring, with the weights published |
The blend isn't more correct than the others. It's more defensible, because the weights are written down and can be argued with, which is a different and sometimes more useful property.
What every framework is bad at
Inputs it can't see. A contractual obligation, a dependency, a thing that has to exist before three other things. None of the five knows about any of that.
Confidence. RICE has a confidence term and the other four have none, which means four of the five treat a guess and a measurement identically.
Being the answer. The output is a starting position. Its value is that nobody has to defend it socially, so the conversation becomes what to move and why, which is shorter and leaves a record.
The one input that changes everything
Whether a vote is a person or an amount of money.
Every disagreement in the table above traces back to that single choice. A list of requests where each vote counts one produces a different product from a list where each vote carries the revenue of the account behind it, and no arithmetic downstream can recover the difference.
How do you do this without a tool?
A spreadsheet with a column per input and a column per framework, so you can see all five orderings side by side. It takes an hour to set up once.
The input that's hard to fill in is the revenue behind each request, because it means knowing who asked and what they pay. Without it, four of the five frameworks above are unavailable and you're left sorting by votes.
How does this product do it?
A request carries the people who voted for it. Those people carry whatever you know about them, including the revenue on the account, so both populations are available, and the plain vote count and the weighted one sit beside each other, not one replacing the other.
Each card carries an effort estimate and a demand score, and the board can be ordered by the priority the two produce, which is the fourth framework above without the spreadsheet.
The revenue weighted voting page covers the weighting, and a RICE prioritisation example works one of the five through in full.
MoSCoW is the one of the five that needs no numbers at all.
14 days, a card at signup, then $9 or $39 a month.
