How to Prioritize MVP Features: MoSCoW vs RICE
Your feature list is too long. A practical way to cut it down with MoSCoW and RICE, including a worked example you can copy.
Every founder has a feature list that is too long. Sign-up with Google, a dashboard, notifications, a referral scheme, dark mode, an admin panel, a mobile app. Each one feels essential until you see the quote and the timeline.
Prioritisation is how you get from "everything we could build" to "the smallest thing that tests our idea". This guide covers two well-known frameworks, MoSCoW and RICE, shows how to use them together, and walks through a worked example so you can copy the method.
Start with one goal, not a list
Before ranking anything, write down what the MVP must prove, in one sentence. For example: "Parents will book and pay for a private tutor online." Every feature is then judged against a single question: does this help a real user complete the core flow, or help us learn whether they will? If the answer is no, it is not an MVP feature. It is a later feature.
MoSCoW: sort by necessity
MoSCoW sorts features into four buckets. It is fast, needs no data, and is excellent for getting a team to agree on a release.
- Must have: the product does not work without it.
- Should have: important, but the product still functions without it.
- Could have: nice to have if there is spare time.
- Won't have (for now): explicitly parked. Writing these down matters, because it stops them from creeping back in.
The common failure is a "Must" bucket that holds 80% of the list. A useful rule is to cap Musts at what you could build in your timeline with some slack, and be ruthless about the test: if we launched without this, could a user still complete the core flow? If yes, it is not a Must.
RICE: score by impact per unit of effort
RICE gives each feature a number, which helps when two ideas feel equally important or when stakeholders disagree. The score is:
RICE = (Reach × Impact × Confidence) ÷ Effort
- Reach: how many users it affects in a given period.
- Impact: how much it moves the goal for each of them. A common scale is 3 (massive), 2 (high), 1 (medium), 0.5 (low), 0.25 (minimal).
- Confidence: how sure you are of your estimates, as a percentage. Be honest here. Pre-launch, you are guessing.
- Effort: total work in person-weeks, from design through testing.
RICE works best when you have some usage data, which an MVP, by definition, does not. Before launch, treat it as a structured way to compare, not as truth.
A worked example: a tutor-booking marketplace
Imagine an MVP that lets parents find a private tutor and book a session. After brainstorming, the team has nine candidate features. Plotting them by effort and value gives this picture.
Booking, search and confirmations are high value and modest effort, so they come first. Online payment is high value and harder, so the team plans it carefully and buys it from a payment provider instead of building it. Reviews and referrals are nice but not needed to test the idea. A native app, in-app video and a tutor analytics dashboard are costly and can wait: a Zoom or Google Meet link covers video on day one.
Scoring the borderline features with RICE
For the "maybe" features, RICE settles the debate. These numbers are invented for the example:
| Feature | Reach | Impact | Confidence | Effort (weeks) | RICE score |
|---|---|---|---|---|---|
| Email reminders | 800 | 1 | 90% | 0.5 | 1,440 |
| Ratings and reviews | 600 | 1 | 80% | 2 | 240 |
| Referral programme | 300 | 2 | 50% | 3 | 100 |
| Built-in video calls | 500 | 2 | 50% | 8 | 63 |
Reminders win by a wide margin because they are cheap and reduce no-shows. Built-in video scores lowest, which backs up the decision to use an external meeting link for now.
How to combine the two
- Brainstorm freely and put every idea on a list. No filtering yet.
- Run MoSCoW first to get the Must list. This is quick and forces alignment on the core flow.
- Estimate effort for the Musts with your developers. If the total exceeds your timeline, find simpler versions before dropping anything.
- Use RICE on Should and Could items, or whenever two options compete for the same slot.
- Publish the Won't list and the reason for each, so decisions stay settled.
Ways to shrink a feature instead of dropping it
- Manual first. Handle onboarding, matching or approvals by hand for your first users.
- Buy, do not build. Use a ready-made service for payments, auth, email and search.
- One option, not many. A single payment method, one language, one currency, one city.
- Defer admin. A spreadsheet or database view can stand in for a polished back office.
- Use a template. Standard layouts and components save design and build time.
Mistakes to avoid
- Building for imaginary scale. Millions of users are a problem for later, and a good one to have.
- Letting the loudest voice win. Scores and a shared goal make the conversation about the product, not about people.
- Prioritising once. Revisit the list after real usage data comes in. Your best guesses will change.
- Forgetting non-feature work. Security, analytics, error monitoring and onboarding are not features, but skipping them hurts.
The takeaway
A good MVP is defined by what you leave out. Anchor on one goal, sort with MoSCoW, break ties with RICE, and write down what you are deliberately not building. A shorter feature list also shortens the timeline and lowers the cost, as we explain in how to build an MVP in 4 weeks and MVP development cost in 2026.
Tags
Keep reading
