Blog · October 22, 2026 · 8 min read

Prioritize Feature Requests by Revenue With One Formula

A feature request prioritization framework that weighs votes by MRR, splits expansion from retention revenue, and adds momentum and effort.

Most feature boards rank requests by vote count. It is the easiest number to collect and the easiest to defend in a meeting. It is also the number most likely to send your team in the wrong direction.

This post gives you a scoring formula you can run in a spreadsheet this week. It weighs votes by the accounts behind them, splits the revenue at stake into expansion and retention, rewards requests that are rising, and divides by effort. There is a worked example with five made-up requests, a list of traps, and a free template at the end.

Why raw vote counts mislead

A vote count answers one question: how many people clicked a button. It says nothing about who they are.

Here is what hides behind a big number:

• One account, many votes. Twenty people at the same customer voting for the same thing is one account's ask. It looks like twenty.
• Free users. A free tier can outvote your paying base on any request that free users care about. That is useful to know, but it is a different signal from paying demand.
• Old asks. A request with 300 votes collected over three years may have peaked long ago. A request with 30 votes, 25 of them this month, is the one moving.
• Effort. Votes never tell you that one request is a two-day job and another is a quarter of work.

Votes still matter. They just belong inside a score, as one input among several.

The scoring formula

The formula has four parts. Each one fixes one of the problems above.

1. Demand: unique voters plus companies

Count unique voters, then add a bonus for each distinct paying company among them.

Demand = unique voters + 2 × paying companies

The company bonus rewards breadth. Ten voters from ten companies beat ten voters from one company. If you track anonymous votes, count them at half weight, since you cannot tell who they are.

2. Revenue at stake: expansion and retention

Revenue at stake is the monthly recurring revenue (MRR) of the companies asking. Count each company once per request, however many of its people voted. Then split it in two:

• Expansion MRR: revenue you could gain. Upsells blocked by the missing feature, deals in the pipeline that named it, accounts that would move up a plan.
• Retention MRR: revenue you could lose. Accounts that asked for it and are renewing soon, unhappy, or have said they will leave without it.

Retention gets double weight. The money is already on your books, and losing it costs you twice: the revenue and the reference.

Revenue points = √(expansion MRR + 2 × retention MRR)

The square root matters. Without it, one $10,000 account outweighs everything else on the board. With it, $10,000 is worth 100 points and $2,500 is worth 50. Big accounts still count more, just not without limit.

3. Momentum: last 14 days against the 14 before

Momentum = votes in the last 14 days ÷ votes in the prior 14 days

Use 1 as the floor of the denominator so a brand-new request does not divide by zero. Then clamp the result between 0.5 and 2. A request that went from 0 votes to 12 is interesting, but it should not jump over everything on a single good week.

4. Effort: a 1 to 5 scale

Ask the team that will build it. Keep the scale coarse:

The full score

Score = (Demand + Revenue points) × Momentum ÷ Effort

In a spreadsheet, with voters in B, paying companies in C, expansion MRR in D, retention MRR in E, votes last 14 days in F, votes prior 14 days in G and effort in H:

=ROUND((B2+2*C2+SQRT(D2+2*E2))*MIN(2,MAX(0.5,F2/MAX(1,G2)))/H2,1)

That formula works as written in Google Sheets and Excel.

A worked example

Five hypothetical requests on a hypothetical B2B board. Every number here is made up to show how the formula behaves.

Ranked by votes alone, the order is Dark mode, Custom portal fonts, Slack integration, CSV export, SAML SSO.

Now the scores:

What changed and why:

• CSV export goes from fourth to first. Twenty paying companies asked, $2,500 of it is retention, and it is a one-day job. Broad and cheap is a strong combination.
• SAML SSO goes from last to third. Only 18 voters, but $10,000 of MRR sits behind it and interest doubled in two weeks. Effort 4 keeps it from taking the top spot.
• Dark mode drops from first to fourth. Lots of voters, few of them paying, and the votes are slowing down.
• Custom portal fonts falls to last. No revenue behind it and momentum is fading.

The score does not decide for you. It tells you which conversation to have first. If your sales team says SAML SSO is blocking a signed deal, you now have a number to argue with instead of a feeling.

The traps

Over-weighting big accounts

The square root is there for a reason. If you remove it, your roadmap becomes your largest customer's wish list. That feels safe until the rest of the base notices. If one account still dominates, look at how many other companies asked for the same thing. One company is a custom-work conversation, and five is a product decision.

Ignoring free users, or only listening to them

Free voters still count in demand. They just bring no revenue points. That is the right default for most B2B products. If free users are your growth engine, give them a separate demand column instead of letting them drown out paying accounts in the same one.

Duplicate requests

"Export to CSV", "Download as spreadsheet" and "Excel export" are one request split three ways. Each copy looks small, and none of them makes the top ten. Merge duplicates before you score, and move the voters onto one request, or the formula will under-rank the things people want most.

Loud channels

A request that came up in a sales call, a support ticket and a Slack thread from the same customer counts as one ask. Log it as a vote from that customer on the existing request. Do not let whoever talks to the product team most often get counted most often.

Stale MRR

If the MRR column was filled in six months ago, the revenue points are fiction. Pull it from billing, or the score will rank accounts that have since churned or grown.

Running it weekly in a spreadsheet

You can do this with a spreadsheet and thirty minutes a week.

1. Export your requests. One row per request: title, unique voters, and the list of companies that voted.
2. Join MRR. Look up each voting company's MRR in your billing export. Sum it per request, counting each company once.
3. Split the revenue. Mark accounts renewing in the next 90 days, or flagged at risk by customer success, as retention. Put the rest under expansion.
4. Count the two windows. Votes in the last 14 days and the 14 days before. Your board's export needs vote dates for this.
5. Fill in effort for anything near the top that is not sized yet.
6. Sort by score and bring the top five to your planning meeting.

The slow part is steps 1 to 4. Joining voters to companies and companies to billing by hand is where spreadsheets break, and where most teams stop doing this after a month.

Get the free feature request prioritization scorecard with the formula already in place and three example rows.

How TheyAsked does it automatically

TheyAsked keeps these numbers on every request as votes come in, so there is no weekly join.

• Demand is identified voters, plus half for anonymous voters, plus 2 for each unique company.
• Revenue at stake is the MRR of the distinct companies voting, each counted once per request. You send company, plan and MRR in the SSO token or sync accounts from your backend through the API.
• Momentum is votes in the last 14 days over votes in the 14 days before.
• Opportunity blends demand, revenue, momentum and critical votes into one 0 to 100 score, and shows the points behind it so it is never a black box.
• Renewal risk flags accounts renewing within 90 days or with poor health, and the revenue view shows how much of each request's MRR is at risk or already churned. That is the retention half of the split above.
• Effort is a 1 to 5 field on each request, used for the quick-wins and big-bets quadrants and for RICE.

You can filter any of it by plan, so "what do Enterprise customers want" is one click. Every view exports to CSV if you still want the spreadsheet. See how it works on the prioritise by revenue page.

Sending MRR uses SSO or the API, which start on the Pro plan. Prices are on the pricing page.

Start a free TheyAsked workspace and see your requests ranked by the revenue behind them. New workspaces get a 14-day Pro trial.

FAQ

Should I weight votes by MRR or by number of companies?

Use both. Company count measures breadth across your customer base, and MRR measures money at stake. A request with high MRR from one company and a request with modest MRR from twenty companies need different conversations.

Why weight retention MRR more than expansion MRR?

Retention revenue is already yours, and losing it is more certain than winning new expansion. Double weight is a starting point. If your business is mostly driven by upsells, lower it.

How often should I recalculate feature request scores?

Weekly is enough for most teams. Momentum uses 14-day windows, so a weekly run catches a rising request within one or two cycles.