How to prioritise MVP features: the MoSCoW + RICE framework explained

Every founder who comes to us has a feature list that is three times too long for a first release. That is normal. The hard part is not having ideas, it is deciding which ones earn a place in version one, and which ones wait. If you want to prioritise MVP features without it turning into a week of arguments, you need a method that separates two different questions: what does the product need in order to work at all, and what gives the most value for the effort. MoSCoW answers the first. RICE answers the second. Used together, they turn a messy wish list into a build order you can defend.

How do you prioritise MVP features?

To prioritise MVP features, run two passes. First, sort every idea into Must, Should, Could, or Won’t using MoSCoW, based on whether the product fails without it. Second, score the features inside each group with RICE, which multiplies Reach, Impact, and Confidence and divides by Effort. Build the Musts first, then work down each list in score order until your budget or deadline runs out.

The order matters. If you start with RICE on the whole list, a cheap, popular feature can outscore something the product cannot launch without, and you end up with a lovely loyalty scheme and no way to take a booking. MoSCoW gives you the guard rails. RICE gives you the sequence inside them. This is the same logic we use when we scope an app project before any code is written.

Pass one: sort with MoSCoW

MoSCoW has four buckets, and the discipline is in being strict about the first one. Must have means the product is broken or pointless without it. Should have means it is important and painful to leave out, but there is a workaround. Could have means it is nice and cheap. Won’t have this time means you have agreed, in writing, not to build it yet.

The test we give founders for a Must is blunt: if we launched without this and nothing else, would your first ten users still get the core value? If yes, it is not a Must. A booking app must let someone book. It does not have to take card payment in version one, because the groomer can take cash at the door.

A useful guard rail comes from the DSDM method, where MoSCoW was formalised: keep Must haves to roughly 60 per cent of your total effort, and leave the rest for Shoulds and Coulds. The point is slack. If every item is a Must, you have no room for the estimate being wrong, and estimates are always a bit wrong. If your Musts alone fill the whole budget, the list is not a plan, it is a hope.

Pass two: score with RICE

RICE was popularised by the product team at Intercom, and it forces you to put numbers on a gut feeling. For each feature you estimate four things.

Reach is how many people the feature touches in a set period, for example in the first three months. Impact is how much it moves the thing you care about for each person, on a scale of 3 for massive, 2 for high, 1 for medium, 0.5 for low, and 0.25 for minimal. Confidence is how sure you are of your own numbers, as a percentage: 100 per cent if you have data, 80 per cent if you have decent evidence, 50 per cent if it is mostly instinct. Effort is the build time in person weeks.

The formula is Reach multiplied by Impact multiplied by Confidence, divided by Effort. A higher score means more value per week of work. The confidence figure is the part people skip, and it is the most useful. It stops a favourite idea from winning on enthusiasm alone, because a feature you are only 50 per cent sure about gets halved.

A worked example you can copy

Imagine a booking app for independent dog groomers, with an expected 400 customers in the first three months. This is a made-up example, but the arithmetic is real. First the MoSCoW sort.

Now RICE inside each group. Within the Shoulds, SMS reminders reach all 400 customers, with medium impact (1), 100 per cent confidence because reminder emails are proven to cut no-shows, and one week of effort. That scores 400 multiplied by 1 multiplied by 1.0, divided by 1, which is 400. Card payment reaches around 300 customers, has high impact (2), 80 per cent confidence, and four weeks of effort: 300 multiplied by 2 multiplied by 0.8, divided by 4, which is 120. So reminders go first.

Within the Coulds, reviews reach 300 customers, impact 1, confidence 80 per cent, two weeks: 300 multiplied by 1 multiplied by 0.8, divided by 2, which is also 120. Loyalty points reach 150, impact 0.5, confidence 50 per cent, three weeks: 150 multiplied by 0.5 multiplied by 0.5, divided by 3, which is 12.5. Reviews beat loyalty by almost ten to one, which is the sort of result that settles an argument in a minute. The Won’ts are not deleted. They go in a parking list with a date to look at them again.

Set up the spreadsheet in ten minutes

You do not need software for this. Make one sheet with these columns: feature, MoSCoW bucket, Reach, Impact, Confidence, Effort in weeks, RICE score, and notes. The score column is a single formula, Reach times Impact times Confidence divided by Effort, copied down every row. Sort by bucket first, then by score descending within each bucket.

Two habits keep it honest. Score each feature separately from the others, and ideally get your developer to supply the Effort column, since founders consistently underestimate it. And write down the assumption behind every Reach and Impact number in the notes column. Six weeks later, when someone asks why loyalty points were cut, the answer is on the page instead of in anyone’s memory.

When RICE gives you the wrong answer

RICE is a sorting aid, not a verdict. It undervalues anything that has to exist before other things can work, which is why we run MoSCoW first. It also rewards features that touch many people lightly over features that transform a few people deeply. If your early customers are ten design studios paying £500 a month each, a feature that delights those ten can matter far more than one that mildly helps a thousand free users, and the Reach column will not tell you that.

So treat a surprising score as a prompt for a conversation, not an instruction. If a feature you are sure matters scores badly, check the inputs. Maybe your Reach is too low, or the Effort is inflated by a technical shortcut nobody has considered. Sometimes the framework is right and your instinct is the thing to change. Both outcomes are useful, which is the whole point of writing the numbers down.

How many features should an MVP have?

There is no magic number, but a pattern shows up in the projects that launch well. A first release usually has between three and seven Must features, built around a single job the user came to do. If your Must list runs past ten, you are almost certainly describing version three. Cut by asking what the user does in their first five minutes, and build only that path from start to finish.

Budget is a more honest constraint than a feature count. Decide what you can spend and by when, estimate each Must in weeks, and see where the line falls. Our piece on why the £25k MVP is a myth shows what a fixed budget really buys, which makes these trade-offs easier.

The mistakes that bloat an MVP

The first mistake is treating everything as a Must because cutting feels risky. If you cannot name a feature you are willing to cut, you have not prioritised, you have just listed. The second is scoring Reach using your hopes rather than your plan. If you have no route to 10,000 users, do not score as though you have them.

The third is forgetting the cost of the invisible work. Logins, notifications, admin screens, and data protection are rarely on a founder’s list, but they take real weeks. If you are unsure what that hidden layer costs, our guides to what it costs to build an MVP in the UK and to adding an admin dashboard put numbers on it. The fourth is never revisiting the list. Priorities should change after your first real users arrive, and a framework that cannot change is just a more elaborate way to be wrong.

Turn the ranked list into a build plan

Once the sheet is sorted, draw a line where your budget or deadline runs out. Everything above the line is your MVP. Everything below is the next release, waiting for evidence. That line is the most important output of the whole exercise, because it is the thing you can show an investor, a co-founder, or a developer to explain exactly what you are paying for.

If you would like help running this on your own idea, send us a project brief and we will turn your list into a ranked, costed plan. If you are earlier than that and still testing whether anyone wants the product, start with how to test an MVP without writing code, because the cheapest feature to build is the one you learned you did not need.