PM Fundamentals6 min read
MVP Explained: How to Build a Minimum Viable Product
Table of contents
The short answer: A minimum viable product (MVP) is the smallest version of a product that lets you learn whether real customers value it, with the least effort. It isn't a half-finished product or a beta full of bugs. It's a focused experiment: one core problem, one target user, just enough functionality to deliver value, and a clear question you want answered.
"MVP" is one of the most used, and most misused, terms in product management.
Some teams use it to mean "version one." Others use it to justify shipping something rushed. Both miss the point.
The idea, popularized by Eric Ries in The Lean Startup, is about learning. An MVP exists to test your riskiest assumption with real users as early as possible.
What "Minimum" and "Viable" Mean
- Minimum: The least you can build, so you learn fast and spend little.
- Viable: It still has to work and deliver real value. If users can't solve their problem with it, you won't learn anything useful.
A common way to picture this: if the goal is transportation, don't deliver a single wheel, then an axle, then a car. Deliver a skateboard, then a scooter, then a bike. Each version is small, but each one actually gets someone from A to B.
MVP vs. Prototype vs. Proof of Concept
These three are often confused. They answer different questions:
| Proof of concept (PoC) | Prototype | MVP | |
|---|---|---|---|
| Question | Can we build it? | How should it work and look? | Will customers use or pay for it? |
| Main risk tested | Feasibility | Usability and value | Value and viability |
| Audience | Internal team | Test users | Real customers |
| Typical form | Technical spike, script | Clickable mockup, sketch | Working product, possibly with manual parts |
| Usually shipped? | No | No | Yes |
A team might do all three: a PoC to check that a model can read invoices, a prototype to test the upload flow, then an MVP that a small group of customers uses for real.
How to Build an MVP, Step by Step
1. Define the problem and the user
Write one sentence: "[Target user] struggles to [problem] when [situation]." If you can't, you're not ready for an MVP; go back to product discovery.
2. Identify your riskiest assumption
What must be true for this product to succeed? Usually it's a value assumption: "Small restaurants will pay to receive orders through our app."
3. Decide what you need to learn
Turn the assumption into a measurable question and a success signal, decided before launch: "At least a meaningful share of pilot restaurants accept orders weekly for a month." Agree on the number with your team so the result can't be reinterpreted later.
4. Map the core user journey
List the steps a user must take to get value. Then cut everything that isn't essential to that journey.
5. Choose the MVP type
Not every MVP needs code:
| MVP type | How it works | Good for |
|---|---|---|
| Landing page | Describe the product, collect sign-ups | Testing demand |
| Concierge | You deliver the service manually and personally | Learning what customers really need |
| Wizard of Oz | Looks automated to users, but humans work behind the scenes | Testing value before building automation |
| Single-feature | One core feature, done well | Testing the main value proposition |
| No-code | Built with tools like n8n, Airtable or website builders | Fast, cheap functional products |
6. Build, launch to a small group, and measure
Ship to a limited audience you can talk to. Track your success signal and interview users.
7. Decide: persevere, pivot or stop
Use the evidence. If the signal is strong, invest more. If it's weak, change direction or stop, and treat that as a successful, cheap lesson.
A Practical Example: An AI Meeting-Notes Tool
This is a hypothetical example.
Idea: An AI tool that writes meeting summaries and action items for small consulting teams.
Riskiest assumption: Consultants will trust AI summaries enough to send them to clients.
MVP: Instead of building integrations with every video platform, the team asks pilot users to upload a recording. A simple script creates a summary using an AI model, and a team member checks it before it's emailed back (a Wizard of Oz element).
What's out of scope: Calendar integrations, team workspaces, custom templates, mobile app.
Success signal (set in advance): How many pilot users forward a summary to a client without major edits.
What they might learn: Users like the summaries but always edit the action items. That suggests investing in better action-item extraction before any integrations.
Common MVP Mistakes
- Building too much. If your MVP takes many months, it probably isn't minimum.
- Building too little. A broken experience teaches you nothing about value.
- No success criteria. Without a pre-agreed signal, every result looks "promising."
- Ignoring qualitative feedback. Numbers tell you what happened; conversations tell you why.
- Treating the MVP as the final architecture. Expect to rebuild parts once you've learned what works.
- Launching to everyone. Start with a small group you can actually learn from.
Key Takeaways
- An MVP is a learning tool: the smallest product that tests whether customers value your solution.
- It must be both minimum and viable.
- A PoC tests feasibility, a prototype tests usability, an MVP tests real-world value.
- Set your success signal before launch.
- Many great MVPs involve manual work behind the scenes.
Your next step: take an idea you have, write its riskiest assumption, and design the cheapest MVP that could test it in two weeks.
Frequently Asked Questions
How long should it take to build an MVP? It depends on the product, but the goal is to learn quickly. If it's taking many months, look for parts you can cut or do manually.
Is an MVP the same as a beta? Not exactly. A beta is usually a near-complete product tested for quality. An MVP is a deliberately limited product built to test value.
Can an MVP be built without code? Yes. Landing pages, concierge services and no-code tools can all be valid MVPs.
What happens after an MVP? You decide whether to persevere, pivot or stop, based on the evidence, then plan the next increment.
Related Reading
- What Is Product Discovery?
- How to Write a Product Requirements Document (PRD)
- RAG Explained for Product Managers
Want to Build Your First MVP?
Inside the AIPM community, we go from product idea to working AI prototype, including Android and iOS apps and n8n automations.
— Mostafa Mekawy