MVP means Minimum Viable Product: the smallest working version of a project that can test an important assumption with real users. It is one of the most commonly used and most commonly misunderstood startup concepts.
An MVP is not simply a cheap, ugly or unfinished version of the final product. It is an experiment with a purpose. A good MVP exists to answer a question that matters for the future of the project.
What does “minimum viable” actually mean?
Minimum means no more than is necessary to test the current hypothesis. Viable means the version must still work well enough that a real person can experience the core value. Product does not necessarily mean a fully automated software system. Depending on the hypothesis, the MVP can be a landing page, concierge service, prototype, manually operated marketplace, spreadsheet-backed service or narrow web application.
The important question is not “how little can we build?” but “what is the smallest credible thing that can give us useful evidence?”
An MVP tests risk
Before building, identify the assumption that could kill the project. Maybe the risk is demand: nobody wants it. Maybe the risk is behaviour: people say they want it but will not change their routine. Maybe the risk is technical: the core mechanism may not work. Maybe the risk is economic: the service works but costs more to deliver than customers will pay.
Your MVP should be designed around the largest uncertainty, not around an arbitrary list of features.
MVP is not the same as prototype
A prototype is usually created to understand or demonstrate how something could work. It can be clickable but fake, technically incomplete, or shown only to a small group. An MVP goes one step further: it should create enough real value that user behaviour becomes meaningful evidence.
A Figma prototype can tell you whether navigation is understandable. It cannot prove that people will pay, return every week or trust an automated recommendation with real consequences.
MVP is not the final project
The first useful version should not contain everything you can imagine. Features such as advanced dashboards, complex permission systems, integrations, automation, multi-language support or elaborate settings are often added because they make the project feel complete, not because they are required for the first test.
The final product may eventually need them. The MVP usually does not.
Examples of different MVPs
A marketplace
You do not need to build a sophisticated matching algorithm, seller dashboard and payment settlement system immediately. You can recruit five suppliers manually, present their offers on a simple page and personally connect the first buyers. The first hypothesis is whether both sides care enough to participate.
An AI document service
You may not need a complete editor, team workspaces and version history. The first version could accept one type of document, run a carefully designed AI workflow, allow a human review step and return the result. The key test is whether the output saves enough time or improves quality enough to matter.
A new consumer app
A polished mobile app may be unnecessary before you know whether people repeat the core behaviour. A narrow web version or even a messaging-based workflow can be enough to test retention.
How small should an MVP be?
Small enough that you can learn before spending heavily, but complete enough to deliver the core outcome. If the MVP is so broken that users leave because of missing basics, you have learned nothing about the real idea.
The correct scope therefore depends on the market. A game can be rough and still fun. A financial or health-related tool needs much stronger trust and reliability even in an early test. A B2B workflow may need basic security and export options before a company can try it seriously.
Start from the user journey
Write the minimum journey from problem to outcome. For example:
- the user arrives;
- understands what the project does;
- provides the minimum required input;
- receives the promised value;
- can take the next meaningful action.
Everything that does not help this journey or test the hypothesis can probably wait.
Manual work is allowed
Founders often automate too early. If ten early customers can be served manually, doing so may be better than spending two months building a system for thousands of users who may never arrive.
Manual work also teaches you what really needs automation. You see edge cases, customer questions and operational bottlenecks before turning them into code.
What should you measure?
The metric depends on the hypothesis. Useful signals can include the percentage of visitors who request access, activation rate, completion of the core action, willingness to pay, repeat usage, retention, referral behaviour, time saved, or the number of customers who continue after a pilot.
A vague result such as “people liked it” is weak evidence. A user returning four times, paying money or changing an existing workflow is much stronger.
Common MVP mistakes
Building too much
The project contains ten secondary features before the core value has been tested. This increases time and cost without increasing learning.
Building too little
The opposite mistake is releasing something so incomplete that users cannot experience the promise. If a user needs to imagine how good the future version will be, you are testing imagination rather than the project.
Choosing features instead of a hypothesis
“Version one needs login, dashboard and notifications” is not an MVP strategy. Ask what assumption those features test.
Calling a prototype an MVP
A prototype shown to friends may produce useful feedback, but it is not the same as observing real behaviour under realistic conditions.
Ignoring distribution
An MVP without a plan for reaching the first users can sit online unnoticed. Distribution is part of the experiment.
A practical MVP process
- Define the specific user and problem.
- Write the most important assumption.
- Choose what evidence would change your decision.
- Design the smallest test capable of producing that evidence.
- Build only the core journey.
- Recruit real target users.
- Observe behaviour, not only opinions.
- Decide whether to continue, change direction or stop.
When should you move beyond the MVP?
When the first version produces a repeated signal: users understand the value, complete the key action, return, pay, recommend it or ask for more. At that point the question changes from “does this deserve to exist?” to “how do we make it reliable, scalable and easier to use?”
That is when architecture, automation, onboarding, design systems, analytics, security and broader feature development begin to matter more.
The main idea
An MVP is not the smallest product you can ship. It is the smallest credible experiment that lets reality answer an important question. Its purpose is to reduce uncertainty before you commit to building the full project.
Different MVPs test different assumptions
A landing page MVP can test message and demand. A concierge MVP can test whether the result is valuable before automation. A technical proof of concept can test feasibility. A paid pilot can test willingness to pay. A clickable prototype can test comprehension and workflow.
Calling all of these “MVP” can create confusion, so it is useful to name the exact experiment and the exact evidence expected from it.
Do not hide quality problems behind the word MVP
“It is only an MVP” should not excuse broken payments, insecure data handling, misleading promises or an unusable core flow. Minimum scope is different from minimum responsibility.
How to decide what goes into version one
For every proposed feature ask: does the user need this to experience the core value? Does it reduce the main risk? Is it required for trust, safety or legal operation? If the answer is no, put it in the later list.
This creates a healthier roadmap because version one has a reason to stop growing.
What happens after the MVP?
The next step is not automatically “build all the missing features”. Review evidence first. If activation is weak, improve onboarding. If retention is weak, investigate value. If one narrow segment responds strongly, focus there. The MVP should determine the next version rather than merely precede it.
Define the learning budget
An MVP should have a limit: time, money or both. If the first experiment keeps expanding because every new idea becomes “required”, it stops being an MVP. A learning budget forces the team to choose the assumption that matters most.