Every customer wants a different feature: how to prioritize a product roadmap

Prioritizing feature requests is not a scoring problem. It is a written rule that answers three questions: what evidence lets a request onto the roadmap, which budget it spends, and who signs off. Without that rule the list sorts itself by whoever asked loudest. There is data on where that ends up. Pendo's 2019 Feature Adoption Report, built from 615 subscriptions that had been using the product for over a year, found that roughly 80% of features in the average software product are rarely or never used. An older and much smaller sample, Jim Johnson's XP 2002 talk for the Standish Group, put the figure at 64%, and Mike Cohn points out that it came from four internally built applications and should not be generalized. The exact number is arguable. The direction is not: most of the code shipped goes into screens nobody opens.

Record the problem, not the request

Customers hand you solutions. "Add an export to Excel button." What belongs in your queue is not the button, it is the job behind it. What does the customer do with that file, how often, how do they cope today, and what breaks if they cannot? The answer is usually something like "I send accounting a monthly reconciliation list," and the cheaper fix is a filter on a report you already have.

Make the intake form ask for the right things: who asked (person and account), what job they are trying to do, how they handle it now, how often it comes up, what it costs them when it does, and which contract or renewal depends on it. Keep the suggested solution in a separate, optional field. Teresa Torres' opportunity solution tree makes the same distinction for a practical reason: one opportunity usually has several possible solutions, and you cannot pick the cheapest one unless the opportunity itself is written down.

Capacity buckets beat one ranked list

Put bugs, contractual commitments, customer requests and strategic bets in a single ranked list and the same side wins every time: whatever is urgent. Strategic work is never urgent this week, so it never reaches the top.

Split capacity into buckets at the start of the quarter instead. Some share goes to customer requests, some to product strategy, some to technical debt and maintenance, and some stays reserved for unplanned work and incidents. The ratios depend on your business; what matters is agreeing them in advance and writing them down. Each request then competes with the other requests in its own bucket rather than with the whole engineering team. Sales also gets a concrete answer to "why didn't this ship."

RICE turns opinions into numbers

Within a bucket, RICE is the common tool. Sean McBride's definition, published on the Intercom blog on 5 January 2018, goes like this. Reach is how many people the work affects in a given period, such as accounts per quarter, taken from real product metrics rather than a guess. Impact is the effect per person on a five-step scale: 3 for massive, 2 for high, 1 for medium, 0.5 for low, 0.25 for minimal. Confidence is how well your estimates hold up: 100% high, 80% medium, 50% low, with anything below 50% being, in McBride's words, a total moonshot. Effort is the total person-months from product, design and engineering. The score is Reach × Impact × Confidence ÷ Effort.

A worked example. Work that touches 400 accounts a quarter, with medium impact (1), medium confidence (0.8) and two person-months of effort, scores 160. Work that touches 40 accounts with massive impact (3), high confidence (1.0) and one person-month scores 120. Those two are close enough that the number will not decide anything, and that is the point. RICE converts "I think this matters more" into "how many accounts do you think it touches."

The weak link is Effort. If the person-month estimate is wrong the score is wrong, and it arrives with a decimal point attached, which makes it sound more reliable than it is. McBride says as much himself: RICE is not a hard-and-fast rule, and dependencies or table-stakes features can jump the queue on a lower score. If you want the estimate side to hold up, the probabilistic approach in our piece on software estimation applies here too.

When timing matters, use WSJF

RICE has no sense of time. Some work loses its value on a calendar: the campaign module that misses the season, the API that misses an integration partner's launch, the invoice field that misses a regulatory date. SAFe's WSJF handles that better by dividing relative cost of delay by relative job size. Cost of delay is built from three inputs: user and business value, time criticality, and risk reduction or opportunity enablement.

The formula has a side effect worth using deliberately. Small jobs rise, because the divisor shrinks. Splitting a large piece of work into genuinely separate slices therefore changes its priority, which is correct behaviour when the slices really can ship on their own and self-deception when they cannot.

Kano: requests are not all the same kind

In his 1984 paper, Noriaki Kano separated features by how they affect satisfaction. In the Kano model, must-be features cause real dissatisfaction when missing and earn nothing when present; one-dimensional features raise satisfaction in proportion to how well you deliver them; attractive features draw no complaints when absent and produce unexpected delight when there.

The prioritization consequence is simple. Do not score a must-be with RICE. You have to build it anyway, and scoring only delays the deal you are about to lose. Attractive features also migrate toward must-be over time. For enterprise buyers, single sign-on is the standard example: a differentiator five years ago, a mandatory line on the procurement checklist now.

When the date is fixed, use MoSCoW

On projects where the date is fixed and scope flexes, MoSCoW is more practical than a score. The Agile Business Consortium defines the four levels as follows. Must Have is the smallest usable set without which the project should be cancelled. Should Have is important but survivable, possibly with a workaround. Could Have is desirable, and it is the contingency pool that drops first when the date gets tight. Won't Have is agreed to be out of scope for this timeframe and recorded so it cannot creep back in informally.

The ratios are the valuable part. The same source recommends keeping Must Have effort to typically no more than 60%, with a Could Have pool of around 20% as contingency, since that 20% is what absorbs the schedule pressure. The common mistake is applying the ratio to the number of requirements instead of effort. Marking twelve of twenty items as Must protects nothing if those twelve carry 90% of the work. Setting this up while writing the requirements and before signing a fixed-price contract shortens the argument at the end of the project.

The one request from your biggest customer

This is the hard one. The account that carries a meaningful share of your revenue wants a feature nobody else has asked for. Saying no is risky, saying yes bends the product.

Keep three options distinct. If the need is genuinely general, it goes into the product and ships to everyone. If it is specific to that customer, it gets priced as paid custom development on its own line, with maintenance responsibility written into the support contract. If the difference in behaviour is small, configuration or a feature flag scoped to one tenant will do. There is a fourth path to avoid: a conditional in the code with a customer name in it. In a multi-tenant architecture that bill arrives a few releases later, as a file nobody is willing to touch.

Have a written way of saying no

The worst way to handle a rejected request is silence. The customer sends it, hears nothing, and raises it again three months later in a sales call, this time as a complaint.

Give the answer three parts: the decision (not now), the reason (what it could not get ahead of), and what would change it (how many more customers asking, or what data arriving, triggers another look). "Not now" with a written reason lands far better than a flat no. Keeping the request log where customers can see it cuts down on repeat questions, though only if you keep it current. A request board that has not been touched in six months sends a worse signal than having none.

A roadmap is not a list of dates

The moment you publish a roadmap as a table of quarters, every estimate on it becomes a commitment. That is why the Now / Next / Later format popularized by ProdPad co-founder Janna Bastow works: ProdPad's own roadmap puts problems with a defined solution and committed resources in Now, problems still in discovery or design in Next, and ideas still taking shape in Later. Uncertainty grows as items move out, and the format says so without anyone having to add a disclaimer.

Some dates are unavoidable: an integration partner, a trade show, a regulatory deadline. For those, give a range rather than a single day, and write down the assumptions it rests on.

Measure after you ship

The step most often skipped is checking whether the decision was right. The first item on John Cutler's 2016 "feature factory" list was exactly this: a team that does not measure what it ships is working in one.

A cheap rule covers it. Before development starts, every feature ticket gets a success measure and a review date. Something like "more than 20% of active accounts use this within eight weeks." Measuring it depends on the event tracking being in place, which is the groundwork covered in our piece on product analytics. If your traffic is too low for a comparative test, the alternatives in the A/B testing piece apply. When the review shows adoption far below expectation, you have two honest options: find out why and try once more, or remove the feature. The third option, carrying a screen nobody uses forever, comes back as test and maintenance cost in every release.

What you can do this quarter

• Change the intake form: make the solution field optional, and make "how do you handle this today" and "what does it cost you" required.
• Split capacity into buckets and write the ratios down, so customer requests, strategy, maintenance and unplanned work stop competing in one list.
• At the next planning session, score the top ten requests with RICE and record the discussion rather than the ranking.
• Write a three-part template for declined requests, and use it to close out everything that has gone unanswered in the last six months.
• Attach a success measure and a review date to every feature going into the next release, and put that date in the calendar as a meeting.