An MVP should contain one main path, for one type of user with one problem, built properly, and very little else. Around that path, keep only what a real product needs: login, payments if you charge, analytics and a way to get feedback. Sort every other idea into "later" or "never", and write that list down.
Every founder starts with a long list of features. That is normal: you have thought about your idea for months. The hard part is not finding ideas, it is choosing the few that go into the first version. This article gives you a simple method to choose, the short list of things every MVP needs even when it is small, and a worked example you can copy.
What is an MVP for?
An MVP (minimum viable product) is the smallest version of your product that real people can use, and that you can learn from. Its job is to answer one question: will people use this, and will they pay for it?
So an MVP is not a small copy of your full vision. It is one part of that vision, finished. Every feature you add makes the build longer and more expensive, and it also makes the answer less clear. If your product does ten things and people stop using it, you do not know which of the ten was the problem.
Start with one user, one problem, one main path
Before you look at any feature, write three short sentences.
- One user. Who exactly is the first version for? "Small businesses" is too wide. "Owners of a yoga studio with one room" is clear.
- One problem. What is the one thing that costs this person time or money today? If you need the word "and" to describe it, you have two problems. Pick one.
- One main path. What are the steps this person takes, from opening your product to getting the result? This path is the heart of the MVP. It has to work well, every time.
These three sentences are your filter. Each feature on your list either helps this user solve this problem on this path, or it does not.
How do you sort features into must, later and never?
Take your full list and put each feature into one of three groups. For each one, ask a simple question: can the user finish the main path without it?
- Must. Without it, the main path is broken or nobody would trust the product. These go into the MVP. The list should be short.
- Later. Useful, but the main path works without it. These wait for version two. Write them down, so nobody has to defend them again in every meeting.
- Never (for now). Ideas that serve a different user or a different problem. They may be good ideas. They do not belong to this product yet.
A useful test for the "later" group: could you do this by hand for your first twenty users? If you can send a reminder yourself by email, you do not need automatic reminders on day one.
What does every MVP still need, even a small one?
Small in scope does not mean unfinished. Some parts are not features your users ask for, but a real product cannot go live without them.
- Login and accounts. If people store anything personal, they need a secure account, and each user's data must stay separate from the others.
- Payments, if you charge. If the goal is to learn whether people pay, the payment has to be real: checkout, receipts and failed charges handled properly.
- Analytics. You need to see what people do: how many sign up, how many finish the main path, and where they stop. Without this, you launch and learn nothing.
- A way to get feedback. A visible contact link or a short form is enough. Your first users will tell you what to build next, if you make it easy for them.
- The basics of a live product. Your own domain, the emails the product sends by itself (sign-up confirmation, receipt, password reset) and error monitoring, so you hear about problems before users write in.
These are the parts that quick prototypes usually skip. They are also what makes people trust a new product enough to use it for real. They are part of every MVP we build.
A good MVP is not a small version of everything. It is one thing, done well enough that people can rely on it.
A worked example: a booking app for a yoga studio
Here is an invented example. Imagine you want to build a booking app for small yoga studios.
The user: a regular student of one studio. The problem: booking a class takes messages and phone calls, and the teacher keeps the list by hand. The main path: the student sees the classes of the week, books a place, pays, and gets a confirmation.
- Must. The weekly timetable. Booking, with a limit on places per class. Online payment for one class. A confirmation email. A way to cancel a booking. A simple page where the teacher adds classes and sees who is coming. Student accounts.
- Later. Class passes and monthly memberships. A waiting list for full classes. Automatic reminders. Several teachers or several locations. An iOS and Android app.
- Never (for now). A video library of classes. A shop for mats and clothes. A social feed for students. Ratings for teachers.
Notice what happened. The first version is one clear path for the student and one page for the teacher. It is small enough to build as a focused web MVP, and it still answers the real question: do students book and pay online when they can?
What should you leave out?
Some things appear on almost every first list. In most cases they can wait.
- A second type of user. Each new type of user adds its own screens, rules and tests. Serve one group first.
- Mobile apps from day one. A web app is usually the fastest way to reach users and learn. Apps for iOS and Android can come later from the same codebase.
- Features for rare cases. If it happens once a month, handle it by hand until you know it matters.
Leaving things out also protects your budget. Scope is the main driver of price, as we explain in our guide to what an MVP costs.
How do you know the scope is small enough?
- You can describe the product in one sentence. "Students of a yoga studio book and pay for a class online."
- You can draw the main path on one page. A few screens, in order, with no branches.
- Your "later" list is longer than your "must" list. If it is the other way round, sort again.
- You know what you will measure. For example: how many people who sign up finish the main path in their first week.
The bottom line
Deciding what to leave out is the real work of an MVP. One user, one problem, one main path, plus the few basics that make a product safe to use. Everything else goes on a written list for later. In our process, this sorting is the first week of the project, as you can see in an MVP in six weeks, week by week. If you want help cutting your own list down, tell us about your idea.
