Feature Prioritisation Frameworks for App Teams

Every app with users has more requests than time. A hiking app hears about offline maps, trail filters, elevation charts and sharing in the same week, and a team of two can build perhaps one of them well this quarter. A prioritisation framework will not make that choice for you. What it does is make the choice explicit, so you can explain it, argue about the inputs instead of the conclusion, and revisit it when the numbers change.

This guide works seven frameworks through one backlog: Trailmate, a fictional hiking app, and its most-discussed requests. Four have their own deep dives, linked below.

The short version

• Scoring frameworks (RICE, weighted scoring, cost of delay) rank a long list. Use them when you have many requests and some numbers.
• Visual frameworks (impact/effort, value vs complexity) sort a short list quickly. Use them in a planning meeting.
• MoSCoW decides what goes into a fixed release. Kano tells you what kind of value a feature gives.
• Almost every framework needs two inputs you can measure: how many people want something, and how much of the business sits behind them. Votes answer the former and revenue the latter.

The sample backlog

Trailmate's users vote on requests inside the app, and the app records each voter's monthly recurring revenue (MRR). That gives two numbers per request: how many people asked, and how much paying revenue those people represent. Dividing one by the other gives a third, the revenue per voter.

Dark map style is already built. It is in the table as a lesson. It had the second-highest vote count and almost no revenue behind it, because most of its voters were on Trailmate's free plan. Ranked by votes, it looked like the next big thing. Ranked by revenue, it was a pleasant weekend project. Neither ranking is wrong. They answer different questions, which is why most of the frameworks below use both.

Scoring frameworks

RICE

RICE was developed at Intercom and described by Sean McBride in RICE: Simple prioritization for product managers. Each idea gets four numbers: Reach (people per period), Impact (on a scale from 0.25 to 3), Confidence (100%, 80% or 50%) and Effort (person-months). The score is reach times impact times confidence, divided by effort.

On Trailmate's list, the trail difficulty filter outscores offline maps. Offline maps has almost twice the votes, but it is about four times the work. Its weak spot is that impact and confidence are judgements dressed up as numbers. The RICE deep dive shows the full table, and how to use revenue per voter to set impact without counting reach twice.

Weighted scoring

Pick a handful of criteria, give each a weight that adds up to 100%, score every request from 1 to 5 on each, and add up the weighted scores. Trailmate might use revenue behind the request (40%), reach in votes (30%) and fit with this year's goal of growing word of mouth (30%).

• Offline maps: revenue 5, reach 5, fit 4, total 4.7.
• Trail difficulty filter: revenue 4, reach 3, fit 3, total 3.4.
• Share a hike: revenue 1, reach 1, fit 5, total 2.2.

Share a hike does better here than anywhere else, because the weights reward the growth goal. That is the point: the weights encode your strategy. Agree on them before anyone scores a request, or they drift towards whatever the loudest person already wanted.

Cost of delay and CD3

Cost of delay asks what it costs you, per week, not to have a feature. Donald Reinertsen popularised the idea in product development, and Black Swan Farming's introduction to cost of delay is a good place to start. To rank work, divide the cost of delay by the duration. This is called CD3.

Say Trailmate estimates that every week without offline maps costs about $150 of MRR in cancelled subscriptions and missed upgrades, and the feature takes 16 weeks. Its CD3 is 9.4. The difficulty filter costs perhaps $60 a week and takes 4 weeks, so its CD3 is 15. Build the filter, then offline maps. Cost of delay is the framework that handles timing best: as the summer hiking season approaches, the weekly cost of missing offline maps rises, and the ranking can flip. The hard part is the dollar estimate, and the MRR behind a request is an anchor for it, not the answer.

Visual frameworks

Impact/effort matrix

Draw two axes, impact and effort, and place each request in one of four boxes: quick wins (high impact, low effort), big bets (high impact, high effort), fill-ins (low impact, low effort) and money pits (low impact, high effort). For Trailmate, the difficulty filter is a quick win, offline maps is a big bet, sharing a hike is a fill-in, and trail notes is a money pit. The impact/effort guide shows how to build the impact axis from votes and revenue so the boxes are not just opinion.

Value vs complexity

This is the same shape with different axes: value to users and the business on one, technical complexity and risk on the other. It suits work where the real cost is uncertainty rather than hours. Offline maps scores high on complexity because of tile storage, download size and battery use. An elevation profile is low complexity if the trail data already holds elevation, and high if it does not.

Scope and customer frameworks

MoSCoW

MoSCoW sorts the scope of one release into Must have, Should have, Could have and Won't have this time. It comes from the DSDM agile method, and the Agile Business Consortium's guidance recommends keeping Must haves to about 60% of the effort, with Could haves as the contingency. For a spring release built around hiking with no signal, offline maps for saved trails is the Must have, and sharing a hike is a Could have. The MoSCoW guide works through the release and the 60% check.

Kano model

Noriaki Kano and colleagues described the model in their 1984 paper Attractive quality and must-be quality. Features fall into categories by how their presence and absence affect satisfaction: must-be features cause anger when missing and no delight when present, performance features add satisfaction the better they get, and attractive features delight when present and are not missed when absent. For Trailmate, offline maps behaves like a must-be for anyone hiking out of signal, and the elevation profile is attractive. The Kano guide covers the survey and how to read it.

The frameworks side by side

How to choose

The table's "Best for" column is most of the answer. The frameworks also combine well. Kano tells you what kind of feature something is, RICE ranks the candidates, and MoSCoW cuts the winners down to fit the release. Pick one, use it for a quarter, and judge it by whether your decisions became easier to explain.

Where the inputs come from

Votes are your reach. They are a sample, not a census, so merge duplicate requests to keep one idea's count in one place.

Revenue tells you whose reach it is. The MRR behind a request separates "lots of free users" from "fewer paying customers". Revenue per voter is often more useful, because total MRR grows with the vote count.

Comments tell you why. "I cannot use the app on the trail without this" and "this would be lovely" are both a vote, and they are very different requests.

Effort comes from the people who will build it, never from the people who asked.

How FeedbackKit fits in

FeedbackKit collects requests, votes and comments inside your app through the Swift SDK. A new request starts with its submitter's vote, and voting stops when a request reaches Completed or Rejected. On every plan, your app passes each user's MRR through the SDK, and in the native admin apps for iPhone, iPad and Mac you can sort requests by the total MRR of the users behind them. That puts the two inputs every framework needs, reach and revenue, side by side. When you merge duplicates, each voter is counted once.

Statuses carry the decision back to the people who asked: Pending, Approved, In Progress, TestFlight, Completed and Rejected. On Pro and up you can send an approved request to an issue tracker such as GitHub or Linear (see integrations). Plans are on the pricing page.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

No framework removes judgement. The good ones move the argument to the inputs, where it belongs, and votes and revenue are the two inputs you can measure instead of guess. If you want both numbers next to every request in your own app, start free.