Almost every product idea is born with a long feature list. And almost always, launching with all of it at once is the surest way never to launch, or to launch late without knowing which features mattered. The minimum viable product exists to avoid that, though it is often misunderstood.
What an MVP is (and is not)
An MVP is not a mediocre version of everything. It is a complete version of one thing: the shortest path that lets a real person get what they came to do. What makes it “minimum” is what it leaves out, not the quality of what it includes.
How to decide what goes in
- Write the product's promise in one sentence: what a person achieves and how long it takes.
- Draw the journey end to end, with no branches: from arrival to getting that result.
- Mark each feature as essential, nice to have or expendable for that journey.
- Launch with the essentials and keep the rest on a list, with a question next to each: what would we learn if we added it?
What usually falls out of version one
- Complex admin panels: at first a spreadsheet or an existing tool may be enough.
- Advanced personalization and settings nobody has asked for yet.
- Integrations with tools the first customers do not use yet.
- Versions for every platform at once.
An example: an app for booking sessions
Suppose you want to build an app for clients to book sessions with independent professionals. The list of ideas is long: profiles with galleries, reviews, integrated payments, notification reminders, synced calendars, internal chat, a dashboard for each professional, discounts, waiting lists. All of it sounds reasonable and all of it has a cost in development, testing and maintenance.
The promise could be summed up like this: “A person books a session in under a minute”. The minimum journey is choosing a professional, seeing the available slots, booking and receiving a confirmation. For a first version, payments can be handled outside, reminders sent by email and profiles kept simple. If people book and come back, there is a base to expand; if not, you will have avoided building ten features around an idea that did not work.
Doing by hand what will later be automated
A very useful technique in the first version is to solve manually what will later be automatic. If you do not yet know whether professionals will want to manage their own calendar, you can manage it yourself for the first few weeks with a shared sheet. When the pattern repeats and it is clear what fails and what is surplus, it will make sense to automate it, with the advantage of knowing exactly what the tool needs.
- A form and a spreadsheet can replace an admin panel for months.
- A hand-written email to the first users teaches more than any analytics dashboard.
- A manual process that hurts is the best specification of what needs automating.
What is never cut
Cutting scope does not mean cutting care. Some things, even in an MVP, are not negotiable: the security of people's data, the clarity of what is promised, basic accessibility and the main journey working for real on the devices your audience uses. A first version with few features and well made builds trust; one with many and fragile destroys it before you can learn anything.
When to expand and when to change course
After launch comes the most valuable moment: looking at what happened. If people complete the journey and ask for more, expand what they ask for, starting with what repeats most. If they arrive but do not complete it, the problem is in the journey, not in a lack of features. And if almost nobody arrives, the question is one of proposition or distribution, and adding features will not solve it. Knowing which of the three situations you are in is what a well-framed MVP lets you discover.
Version one does not have to be complete; it has to be enough to learn something real.
Measure to decide what comes next
Before launching, decide what you will observe: how many people complete the journey, where they stop and what they ask for that does not exist. That evidence, not intuition, should order the next version.
If you have an idea and do not know what to cut, that is a good topic for a first conversation: defining the scope is often the most valuable part of the whole project.