Creatives Takeover

How to Prioritize MVP Features

Prioritize MVP features by keeping only those that deliver the single core outcome or test the assumption most likely to sink the product. Score every other feature against those two tests, and move anything that fails to a visible backlog.

By Javier Alonso, Founder & CEO. Updated .

Step by step

  1. Write the core outcome in one sentence

    "A clinic manager sends automatic appointment reminders without changing booking system." Features that do not serve this sentence are candidates to cut.

  2. Name the riskiest assumption

    The belief that would kill the product if wrong, for example "patients respond to text reminders more than calls".

  3. Score each feature

    Give each feature two scores from 0 to 3: how much it contributes to the core outcome, and how much it reduces the riskiest assumption. Add a third score for effort, from 1 (days) to 3 (weeks).

  4. Keep the high-value, low-effort features

    Sort by value divided by effort. Keep the top items until the build fits in a few weeks. Everything else goes to the backlog.

  5. Publish the backlog

    Share the list of deferred features with your team and early users. Saying "not now" is easier when people can see it is recorded.

The MoSCoW method

MoSCoW is a common way to sort features into four groups:

  • Must have: without it, the core outcome is impossible.
  • Should have: important, but the MVP works without it.
  • Could have: nice to have if time allows.
  • Won't have (this time): explicitly out of scope.

For an MVP, build only the must-haves. Be strict: teams tend to put too much in the first group. If a manual workaround exists, it is not a must-have.

Example

A team building appointment reminders for clinics starts with 14 feature ideas. After scoring:

  • Keep: connect to the booking calendar, send a text reminder 24 hours before, let patients confirm or cancel by reply.
  • Manual for now: onboarding (done on a call), reporting (sent as a weekly email by the founder).
  • Backlog: custom templates, multi-language support, email reminders, staff permissions, analytics dashboard and others.

The MVP ships in four weeks instead of four months.

Common mistakes

  • Prioritizing features that impress investors over ones that serve users.
  • Letting the loudest early user set the roadmap.
  • Keeping features because they are already half-built.
  • Forgetting to build the measurement needed to know whether the MVP worked.

For your role

Mentors
When a founder's MVP keeps growing, ask them to score the features out loud against the core outcome. It makes the trade-offs visible.

Primary sources

Common questions

How do I decide which MVP features to build?
Keep features that deliver the core outcome or test your riskiest assumption, and that fit in a few weeks of work. Defer everything else to a backlog.
How many features should an MVP have?
As few as possible: usually three to five essential capabilities that let one customer reach the core outcome.
What is the MoSCoW method?
A way to sort features into must have, should have, could have and won't have. For an MVP, build only the must-haves.

Put it into practice

MVP Scope helps you identify must-have features and leave with a tighter, more buildable plan.

Scope your MVP

Keep learning