“Let’s just ship an MVP” is one of the most common — and most misunderstood — phrases in any product meeting. People hear “MVP” and think “the cheap version” or “the thing with half the features missing.” That’s not it. An MVP is a learning tool, and understanding that changes how you think about the whole project.
What MVP really means
MVP stands for Minimum Viable Product. Break the words apart:
- Minimum — the least you can build. No nice-to-haves, no polish you can live without.
- Viable — it still actually works and delivers genuine value. A broken thing is not viable.
- Product — it’s real enough that real people can use it.
The magic is in holding minimum and viable in tension at the same time. Strip away everything non-essential, but keep enough that someone gets real value and you get real feedback.
The point is learning, not launching
The reason MVPs exist is that building the full thing is expensive and slow, and you usually don’t actually know whether people want it. An MVP lets you test your riskiest assumption with the least possible investment.
The famous illustration: if you’re building a way for people to get from A to B, the wrong MVP is one wheel of a car (useless on its own). The right MVP is a skateboard — humble, but it actually moves someone from A to B, and you learn how they ride it. Then a bike, then a motorbike, then the car. Each step is viable and teaches you something.
An MVP isn’t version 0.1 of your final product. It’s the smallest experiment that answers “are we even building the right thing?”
What an MVP is NOT
- Not a buggy, broken first draft. “Viable” means it works.
- Not the full product with features postponed. That’s just an unfinished product.
- Not an excuse to ship something embarrassing. It should be small, but good at the one thing it does.
- Not the end. It’s the start of a build-measure-learn loop.
How teams actually scope an MVP
The hard part is deciding what’s “minimum.” A useful method:
- Name the core assumption. What’s the one thing that, if wrong, sinks the whole idea? (“People will pay to book a dog-walker from their phone.”)
- Find the shortest path to test it. What’s the least you can build so a real person can do the core action and you can watch what happens?
- Cut everything else. Ratings, profiles, fancy settings — if it doesn’t test the core assumption, it waits.
- Define what success looks like before you launch, so you know what the experiment is telling you.
A quick example
Imagine a startup that wants to build a meal-planning app with recipes, grocery integration, calorie tracking, and social sharing. The full build is months of work. The MVP might be a single simple screen that emails you a weekly meal plan. No grocery integration, no social features. If people open those emails and keep subscribing, the core assumption (“people want planned meals”) holds and you build more. If they don’t, you’ve saved months.
How to use the term
- “Let’s define the MVP — what’s the smallest version that still proves people want this?” (scoping for learning)
- “That’s a great feature, but it’s not MVP. Let’s park it for v2.” (protecting scope — see also scope creep)
- “The MVP launched and the retention numbers are weak, so we’re rethinking before we invest more.” (MVP as an experiment that can fail usefully)
The mature take: a good MVP is the cheapest way to be wrong. If it works, great. If it doesn’t, you found out fast and cheap — which is the whole point.