Free tool

Feature request ROI calculator

Put a number on one request: the revenue behind the accounts asking, against the loaded cost to build it. Out come ROI, net value, and payback.

First-year ROI

74%

Value (yr 1)

$52,320

Build cost

$30,000

Payback

6.9 mo

Pays for itself in year one

Retained revenue is the soft spot. The formula treats requesting accounts' MRR as value at stake, which overstates the case when those accounts would stay anyway. Confidence is where that honesty lives; set it from evidence, not hope.
See the MRR behind every request Open the live demo

Rank the whole backlog by revenue →

The method

What the formula counts, and what it cannot.

Value is revenue-shaped. Retained MRR annualized plus expansion the change unlocks. Strategic value, platform leverage, and brand carry a zero here on purpose; score those elsewhere.

Cost is loaded. Person-months times the full cost of a person-month. Salary alone understates it; the loaded figure is what the roadmap actually spends.

Confidence does the honesty. A 90% on a request three named accounts asked for is different from a 90% hunch. Tie it to the evidence behind the request.

ROI ranks one request; the product prioritization framework covers the whole method, and turning feedback into product changes covers where the revenue inputs come from.

FAQ

Feature-request ROI questions

How do you calculate the ROI of a feature request?
Estimate the first-year value: the requesting accounts' combined MRR times 12 (revenue the feature helps retain) plus any expansion ARR it unlocks, discounted by your confidence. Subtract the build cost (effort in person-months times your loaded cost per person-month), then divide the net by the cost. Above 0% the request pays for itself in year one.

What is a loaded cost per person-month?
The full monthly cost of one engineer to the company: salary plus benefits, payroll taxes, tooling, and overhead. For B2B SaaS it typically lands between $12,000 and $20,000 per month depending on market. Using loaded cost instead of salary keeps the ROI honest; using salary alone understates the build cost by a third or more.

Should ROI decide which requests get built?
ROI is a tiebreaker and a sanity check, not the strategy. It treats retained revenue as value the feature secures, which overstates the case when those accounts would have stayed anyway, and it carries no strategic weight for platform work or new-market bets. Use it to rank comparable requests and to catch negative-ROI work early.

Where do the revenue inputs come from?
From billing data joined to the accounts that made the request. A feedback inbox knows what was asked but not what the askers pay; the join is what turns a vote count into an MRR figure. If gathering that number for one request takes more than a minute, the input pipeline, not the formula, is the thing to fix.

More free tools: revenue-weighted prioritization · RICE · WSJF · stack cost.

Want a copy you'll still have tomorrow?

Leave an email and we'll send your scored request back - value, cost, ROI and payback in one row you can paste into the roadmap review.

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