Definition: The MVP (Minimum Viable Product) is the first functional version of a product designed to validate the most important business hypotheses with minimum development effort. The goal is to learn, not to impress.
— Source: NERVICO, Product Development Consultancy
What is an MVP
The concept of MVP was popularised by Eric Ries in "The Lean Startup" (2011). The central idea is simple: instead of building a complete product before launching, build the minimum necessary to test whether your business hypothesis is correct.
An MVP is not a bad or incomplete product. It's a focused product that does one thing well: validate whether there's real demand for what you want to build.
What an MVP is NOT
- Not a demo: It must be functional and usable, not just a presentation.
- Not a prototype: Although it may look similar, the MVP goes to real users.
- Not an excuse for low quality: Minimum doesn't mean shoddy.
- Not a finished product: It's a starting point for iteration.
The Purpose of the MVP
The only goal of an MVP is to learn. Specifically:
- Validate that the problem you think exists actually exists.
- Validate that the solution you propose solves that problem.
- Validate that there are people willing to pay for that solution.
If your MVP doesn't help you learn something about your market, you've built the MVP wrong.
What to Include in an MVP
The "Just One Thing" Rule
A good MVP does one thing well. Identify the core value of your product —the main reason someone would use it— and build only that.
Inclusion Criteria
- Is this feature necessary to validate the main hypothesis?
- Without this feature, does the product make no sense?
- Can users not complete the main flow without this?
If the answer to all is "no", that feature can probably wait.
What to Leave Out
- Complete authentication: Sometimes email and magic link is enough.
- Admin dashboard: Do it manually at the start.
- Multiple payment methods: One is enough to validate.
- Internationalisation: Start with one language.
- Performance optimisation: The first 100 users don't need it.
- "Nice to have" features: If in doubt, leave it out.
How to Measure MVP Success
Define before building what metrics will determine whether the MVP validates or invalidates your hypothesis:
- Activation: What percentage of users complete the main flow?
- Retention: Do they come back to use the product?
- Conversion: Do they pay or sign up to pay?
- Qualitative feedback: What do users say when using it?
Common Mistakes
1. Building Too Much
The most frequent error. "While we're at it, let's also add this..." Every extra feature is time not spent validating and learning.
2. Not Talking to Users
An MVP without users is just a development exercise. You need real feedback from real people using your product.
3. Technical Perfectionism
Wanting the code to be perfect before launching. The MVP code will probably be rewritten when you validate. That's fine.
4. Ignoring the Hypothesis
Building features because they're "cool" rather than because they validate something specific. Every decision should answer: "What will I learn from this?"
After the MVP
When the MVP validates your hypothesis, you have two paths:
- Iterate: Add features incrementally based on feedback.
- Scale: Prepare the infrastructure for growth if there's traction.
If the MVP invalidates your hypothesis, you've also won: you've learned before investing more time and money in the wrong direction.