What MVP has come to mean, and what it should mean
The term now describes a small release. It was meant to describe an experiment, and the difference decides whether you learn anything.
Minimum viable product has drifted from its original meaning into something considerably less useful. It now generally denotes a first release with fewer features — the product, but smaller. That is a scoping decision, and a reasonable one, but it is not what the term was for.
The original idea was an experiment: the smallest thing that would produce reliable evidence about an uncertain assumption. Under that definition an MVP might not be a product at all. It might be a landing page, a manual service performed by three people, or a spreadsheet operated behind an interface. What makes it viable is that it answers the question, not that it ships.
Why the distinction matters
A smaller version of the product tells you how people respond to a smaller version of the product. If the assumption in doubt is whether anyone wants the thing at all, a reduced-feature release is an expensive way to find out and a slow one.
Worse, a partial release frequently produces ambiguous evidence. Adoption is weak — but was that the concept, the missing feature, the rough interface, or the fact that the useful part was scheduled for phase two? A well-designed experiment isolates one variable. A trimmed product isolates none.
Designing for evidence
- Write the assumption down before building. If nobody can state what is uncertain, the exercise is delivery with a fashionable name.
- Choose the cheapest instrument that could disconfirm it. Frequently that is not software.
- Define in advance what result would cause you to stop. Teams that skip this reinterpret every outcome as encouraging, which is a reliable way to spend two years.
- Be willing to fake the mechanism. Manual fulfilment behind a simple interface answers demand questions faster and more cheaply than an automated system, and the customer cannot tell.
- Separate the concept test from the quality test. Poor execution can bury a good idea, and the two failures look identical in the metrics.
When the smaller product is the right answer
This is not an argument that phased releases are wrong. Where demand is well established and the uncertainty is about execution — will this scale, will people adopt this particular design — building a real, narrow version is exactly right.
The failure is using one word for both situations, which lets teams believe they are running an experiment when they are simply shipping less. The clarifying question is short: what would we learn from this that we do not already know, and what would we do differently if the answer were no?
Let's build the system your business will run on next.
Tell us where it hurts. We'll bring the architects, engineers, and delivery model to fix it — and scale it.