The term minimum viable product has been used so many times in so many contexts that it has lost meaning for most people. Some founders treat it as a synonym for "crappy first version." Others treat it as an excuse to ship something incomplete. Neither interpretation is correct, and the misunderstanding has a measurable cost.
What an MVP actually is
An MVP is the minimum version of a product that can validate your core hypothesis about whether the product will work. The key word is validate. An MVP is not a product you plan to sell. It is an experiment designed to answer a question.
The question is usually something like: "Will users pay for a solution to this problem?" or "Can we acquire users through this channel at this cost?" or "Does this feature drive the retention improvement we predict?"
A useful MVP is the least expensive and fastest way to answer that specific question with sufficient confidence to decide what to do next.
Why "minimum" is misunderstood
Minimum does not mean broken. Minimum means no more than what is required to answer the question.
If your hypothesis is that busy professionals will pay for a tool that summarizes their daily emails, your MVP needs to: accept emails, produce useful summaries, and let someone pay you for it. That is the minimum. A beautiful onboarding flow is not minimum. Multi-language support is not minimum. Mobile apps are not minimum.
The minimum is often more than founders want to build (because it requires real functionality that works) and less than founders try to build (because they add features that are not needed to test the hypothesis).
Why "viable" is misunderstood
Viable means the product works well enough that users get genuine value from it and you can learn from their real experience with it.
A landing page is not an MVP. A landing page is a demand test. It tells you if people are interested enough to sign up. It does not tell you if they will actually use the product or pay for continued access.
A mockup is not an MVP. A mockup tells you if people understand the concept. It does not tell you if they will actually use a working version.
A product with core functionality broken or so rough that users cannot get value from it is not viable. Users struggling through a broken experience do not give you the data you need.
The standard most useful to apply: would a real user pay money for this and be satisfied that they received value? If yes, it might be viable. If no, it is not.
The Dropbox example people always cite
Drew Houston famously validated Dropbox with a video showing how the product would work, before building the product. Signups poured in. This is often cited as evidence that you can validate demand without building.
This worked for Dropbox because the question was demand: do people want this product? The video answered that question adequately.
But this approach does not work for most products. If your hypothesis is about usage patterns, retention, or specific feature value, you need users to actually use a working product. The Dropbox video trick answers demand questions. It does not answer product questions.
What makes an MVP useful
A useful MVP has four characteristics:
A clear hypothesis. You know exactly what question you are trying to answer before you build. The MVP is designed around answering that question.
A way to measure the answer. If your hypothesis is about retention, you need a way to measure whether users come back. If it is about willingness to pay, you need a payment mechanism. If the MVP cannot produce data that answers the question, it is not a useful MVP.
Real users in the intended context. Testing with friends who want to support you is not useful. Testing with people who have the actual problem you are solving, who found out about the product through a channel you could actually scale, is useful.
A decision rule. Before you launch the MVP, define what result would tell you to continue vs. pivot vs. stop. If 30% of users who try the product pay for it after a trial, continue. If under 10%, pivot or stop. Setting this threshold before you have results removes the bias that comes from rationalizing whatever result you get.
What an MVP is not
An MVP is not:
The first version of a product you plan to sell for years. It is a learning tool. Treat it like one.
An excuse to ship a product with broken features. Broken features do not produce useful data. They produce noise.
Something you have to charge for. Sometimes a free MVP that asks for real commitment (time, effort, integration into someone's workflow) is more validating than a paid one.
A one-time activity. Products have multiple hypotheses. MVPs are an ongoing method, not a one-time event. After your initial MVP validates demand, you build the next hypothesis about what drives retention, and run the next experiment.
The cost of getting this wrong
Founders who build too much before validating spend months and significant money on features no one wanted. This is the most common failure mode in early-stage software products.
Founders who build too little call something an MVP when it cannot actually generate learning, then make decisions based on insufficient data.
The right amount to build requires being honest about what question you are answering and what the minimum product is that could answer it with real data.
Use the MVP planner to define your core hypothesis and what a minimum product looks like. Then get in touch to discuss what it would cost to build and how long it would take.