BYD TechThe short answer
To prioritize features for an MVP, start from the one problem the product must solve and the shortest path for a user to solve it. Everything on that path is a must; everything else waits. Frameworks help make the rest of the call consistent: MoSCoW sorts features into must, should, could and will not have, and RICE scores each by reach, impact and confidence divided by effort. Use them to support judgment and user evidence, not replace it.
Key points
- Start from the core problem and the shortest path to solving it.
- MoSCoW is fast for deciding scope with a group.
- RICE gives a score that makes trade-offs visible.
- Effort and confidence matter as much as how good an idea sounds.
- Revisit priorities as real usage comes in.
Start from the core path
Write the one sentence the MVP must prove, for example "busy clinic owners will book appointments through a shared link instead of by phone". Then list the steps a user takes to get that value, from arriving to succeeding. Features on that path are in. Login options, settings pages, admin dashboards and integrations usually are not, unless the path breaks without them. See How to build an MVP.
MoSCoW
| Category | Meaning |
|---|---|
| Must have | Without it, the product does not work or the test is meaningless |
| Should have | Important, but the product works without it for now |
| Could have | Nice to have if time allows |
| Will not have (this time) | Explicitly out of scope, so nobody keeps adding it back |
MoSCoW is quick and works well in a workshop. Its weakness is that everything tends to drift into "must". Be strict: a must is something without which the core path fails.
RICE
RICE was developed by Intercom’s product team. Each feature gets a score: reach times impact times confidence, divided by effort.
| Factor | Question | Scale |
|---|---|---|
| Reach | How many users will this affect in a period? | A number of people or events |
| Impact | How much will it move the goal for each? | 3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal |
| Confidence | How sure are we of these estimates? | 100 percent high, 80 medium, 50 low |
| Effort | How much work will it take? | Person-months, or a similar unit |
RICE is better once you have users and some data. Before launch, reach and impact are mostly guesses, which the confidence score should reflect honestly.
Making the cut
- Ground each feature in evidence: an interview, a request, a measured problem. See How to conduct user interviews.
- Prefer manual work behind the scenes over building automation for an MVP.
- Write down what was cut and why, so the decision is not repeated weekly.
- Look at effort honestly with the people who will build it.
- Re-prioritize after launch, using real usage instead of guesses.
A written scope helps: see How to write a PRD. Agreeing on what launch includes is where MVP development starts.
Sources
Checked when this guide was written.
