A minimum viable product, or MVP, is the smallest version of a product that is useful enough to put in front of real users so you can learn whether it solves their problem. Its purpose is not to be small for its own sake, but to test your most important assumptions quickly and cheaply.
Done well, an MVP saves months of building the wrong thing.
Key takeaways
- An MVP exists to answer a question, so define the question first.
- Include only what is needed for a user to get the core value.
- Prototypes, manual workarounds and concierge services can all count as MVPs.
- Treat feedback and behavior as the product’s real output.
Start with the problem and the riskiest assumption
Write down who the product is for, the problem you believe they have and why your approach might help. Then list the assumptions that must be true for the idea to work and pick the riskiest one. Perhaps people will not pay, or will not change their habits, or cannot be reached cost-effectively. Your MVP should be designed to test that assumption as directly as possible.
Decide what is in and what is out
For each possible feature, ask whether a user could get the core value without it. If yes, leave it out for now. This is harder than it sounds, because teams naturally want to polish and add. A useful exercise is to describe the single journey a user must complete to see value, then build only the steps on that path.
Be careful with the word “minimum”. The product still has to be viable, meaning good enough that people take it seriously. A rough edge is acceptable. A product that does not solve the problem is not.
Different shapes an MVP can take
You do not always need working software.
- A simple landing page that describes the idea and measures interest.
- A clickable prototype that lets users try the flow before it is built.
- A concierge MVP, where you deliver the service by hand to learn what matters before automating it.
- A single-feature product that does one thing well.
Choose the cheapest option that can answer your question honestly.
Test with real people
Put the MVP in front of the kind of users you are targeting and watch what happens. Observe where they get stuck, ask what they expected and, above all, notice whether they come back and whether they will pay. Opinions are useful, but behavior is stronger evidence. Early customers can also help you decide what to do next, as described in what product-market fit really means.
Learn, then decide
After each round, decide whether to continue as planned, change direction or stop. Write down what you learned and what you will test next. A cycle of build, measure and learn, repeated in short loops, tends to outperform a long build followed by a big reveal.
When your product eventually reaches the market, how you evaluate competing tools also matters to your buyers, a perspective in how to evaluate a SaaS tool before you commit.
Common mistakes to avoid
- Building too much. Every extra feature delays learning.
- Building too little. A product that does not solve the problem teaches nothing.
- Testing with friends only. Polite supporters rarely behave like real customers.
- Ignoring what users do. Watching behavior reveals more than asking for opinions.
An illustrative example
Imagine a founder who believes small restaurants would pay for a simple tool to manage weekly staff rotas. Instead of building an app, she creates a shared spreadsheet template and manually sets up rotas for three local restaurants, asking for a small fee. She learns which parts save the most time, which parts people ignore and whether owners will pay. Only then does she decide what to automate. The first version was far from a finished product, but it answered the most important question: do people want this enough to pay?
Frequently asked questions
Is an MVP the same as a prototype?
Not exactly. A prototype is often a model for testing a design. An MVP is a version real users can use to get actual value, though some MVPs are very simple.
How long should it take to build an MVP?
As short as practical. Weeks rather than many months is a common aim, depending on the product.
What if users do not like the MVP?
That is valuable learning. Use it to understand why, and decide whether to adjust the product, the audience or the idea.
