Short answer: an MVP is the smallest thing that lets one kind of user do one job so you can learn whether your riskiest assumption is true. Anything that does not help with that goes on a cut list, gets bought instead of built, or gets done by hand for now.
The term has a clear origin. According to its Wikipedia entry, it was coined by Frank Robinson in 2001 and popularised by Steve Blank and Eric Ries. Ries defined it as the version of a new product a team uses to collect the maximum amount of validated learning about customers with the least effort. The key idea is learning, not a smaller product for its own sake.
What is the first step in scoping an MVP?
Choose one user and one job. Not "small businesses" and "manage everything", but one specific person and one task they are trying to get done.
Write it as a sentence: "A [specific person] can [do one thing] without [the current painful workaround]." If you cannot write that sentence, scoping will keep growing, because every feature will seem to serve somebody.
Two quick tests:
- Can you name a real person who fits the sentence and would talk to you this week?
- Does the sentence describe an outcome, not a screen?
How do I find the riskiest assumption?
List the things that must be true for your idea to work, then pick the one that would hurt most if it were false. It is usually one of these:
- People have this problem often enough to care.
- They will use a digital tool for it instead of the current workaround.
- They will pay, or give you the data you need.
- You can reach them at a cost that makes sense.
Your MVP is the cheapest honest test of that one assumption. Not of all four. If the riskiest assumption is "will anyone pay", a login system and an admin dashboard are not part of the test.
How do I make a cut list?
Write every feature you have in mind. Then ask of each one: can I test the riskiest assumption without this? If yes, it goes on the cut list.
Use these four labels:
- Cut: not needed to test the assumption. Build it after you have learned something.
- Fake: needed in the user's eyes, but you can do it by hand for now (for example, sending a confirmation email yourself).
- Buy: a ready-made service does it well enough.
- Build: this is the thing that makes your product different, so it has to exist.
Features that are often cut at first include user roles and permissions, a polished admin panel, multiple languages, native apps for every platform, advanced search, notifications on every channel, reports and exports, social login, and settings pages. Whether each one is truly unnecessary depends on your idea. The label is a decision you make on purpose, not a default.
Should I build or buy?
Buy anything that is not your core idea. Payments, sign-in, email delivery, file storage, analytics and scheduling are common examples. Building them yourself costs time and adds security work, and no customer chose your product for how you did them.
Before you commit to a service, check these at its own site, because plans and limits change:
- Current pricing and what happens when you outgrow the free or low tier.
- Limits that could affect your idea, such as a maximum number of items or users.
- Whether you can export your data and leave.
- Where your users' data is stored and who can see it.
If you rely on any of these facts, write down the date you checked them. We do not quote vendor limits here since they change.
Build the part that is your difference. If your product's value is a clever matching method, build that. If it is a better booking experience, build that part and buy the rest.
What must be real in an MVP?
Not everything can be faked. Keep these real:
- The part you are testing. If you fake the thing you want to learn about, you learn nothing.
- Money. Take payments through a proper provider, never through a homemade flow.
- Personal data. Store and protect it properly, even in a first version.
- Anything the user would be harmed by if it were fake, such as a booking that does not really reserve anything.
- Basic reliability on the main path. One working path is better than five that sometimes break.
Everything else can be rough: styling, edge-case messages, internal tools, and manual back-office steps.
A worked example (hypothetical, not a client)
This is an invented example for illustration only. It does not describe a real client or project.
Imagine an owner of a small group of independent physiotherapy rooms who wants an app where patients book, pay, get reminders and track exercises.
The one user and one job: a patient who wants to book a follow-up appointment without phoning.
The riskiest assumption: existing patients will book online instead of phoning the reception.
First backlog of ideas: online booking, payments, reminders by text and email, exercise videos, progress tracking, a patient profile, therapist calendars, multiple rooms, a Portuguese and English version, an admin panel, and a mobile app.
After the cut list:
- Build: a booking page where a patient picks a time slot from a list the reception maintains.
- Fake: the reception enters the slots by hand in a simple form, and sends confirmations manually at first.
- Buy: email sending through an existing provider; payment, if wanted, through an existing payment provider.
- Cut for now: exercise videos, progress tracking, patient profiles, multi-room logic, a native mobile app, text message reminders.
- Real: the booking itself, so a slot taken is a slot gone, and the patient's contact details stored with care.
What the owner learns: how many patients use the page when they are offered it, and what they ask for next. If nobody uses it, the larger app was never going to work either, and that was a cheap answer. If many use it, the next features are chosen from real requests, not guesses.
You may disagree with this particular cut list, which is fine. The point is that every item had to defend its place against one question.
When this is not for you
An MVP approach is a poor fit if your product only works at full size, for example a marketplace that is useless without both buyers and sellers, or software that must meet strict regulation before anyone can use it. In those cases you still cut scope, but the minimum is larger, and you may need specialist advice first.
It is also not the answer if you already know what users want because you have been serving them for years. Then you may need a well-built version one, not an experiment.
Next step
If you have a feature list and are not sure what to cut, send it over. In a free call, Kevin will go through it with you, label each item cut, fake, buy or build, and say honestly if the idea needs an app or whether a simpler website would test it.
