MVP feature prioritization: MoSCoW, RICE, and one journey

Every MVP starts with a list that is too long. MVP feature prioritization is the work of turning that list into a first release you can build, test, and learn from. The frameworks help, but only after you make one decision they cannot make for you: which single journey the product exists to serve.

Start with one core journey

Before you score anything, write the one path a user takes to get value from your product. Keep it to a sentence with a clear start and end.

• A booking app: “A client finds an open slot, books it, and gets a confirmation.”
• An expense tool: “A freelancer snaps a receipt and sees it sorted into the right tax category.”
• A team dashboard: “A manager opens the app on Monday and sees which projects are behind.”

Now walk the journey step by step and list every feature it touches. That list is your starting scope. Anything not on the path goes to a separate list called “later”. This step alone usually removes half the backlog.

If a feature does not sit on the core journey, it has to argue its way into the first release.

MoSCoW: a fast first sort

MoSCoW splits features into four groups. It is quick, easy to explain to stakeholders, and good for a first pass with a whole team in the room.

Group	Meaning	MVP rule of thumb
Must have	The journey breaks without it	Build it, and build it properly
Should have	Important, but there is a workaround	Do by hand at first, or ship soon after launch
Could have	Nice, small, low risk	Only if time is left at the end
Won’t have (now)	Agreed to be out of this release	Write it down so it stops coming back

Where MoSCoW goes wrong

The common failure is that everything ends up as a Must. To prevent it, use a strict test: “If we remove this, can a user still complete the core journey?” If yes, it is not a Must.

A second rule helps too. Cap the Must group at roughly 60% of the time you have. The rest is buffer for the surprises every build has.

RICE: scoring the hard calls

MoSCoW is a sort. RICE is a score. Use it for the features you are arguing about, usually the Shoulds and the borderline Musts.

RICE stands for four inputs:

1. Reach. How many users will this affect in a set period? Use a count, such as users per month.
2. Impact. How much does it move your key metric for each of those users? Use a small scale: 3 for big, 2 for medium, 1 for small, 0.5 for minimal.
3. Confidence. How sure are you about the reach and impact numbers? 100% for data, 80% for strong signals, 50% for a guess.
4. Effort. How much work, in person-weeks?

The score is Reach × Impact × Confidence ÷ Effort.

A worked example

Say you are building that expense tool, with 400 users expected in the first month.

Feature	Reach	Impact	Confidence	Effort	Score
Bank account sync	300	2	50%	3	100
CSV export for accountants	200	2	80%	0.5	640
Dark mode	400	0.5	80%	1	160
Multi-currency	60	3	80%	2	72

CSV export wins clearly. It is cheap and the evidence for it is good. Bank sync looks attractive, but the low confidence and high effort push it down. That is a useful signal: before building it, find out whether users actually want it.

Do not trust the decimal places

RICE gives you a number, and numbers feel objective. They are not. The inputs are estimates. Treat the score as a way to start a better conversation, not to end one. If the ranking feels wrong, ask which input you disagree with. That is usually where the real question is.

Other filters worth a minute

A few quick questions catch features the frameworks miss:

• Is it a risk test? If a feature tests your riskiest assumption, such as whether people will pay, it may belong in even with a low score.
• Can it be manual? Many features can be a person with a spreadsheet for the first hundred users. Approvals, reports, and onboarding calls often start this way.
• Does it block the store or the law? Account deletion, privacy notices, and some payment rules are not optional, whatever they score. Check the app store submission checklist early.
• Is it expensive to add later? Some decisions, like your data model or user roles, are cheap now and costly to change. Design for them even if you do not build the full feature yet.

Write the cut list, and share it

The output of MVP feature prioritization is two documents, not one. The scope for release one, and the list of what waits. The second one matters as much as the first.

A written “not now” list does three things. It shows stakeholders their idea was heard. It stops the same debate from restarting every week. And it gives you a ready backlog for release two, ranked by what you learn after launch.

This is also how we run the start of our two-week 2Sprint at Batriders. The first three days end with a written list of what the first release will and will not do, agreed before design and build begin. You can read the full calendar in how a two-week sprint works.

MVP feature prioritization in six steps

If you only remember one thing, remember the order:

1. Name the core journey in one sentence.
2. List every feature the journey touches.
3. Sort everything with MoSCoW, using the “can the user still finish?” test.
4. Score the disputed features with RICE.
5. Check for risk tests, manual options, and hard rules.
6. Publish the scope and the cut list together.

Frequently asked questions

Which is better for an MVP, MoSCoW or RICE?

Use both, in that order. MoSCoW is a fast sort that gets a team aligned. RICE is slower but sharper, and works best on the handful of features you cannot agree on.

How many features should make the cut?

As many as the core journey needs, and few beyond it. For most first releases that means a handful of features plus sign-in, error states, and basic analytics. See what is an MVP for the full list of what a release needs to be viable.

What if a stakeholder insists on a feature?

Ask them to score it with RICE alongside everything else. If it still ranks low, offer the “not now” list as a firm commitment for release two. Most people accept a clear later more easily than a vague no.

How often should we revisit the priorities?

After launch, every time you get meaningful data. Before launch, hold the scope steady unless something you learn changes the core journey itself.

Prioritization never feels finished, but a short, honest list that ships beats a perfect one that does not.