Guide · Apps & software
Defining MVP scope: what to build first and what to cut
Every product idea comes with a long list of features. The MVP — minimum viable product — is the smallest subset that lets real users get real value and gives you evidence about the product's future. Scoping it is mostly about saying "not yet" to good ideas. This guide gives a method that works for startups and for companies launching new internal or customer-facing products.
[ 01 ]
In short
In short
- 01
Write the hypothesis first: who has what problem, what they will do with your product, and how you will know.
- 02
Define one core scenario that delivers the value end to end.
- 03
Cut everything that does not change the answer to the hypothesis; keep a visible "later" list.
- 04
Do not cut foundations that are expensive to change: data model, authentication, payments architecture, security.
- 05
Decide in advance which numbers mean "continue", "change" or "stop".
[ 02 ]
Guide
Step 1: the hypothesis
A useful template: "We believe that [users] have [problem]. If we give them [solution], they will [measurable action]. We will know we are right when [metric] reaches [threshold] within [time]."
Example: "Small clinics in Baku lose revenue from no-shows. If we give them online booking with automatic reminders, at least some of them will pay a monthly subscription after a free trial."
Step 2: the core scenario
Describe the one journey that delivers the value, from the user's first contact to the result. For the example: a clinic signs up → sets up doctors and schedules → patients book online → patients receive reminders → the clinic sees fewer no-shows.
Every screen and function in the MVP should serve this scenario.
Step 3: list everything, then cut
Write down all features anyone has suggested. For each, ask:
- Does the core scenario fail without it?
- Can it be done manually for the first users?
- Does it change what we learn?
Typical cuts: multiple roles when one works, advanced settings, integrations replaceable by exports, native apps when a web app or a messenger bot is enough, reports beyond the key metric, localisation into every language on day one.
Keep the cut items in a "later" list with reasons. It makes cutting easier for everyone.
Step 4: protect the foundations
Some decisions are cheap now and expensive later:
- Data model and relationships between core entities.
- Accounts and authentication, including how organisations and users relate.
- Multi-tenancy, if the product will serve many companies. See multi-tenancy.
- Payments architecture, so providers and pricing models can change.
- Security and personal data handling.
- Analytics events for the key metric.
These are not features; they are what the features stand on.
Step 5: success criteria
Agree before launch which numbers you will look at and what they mean: activation rate, repeated use, conversion to paid, retention after a month. Without agreed criteria, every result can be interpreted as success.
Step 6: user stories and estimates
Turn the core scenario into user stories with acceptance criteria. Estimate them, and if the estimate exceeds your budget or time, cut further — not quality. See writing user stories.
Resisting feature creep
- One person has final authority over scope.
- New ideas go to the "later" list by default.
- Each addition must replace something of similar size or extend the deadline explicitly.
- Show users the MVP early; their reactions are better arguments than internal opinions.
[ 03 ]
FAQ
Frequently asked questions
How minimal is too minimal?
If users cannot reach the value without help from your team, or the product is so unreliable that feedback is about bugs, the MVP is too minimal. Scope can be small; quality must be sufficient.
Should the MVP be free?
If willingness to pay is part of the hypothesis, charge — even a small amount or after a trial. Free usage does not prove people will pay.
What if stakeholders insist on more features?
Show them the hypothesis and the cut list. Ask which item would change what you learn. Most additions do not.