Ask five people what an MVP is and you get five answers, all of them a size: smallest product, first version, prototype, beta, v1-lite. The word has been folded into "ship less, sooner" so thoroughly that its own inventor's definition gets lost. The term means two specific things depending on whose book you open, and the misreads all come from using one definition while paying for the other.
Where the word came from
Frank Robinson coined "minimum viable product" in 2001 and defined it as the product that "maximizes return on risk for both the vendor and the customer": right-sized, big enough to sell, small enough not to bloat. Eric Ries borrowed the term in 2009 and redefined it around learning: "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort," adding immediately that "MVP, despite the name, is not about creating minimal products." Steve Blank spent years correcting the same misread: "an MVP is not the product with fewer features," but "the simplest thing that you can show to customers to get the most learning at that point in time."
So the word carries two jobs. Robinson's is a sizing heuristic: do not build past what the customer pays for. Ries's is an experiment design: the build exists to answer "should this product be built," not "can it." The Dropbox story is the canonical example of the second: Ries recounts how Drew Houston validated demand with an explainer video, and the beta waitlist went "from 5,000 people to 75,000 people literally overnight," with the product itself still unshipped.
What the word does not license
The failure mode this post exists to kill is treating MVP as a quality waiver. Ries wrote the rebuttal himself: "'minimally viable' does not mean operating in a sloppy or undisciplined way, building bad code that's going to result in a lot of technical debt, or ignoring safety or health concerns." And from the same post: "an MVP is not an excuse to throw our beliefs about quality out the window; it's simply an experiment on the way to excellence."
The clearest way to hold the two definitions: Robinson's MVP asks "how much product is worth the risk," and it is the right frame when the demand question is already answered. Ries's asks "what is the cheapest thing that teaches us whether this should exist," and it is the right frame before that answer exists. Most failed MVPs are really failed experiments: the team shipped a small product to a market whose interest was never in doubt and learned nothing, or they shipped a learning instrument to a market that needed a real product and killed the sale. Pick which job you are paying for before the scope conversation starts.
What no MVP may cut
These are not features; they are floors, and cutting them does not make the product smaller, it makes it illegal or broken:
deletion wherever users can create one;
not a v2 item
in transit; a form question and a policy at once
what "reasonable measures" means in writing
to submit at all; they are not a feature to scope
should we build"; it never answers "how sloppy
can we be"
The Dropbox numbers matter for a subtler reason: the video was not a smaller product, it was a cheaper experiment that produced a bigger answer. That is the Ries definition working as designed. The build-measure-learn loop only pays if the thing you built actually teaches you something, and "users loved the idea" is not learning when the thing they loved cost less than the thing you were planning to build anyway. An MVP that does not change any decision was a demo, not an experiment.
Our position
When a client asks us for an MVP, we build the experiment, not the skeleton: the smallest scope that answers the real question, on a foundation that does not need rebuilding when the answer is yes. That means the compliance floors are in from day one, the data model is honest, and the corner-cutting lives in the feature list where it belongs. It is the same bar we hold on our own product, CashTaq: a money app scoped to one question first, with the floors in before the features. An experiment that answers yes and then falls over in review is not a fast start; it is a slow one with a marketing story.
The takeaway
An MVP is a question with a price tag, not a product with an asterisk. Before you sign, ask the studio what question your MVP is supposed to answer and what it will still refuse to cut. If either answer is vague, you are buying a cheap product, not a fast experiment.
If you are scoping a first version and want the floor drawn honestly, send us the idea. This is the conversation we open every custom software engagement with.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
