Free tool

Revenue-weighted prioritization calculator

Score any feature by the money behind it: the requesting accounts' MRR, the expansion it unlocks, your confidence, and the effort to build. The output is ARR at stake per person-month.

ARR at stake per person-month

$26,160

Medium leverage

Where it lands

low medium high
The score is only as real as the MRR figure. If the revenue behind each request comes from a quarterly spreadsheet join, the ranking drifts as fast as the spreadsheet. On a spine, the request already carries its accounts and their MRR, so the score is a query, not a project.
Get the join, skip the spreadsheet Open the live demo

What revenue-weighted prioritization means →

The method

Three revenue lenses, one score.

Retained. The MRR of the accounts asking. If they churn unheard, this is what walks out; it is the floor of the score.

Expanded. ARR the change unlocks: an upsell blocked on a missing capability, a deal in the pipeline that names it. Enter 0 when it is a guess.

Discounted and divided. Confidence keeps a hopeful estimate from beating a certain one; effort makes the unit comparable across items of any size.

The full method, including when revenue should NOT decide, is in the product prioritization framework. Scoring by formula instead? Run the same items through the RICE calculator or the WSJF calculator and compare the rankings.

FAQ

Revenue-weighted scoring questions

What is revenue-weighted prioritization?
Revenue-weighted prioritization ranks candidate work by the actual revenue of the accounts behind each request instead of raw vote counts. The three lenses are revenue retained (accounts asking that might churn), revenue expanded (upsell the change unlocks), and revenue at risk if nothing ships. It turns 'lots of people want this' into 'accounts worth $4,200 MRR want this.'

How do you calculate a revenue-weighted score?
This tool computes annual revenue at stake per person-month: add the requesting accounts' combined MRR times 12 to any expansion ARR the change unlocks, multiply by your confidence, and divide by effort in person-months. Score every backlog item the same way and rank. The unit is dollars of ARR at stake per month of build time, so the number is meaningful on its own.

Where do the revenue numbers come from?
From your billing system, joined to the accounts that made each request. That join is the hard part: a feedback inbox knows what was said but not what the account pays. If you are reading MRR off a spreadsheet lookup per feature, the calculator still works, but the maintenance cost is why most teams fall back to vote counts.

Should revenue decide the whole roadmap?
No. Revenue weighting is a tiebreaker and an evidence layer, not a strategy. Platform work, developer experience, and bets on a new market often carry no attributable revenue yet and still deserve capacity. Use the score to settle backlog ties and defend the ranking, under a strategy that decides which market you serve next.

More free tools: RICE · WSJF · stack cost · churn.

Want a copy you'll still have tomorrow?

Leave an email and we'll send your scored list back - every item with its MRR at stake, expansion, confidence and effort, so the ranking survives the roadmap review.

The tool stays free and needs no account - this is only so the result outlives the tab.