What is an MVP — and what it isn't

"Let's just ship an MVP" might be the most-said and least-understood sentence in software. Somewhere between Eric Ries coining the term and its ten-thousandth appearance in a planning meeting, MVP came to mean something like the cheapest version of the thing we already decided to build. That's not what it is, and the difference isn't pedantic — it determines whether you learn anything.

The actual definition

An MVP is the smallest thing you can put in front of real users that tests your riskiest assumption. The operative word isn't "minimum." It's "viable" — viable as an experiment. An MVP is a question wearing a product costume.

Every new product or feature rests on a stack of assumptions: people have this problem, they want it solved this way, they'll pay for it, they'll change their behavior for it. Some of those assumptions are safe. One or two of them, if wrong, kill the whole idea. The MVP exists to test those — as fast and cheaply as honesty allows.

What an MVP isn't

It isn't version 1.0 with features removed. If you scope an MVP by starting with the full vision and deleting rows from a spreadsheet until the estimate fits the quarter, you haven't designed an experiment — you've just built less. The question "what can we cut?" is the wrong starting point. The right one is "what do we need to learn?"

It isn't an excuse to ship something broken. "It's just an MVP" has absolved a lot of unusable software. Viable means a user can actually complete the core experience and you can actually observe the result. A broken product doesn't test your assumption — it tests users' patience, and contaminates the data.

It isn't always software. Some of the best MVPs are a landing page with a sign-up button, a concierge service run manually behind the scenes, or a pre-order form. If the risky assumption is "people want this," you may not need to build anything to find out. I've run this play myself with a very small business and real receipts — the principle scales down as well as up.

How to scope one properly

1. Name the riskiest assumption. Write down what has to be true for this product to succeed, then rank the list by two factors: how catastrophic it is if wrong, and how little evidence you currently have. The top of that list is your target.

2. Design the smallest honest test. What's the least you can build — or fake — that puts the assumption in front of real users and produces a signal you'd trust? Define what you'll measure before you build, not after.

3. Decide the thresholds in advance. What result means "keep going," what means "pivot," and what means "stop"? Teams that skip this step have a way of interpreting every outcome as encouraging.

4. Actually be willing to learn. The hardest part of the MVP isn't scoping — it's the organizational willingness to hear "no" from the market and act on it. An MVP built to confirm a decision that's already been made is theater, and cheaper theater is available.

Notice that step one is really a prioritization exercise — ranking assumptions by risk instead of features by preference. The muscles are the same.

The tell

Here's a quick diagnostic for whether your team is using MVP correctly: after it ships, does anyone ask "what did we learn?" — or only "what's next on the roadmap?" If the answer to the first question was never defined, the thing you shipped wasn't an MVP. It was just version one, arriving early and underdressed.