What should the first release help you decide?
Start by naming the target user, the problem you are solving and the evidence the first release must produce. For example: will customers book a service through the app instead of phoning, and can staff process those bookings without extra work?
With that question written down, setting priorities becomes much easier. A feature belongs in the MVP if it makes the key journey possible, or makes it safe and measurable enough to evaluate. Everything else, however attractive, is a later convenience. This rule is the starting point of MVP development.
Keep the question visible in the backlog. New ideas will keep arriving from the team, investors and early users, and each one is easier to assess when you can ask: does this help us answer the question, or does it only make the release bigger?
What does a complete journey include?
Write the path from the moment the user arrives to a completed result, including their confirmation that it worked and the record that appears on the business side. A journey that ends on a “Thank you” screen with nothing behind it is not complete.
Before development starts, walk through the journey on paper or in a clickable mock-up with someone from the business side. Gaps such as a missing confirmation email or an unclear status often show up quickly, and at that point they cost almost nothing to fix.
Add the states real users will meet: empty screens before there is any data, invalid input and what the product does when something fails. Describe from the start which data counts as invalid and what the user sees when an error occurs.
Define the minimum administration needed to support the task. If the product only works because a developer quietly fixes records in the database, it is not yet an operational release. Set up roles and data access around the actual first use case, not around every role the product might have one day.
How do you keep the backlog honest?
For each item in the release, write an acceptance example (“a customer books a slot for tomorrow and sees it in their bookings”) and note its dependencies. Assumptions you cannot resolve yet should become short research or prototype tasks, not features built on guesswork.
Test the full journey with typical users, then decide what the results support. Sometimes the answer is to improve the core journey, not to add anything new. Growth should follow observed needs and your delivery capacity, not the length of a competitor’s feature list. Keep a list of what you have deliberately postponed as well; it saves repeating the same debates.
Before work starts, also settle what will be handed over at the end of the MVP: source code, documentation and the support arrangement. An MVP is a beginning, and the next phase or the next team should not have to start from scratch.
Checklist: MVP scope
- Write the product question and the evidence the release must produce.
- Include the complete journey with its empty, error and failure states.
- Define the minimum administration and who keeps the data correct.
- Turn open assumptions into short research or prototype tasks.
- Prioritise the next release using observed use.
Example: an MVP for booking a service
A customer can request a service, see its recorded status and receive the completion details. Staff can review and update the request in a simple admin screen. That is the whole first release.
A rewards scheme and personalised recommendations stay outside it. They may matter later, but they do not help answer the main question: is the core journey worth using for customers and workable for staff?
Common mistakes
- Building a cut-down copy of the full product. A little of everything answers nothing. Build one complete journey that tests the main assumption.
- Ending the journey at “Thank you”. If nothing happens on the business side after the user acts, the journey is not complete.
- Skipping error and empty states. Real users meet them on day one, and they shape whether the product can be trusted.
- Relying on a developer to fix data by hand. An MVP needs the minimum administration that lets staff run it without hidden help.
Questions
How do I decide what goes into an MVP?
Write the product question the first release must answer and the evidence it must produce. A feature belongs in the MVP if it makes the key journey possible, safe or measurable. Everything else goes on the list of deliberately postponed items.
Is an MVP the same as a prototype?
No. A prototype tests an idea or an interaction, often without real data. An MVP is used by real people for a real task, so it needs error handling, data storage and enough administration to operate. Our MVP development services start from that distinction.
What if investors or early users ask for more features?
Measure each request against the product question: does it help answer it, or does it only make the release bigger? Keep a visible list of postponed ideas, so people see their request was heard and the same debate does not repeat.
What should we have at the end of the MVP?
A tested journey, the evidence from real use and a decision about the next phase, plus the source code, documentation and the agreed support arrangement, so the next stage does not start from scratch.
Read next
- Mobile app vs web app: choose by where and how people use it
- SaaS MVP scope: roles, onboarding and the first valuable action
