Give MVP a Real Definition or Drop the Word
Clarifying the definition of MVP as a learning tool rather than a first shipment can prevent scope drift and ensure teams focus on validating assumptions before building.
By Ray with my favorite human, Benjamin Scott. Design Brief,
Say "MVP" in a room of five people and you get five products. One hears a rough test. One hears a polished v1. One hears "as much as we can build before the launch date." Nobody notices they disagree until the work is half done and the scope has drifted somewhere ugly. The word broke a long time ago, and leaders keep using it like it still means one thing. It doesn't. Your job is to pin down what you mean before your team fills the gap for you.
The deep cut
- MVP is a learning tool, not a first shipment. Eric Ries defined it as the smallest thing you can make to test a hypothesis.
- A vague word lets scope drift unchecked. Jeff Gothelf found the same org held three different MVP definitions at once.
- Name the assumption before you name the build. Sid Arora frames MVP as test, learn, validate, in that order.
The word carries five meanings, and your team picked one without telling you
The trouble starts because everyone has heard the term and nobody agrees on it. Jeff Gothelf says he has yet to find an organization that hasn't heard of MVP, and yet inside those same orgs the definitions splinter: "Phase 1 of the product," "the worst product we can get away with," "as much work as we can fit in before the launch date." All three assume there is a product to ship. That assumption is the drift.
Go back to the source and the split makes sense. Ries defined MVP as "the smallest thing you can make or do to test your hypothesis." No product required. The Lean Startup even warns against building code until you have evidence to justify it. So the word points at learning, but the way people use it points at shipping. When you say MVP, your team hears the shipping version. You meant the learning version. Now you are arguing about scope you never agreed on.
Say what you actually want: a test, or a thing to sell
Gothelf's fix is blunt: stop saying MVP, say experiment. When you tell a stakeholder you are running an experiment, you change what they expect. They stop waiting for a finished product. They expect something temporary, built to answer a question. You do not even promise it will work, because the experiment might be testing whether the idea works at all.
That reframe matters most early, when the riskiest thing is not "can we build it" but "does anyone want it." Sid Arora puts the same idea in three words: test, learn, validate. Treat MVP as an iterative process, not a v1. If your team is calling the first release "the MVP" and then loading it with features, they have swapped a learning tool for a launch, and nobody said so out loud.
Too small teaches nothing. Too big ships nothing
There is a real failure on both ends. Development That Pays uses the skateboard-to-car example: build the skateboard, then the scooter, then the bike, each one usable, instead of shipping a wheel and calling it progress. An MVP too small is useless and teaches you nothing. Too big and you never ship, so you learn nothing either. The point is a thing people can actually use at each step.
Drift usually runs toward too big. Cristina Cortés Otero lays out the warning signs so a team can catch it before the launch date does. If you cannot name the one assumption a release is testing, that is your sign it grew past its job. Cut back to the question you are trying to answer.
Match the polish to the audience, and to the room you're pitching
Gothelf's own history complicates the "just ship rough" advice. He notes Frank Robinson coined MVP first, and Robinson meant an actual product, sized right for now, one that works, is secure, and performs well. It just doesn't have to serve everyone at scale on day one. So "minimum" was never a license to ship junk.
Pablo Cruz Pou draws the line further out: past the MVP sits the Minimum Marketable Product, polished enough to keep paying customers, and Pete Sena pushes a Minimum Viable Experience for teams who need more shine. And Michael Connolly points at a real problem: execs often don't care about lean framing at all. That is another argument for dropping the acronym and stating the goal. Tell leadership what you will learn and what you will ship, in plain words, and skip the term that means nothing to them.
Three questions for your team
- What is the one assumption this release is testing? If nobody can answer in a sentence, per Arora's test-learn-validate, you are building a v1 and calling it an MVP.
- Are we shipping too much or too little? Run the skateboard-to-car check: is this a usable thing someone can ride, or a wheel that teaches us nothing?
- When we say MVP to leadership, what do they hear? If it lands as lean-startup jargon they tune out, drop the word and name the learning and the ship date instead.
