Feature prioritization: requests, priced in retention

Feature prioritization is deciding which requests make the next release and which ones wait. In most SaaS teams the requests arrive from three directions at once: sales brings what a prospect asked for in the demo, support brings what customers complain about, and marketing brings what the next campaign needs. Each team is right about its own customers, and none of them uses the same unit.

Without a common price, the loudest request wins: the one repeated in the most meetings, or brought by the most senior person in the room. The common price is already in the billing data. A request is worth the retention of the customers asking for it: how many of them there are, how much faster they leave than everyone else, and what each one pays.

Feature prioritization decides which requests ship next. Frameworks like RICE score reach, impact, confidence and effort, but not who is asking. Pricing a request in retention adds that: customers asking × how much faster they churn than the base × ARPU × 12 gives the ARR lost for every month the request waits.

Key takeaways

• Without a common price, feature prioritization goes to the loudest request, not the one worth the most.
• RICE scores reach, impact, confidence and effort, but reach counts people, not which people are asking.
• Request value = customers asking × churn gap × ARPU × 12: the ARR lost for every month the request waits.
• On the example product, 40 customers churning at 7 of every 100 against the base 4 make a request worth €864 of ARR a month.
• Retention, expansion and acquisition requests each need their own price, and the cancellation reasons confirm the gap.

How feature prioritization usually works

The requests are rarely the problem; there are always more than a release can hold. Savio, which builds a tool for tracking them, recommends collecting feedback from "sales, support, customer success, and any other teams that talk directly to your customers," not only from surveys sent by product.

To turn that list into an order, many teams use a scoring model. The best known is RICE, published by Intercom in 2018:

RICE score = (Reach × Impact × Confidence) / Effort

Reach is "how many people will this impact?" within a period. Impact is a guess on a five-step scale, from massive (3) to minimal (0.25). Confidence discounts the guess, from high (100) to low (50). Effort is counted in person-months. Intercom built it against a familiar bias: "It's satisfying to work on pet ideas you'd use yourself, instead of projects with broad reach."

RICE fixes the pet ideas. It does not say who is asking. Reach counts people, and a request from 40 customers who are about to leave scores the same as one from 40 customers who would stay anyway. Savio points the same way: rank requests by customer value, and when the goal is reducing churn, give weight to feedback from churned and at-risk accounts.

Feature request prioritization, priced in retention

The missing unit is what the customers asking are worth if they leave. Billing already knows it. Group the accounts behind each request, measure how many of them cancel each month, and compare it with the churn of the whole base:

Request value = customers asking × churn gap × ARPU × 12

The churn gap is their monthly churn minus the base churn. The result is the annual recurring revenue lost for every month the gap stays open, which is every month the request waits, if the request is what explains the gap.

The formula, worked on one product

Take the product used across this blog's SaaS posts: a subscription tool for creative businesses such as studios, academies and photographers, with 1,100 paying customers at €60 a month, the base worked out in the SaaS pricing strategy post. It loses 4 of every 100 customers a month, 44 in all, so its customer retention rate is the number every request should be judged against.

Two requests are on the table this month (the split is a declared example):

Request	Brought by	Customers asking	Their monthly churn	Gap vs the base	Retention value
Bulk class scheduling	support	40	7 of every 100	3 of every 100	€864 of ARR a month
Calendar integration	sales and support	60	4 of every 100	0	€0

The integration is the louder request: more customers ask for it, and sales repeats it in every demo review. Their churn is the base churn, so in retention it is worth nothing. Its value, if it has one, is in new contracts, and it needs its own price there.

The scheduling request is quieter and costs real money. The 40 academies asking for it lose 7 of every 100 a month against the base 4, so 40 × 3 ÷ 100 = 1.2 more customers leave every month:

1.2 customers × €60 × 12 = €864 of ARR for every month the gap holds

A quarter of waiting is 3.6 customers and €2,592 of ARR, on a product that adds and loses 44 customers a month.

The gap measures who leaves, not why. Before believing that the feature closes it, read the cancellation reasons of the accounts that left from those 40. If they mention scheduling, the price stands; if they mention something else, the request is a symptom, and the money is in the other reason.

Pricing every open request in the retention of the customers asking for it, on your own billing data, is part of what The Activation Audit maps.

Where the price fits in a feature prioritization framework

The retention value does not replace a framework; it replaces the guess in it. Keep the effort from RICE as the denominator and divide: the scheduling request at €864 a month and two person-months of work is €432 of ARR per person-month, and it can now be compared with any other retention request on the same scale.

Not every request is a retention request. Each kind needs its own price, so that a vague score is never compared with a number in euros:

• Retention: customers asking × churn gap × ARPU × 12, as above.
• Expansion: customers who would move up a plan × the price difference × 12.
• Acquisition: prospects who asked × the share that closes × ARPU × 12.

The three prices answer to the same top number. A request that moves none of the inputs of the product's north star metric is a request to say no to, however loud it is.

What to do before the next release

1. Export the open requests with the account that asked for each one, whatever the channel: support tickets, sales notes, the feedback board.
2. Mark which of those accounts are still paying, and calculate the monthly churn of each request's group against the base.
3. Price each request with the formula, divide by effort, and bring the sorted list to the planning meeting.

What to do this week: take the three requests repeated most often in the last month. Count the customers behind each, look up how many of them cancelled in the last 90 days, and multiply the gap by your ARPU and by 12. If the loudest request comes out last, that is the conversation to have with sales.

Work through this with your own numbers

My SaaS product has [paying customers] paying customers at [ARPU] a month and loses [base churn] of every 100 each month. Here are my open feature requests, with the accounts that asked for each one and how many of those accounts cancelled in the last [months] months: [list]. For each request, calculate the monthly churn of its group, the gap against my base churn and the ARR lost for every month it waits (customers asking times the churn gap times ARPU times 12). Then divide by the effort in person-months I give you, sort the list, and tell me which requests are really expansion or acquisition requests that need a different price.

FAQ

What is feature prioritization?

Feature prioritization is deciding which product requests go into the next release and which wait. Requests come from sales, support, marketing and the product team itself, so the hard part is not the list but a common unit to compare them in.

What is the best feature prioritization framework?

RICE, published by Intercom, is a widely used scoring model: reach times impact times confidence, divided by effort. Its weak spot is that reach counts people, not which people. For requests that affect retention, replace the guessed reach and impact with the recurring revenue at stake and keep effort as the denominator.

How do you prioritize feature requests from customers?

Group the accounts behind each request, compare their monthly churn with the churn of the whole base, and multiply customers asking by the churn gap, by ARPU and by 12. The result is the ARR lost for every month the request waits. Then read the cancellation reasons to confirm the request is what explains the gap.

Should the most requested feature always be built first?

No. The most requested feature can come from customers who stay anyway, while a quieter request comes from the accounts that are leaving. On the example product above, the request 60 customers asked for is worth nothing in retention, and the one 40 asked for is worth €864 of ARR a month.

Pricing your open feature requests in the retention of the customers asking for them, and lining them up for the next release, is part of what The Activation Audit maps. Five business days, $500, and the map stays with you whether or not you hire anyone next.