The minimum viable product was defined as the smallest thing that produces validated learning, which is not how it is now used.
The original meaning
An experiment designed to test a specific assumption.
Which may not be a product at all.
What it became
A first version with fewer features.
Which is a release strategy rather than a learning device.
The confusion cost
Teams build a small product without identifying what they are testing.
Which produces a weak product and no learning.
The useful question
What must be true for this to work, and what is the cheapest way to find out.
Types of experiment
Landing pages, concierge delivery, manual processes behind a facade.
Which test demand without building the product.
These frequently answer the question faster and considerably cheaper.
Validated learning
Evidence that changes what you do next.
Which is the actual output being sought.
Evidence that would not change any decision is not worth gathering.
Quality expectations
Minimal does not mean broken.
Which is a distinction many teams have failed on publicly.
Users judge a small product against products they already use.
Knowing when to stop
The assumption is tested and the answer is clear.
Which is the point to build properly or to stop.
Where the concept came from
Lean methodology framing product development as a series of tests.
Which was a response to teams building for years without customer contact.
That problem is real and the remedy has been widely misapplied.
Build, measure, learn
The cycle the concept sits inside.
Which only works if the measure and learn parts actually happen.
Teams that build and ship without measuring have kept one third of the method.
What to test first
The assumption that would be most damaging if wrong.
Which is usually about demand rather than about feasibility.
Existing products
The same discipline applies to new features.
Which is where most product effort actually goes.
Feature requests are demand signals of highly variable quality.
The honest summary
Identify the assumption, choose the cheapest test, and act on the answer.
Common misapplications
Shipping something incomplete and calling the poor reception a learning.
Which is not what the method describes.
The learning has to be designed in advance to be worth anything.
Regulated and safety-critical products
Contexts where a minimal first version is inappropriate.
Which includes medical, financial and transport applications.
The testing philosophy still applies; the shipping approach does not.
Enterprise buyers
Customers who cannot adopt an incomplete product.
Which means the experiment happens through conversations and pilots rather than through release.
Documentation of learning
Writing down what was assumed, what was tested and what was found.
Which teams almost never do.
It prevents relitigating the same question a year later.
The version worth keeping
Cheapest possible test of the assumption that matters most, run deliberately.
Which is useful advice independent of what it is called.
Talking to customers instead
Structured conversations about current behaviour rather than about hypothetical products.
Which is frequently the fastest test available.
People predict their own future behaviour poorly and describe past behaviour reasonably well.
Prototypes
Clickable designs without working software.
Which tests comprehension and interest at a fraction of build cost.
Pre-selling
Taking commitments before building.
Which is the strongest demand signal available.
It also creates an obligation, which is the point.
Internal resistance
Teams prefer building to testing.
Which is why the discipline requires deliberate enforcement.
The summary
The label matters far less than the practice: name the assumption, test it cheaply, and let the answer decide.
What to take from it
The specific practice rather than the terminology.
Which survives the fact that the term has been diluted into uselessness.
Teams arguing about whether something counts as one have missed the point entirely.
The one-line summary
Identify the riskiest assumption, find the cheapest honest test of it, and let the result decide what happens next.
A closing caution
None of this is prescriptive. Businesses differ by sector, by scale and by stage, and practices that work well in one context fail in another for reasons that are not always visible from outside.
What is consistent is that the businesses handling these questions well tend to have written something down, measured it in a defined way, and reviewed it on a schedule rather than when a problem forces the issue.
Where a decision carries legal, tax or employment consequences, professional advice specific to your jurisdiction is worth the cost, and this article is general description rather than advice.
One more thing worth saying
Most of what is written about running a business is written by people selling something, which shapes what gets emphasised and what gets left out.
The unglamorous parts, keeping records, reading the contract, updating the forecast, rarely feature because nobody can sell them. They are also the parts that most reliably separate businesses that survive from businesses that do not.
Whatever you take from this, take the habit of writing the number down and looking at it again next month.