Roadmaps should rank features by revenue and retention impact per engineering pound — not loudness.
Conversion drivers, expansion hooks, and churn killers beat nice-to-haves. Quantify expected MRR or saved MRR before sprint planning.
It belongs in our saas metrics churn startup finance guide, alongside are product features worth the cost and why building more features hurts your business. Use the cost per feature calculator when you want to model your own numbers.
Revenue Impact
Not all features contribute equally to revenue. Some drive conversion — the feature or set of features that convinces a free user to pay, or a trial user to convert. Some drive expansion — features that enable or encourage users to upgrade to higher tiers or add more seats. Some drive retention — features that increase product stickiness and reduce churn. And some are table stakes — features that must exist to stay competitive but generate no incremental revenue on their own.
The highest-priority features to build are those in the first two categories: conversion and expansion drivers. They have a direct, measurable revenue impact that can be estimated in advance and measured after launch. Features that fix pain points for existing customers are valuable for retention, but their revenue impact is indirect (prevented churn) rather than direct (new revenue). Table stakes features are necessary but represent competitive maintenance, not growth investment.
To identify which features fall into which category, the most reliable method is to ask churned customers what they wish the product had done that it did not, and ask converted customers what specifically drove their decision to pay. These two data sources together reveal the features that matter most for the core revenue mechanics of the business. The Cost per Feature Calculator then helps evaluate whether the development investment to build those features is justified by their projected revenue impact.
User Value
User value and revenue impact are related but not identical. A feature can be highly valued by users and produce zero incremental revenue — it is used by customers who are already paying and who would not churn without it. Conversely, a feature can be mildly valued by most users but have a disproportionate impact on the specific user behaviour (conversion, upgrade, referral) that drives revenue.
User research — surveys, interviews, usability testing — measures perceived value. Behavioural data — feature adoption rates, correlation between feature usage and retention or conversion, A/B tests — measures actual impact on the outcomes that matter. Both are necessary, but the two frequently disagree in instructive ways.
A feature that users say they want and that correlates strongly with retention in usage data is a strong build candidate. A feature that users say they want but that has no measurable correlation with any revenue or retention metric in behavioural data should be deprioritised, regardless of the volume of requests. The loudest voices in feature requests are not always representative of the paying customer base, and paying customers' behaviour predicts revenue impact better than any survey.
Trade-Offs
Every feature is a trade-off in three dimensions: value, cost, and opportunity cost. The value is what the feature does for the business if it works as expected. The cost is the engineering, design, and maintenance investment. The opportunity cost is what else could have been built with the same capacity.
The trade-off framework forces specificity. "This feature will improve conversion" is not a prioritisation argument — it is a hope. "This feature addresses the most common reason churned customers cite for leaving, which at our current churn rate represents approximately £8,400/month in recoverable revenue, against a development cost of £22,000 and a payback period of 2.6 months" is a prioritisation argument. The difference is quantification.
Teams that habitually quantify impact estimates — even imprecisely — make better prioritisation decisions than teams that rely on qualitative assessment, because the quantification process forces the underlying assumptions to be made explicit and examined. An estimate of £8,400/month in recoverable revenue requires justifying where that number came from, which surfaces the assumptions and allows them to be challenged before the investment is made.
The final trade-off to make explicit: doing nothing. Every feature on the roadmap that does not get built is implicitly deprioritised in favour of what is built. Making the opportunity cost of each choice visible — "building Feature A means we do not build Feature B this quarter, which has an estimated revenue impact of X" — produces better resource allocation than an additive roadmap where everything is eventually planned without any explicit trade-offs between competing priorities.
Worked example: scoring two competing features
Feature A (SSO): 15% of churned accounts cited security; 3% monthly churn on £28k MRR → £840/month loss; SSO might cut churn 0.4% → ~£112/month saved; build £25k → long payback.
Feature B (usage alerts): trial conversion 12% → 14% on 400 trials/month at £49 ARPU adds ~£3,920 MRR/month if sustained; build £9k → payback ~2.3 months.
Team ships B first, time-boxes SSO discovery. Prioritisation by estimated £/month per £1k build changed the quarter outcome.
Check results in the churn impact calculator and see how to reduce churn increase retention for related guidance.
What to do next
- Interview churned and converted users for drivers.
- Estimate MRR impact ranges; be explicit about confidence.
- Use cost per feature calculator for payback.
- Publish ranked list with trade-offs visible.
- Review actual impact 90 days post-launch.
This article is for general planning and education — not professional financial, tax, or legal advice. Figures are illustrative; check current terms and your own numbers before acting.
Frequently asked questions
What if users shout for a non-revenue feature?
Weigh segment value; power users matter if they expand or refer, not only if they are loud.
How do we estimate impact?
Use past experiments, comparable features, or small tests before full build.
Should tech debt ever win?
When debt blocks revenue work or raises incident cost above feature ROI.
How many metrics should we track?
One primary per bet: conversion, expansion, or churn — not all three at once.
Do bugs outrank features?
Revenue-blocking bugs yes; cosmetic fixes compete on same scoring.