The acronym gets used for everything and ended up meaning "less." Fewer features, less quality, less time. And so the MVP went from being a tool to learn something into an excuse to deliver something unfinished.
It's worth recovering what it actually was.
What it actually is
A minimum viable product is the cheapest way to answer a question. Nothing more than that.
The important part is that there's a question first. If you don't know what you want to find out, you're not building an MVP: you're building a small version 1, which is a different thing and gets justified differently.
Real questions we've helped answer:
- Are people going to buy this online, or will they always want to talk to someone?
- Can the manual process we do today be automated without breaking quality?
- Will customers load their own data, or will someone still have to do it for them anyway?
Each one defines a different MVP. And none of them needs a finished product to get answered.
Minimum doesn't mean "low quality"
Here's the most expensive misunderstanding.
Minimum is about scope: fewer things. Not about quality: the few things it does, it has to do well.
A store MVP can have five products and no filters. What it can't have is a checkout that sometimes charges twice. Because then what you learn isn't whether people buy: it's that people don't come back when you charge them wrong.
The cutting happens on what it does, never on how well it does it.
The trick to actually cutting scope
When we ask "cut everything that isn't essential," the list that comes back usually still has everything in it. Because from the inside, everything looks essential.
The question that actually works: what happens if this isn't there? Not "is it useful?" — everything is useful — but what concretely breaks if it's missing.
Often the answer is "someone does it by hand." And that's the key: in an MVP, doing it by hand is a valid feature. If you get twenty orders a week, someone can process them by hand while you learn whether the business exists at all. Automating it before you know that is building on top of a hypothesis.
What almost never gets cut
There are things that, even with minimum scope, have to be there, because without them the MVP can't fulfill its purpose of teaching you something:
- Measuring. An MVP without analytics doesn't answer any question. It's the part that gets forgotten most often, and the one that gives the whole exercise its meaning.
- Not losing data. If the experiment goes well, that data is the beginning of what comes next.
- Basic security. "It's just an MVP" isn't an argument when your first customers' data leaks — and they're also the ones who matter most to you.
How it ends
An MVP has three possible endings, and all three are good:
- The hypothesis is confirmed and now you know what to build for real.
- The hypothesis falls apart and you saved yourself the whole project. This is the most valuable one and the worst received.
- You learn the question was wrong and the right one shows up.
The only bad ending is that it stays as it is: in production, having answered nothing, growing through patches on top of decisions made for an experiment. That's no longer an MVP: it's technical debt with good PR.
That's why, when we start one, the conversation includes what happens afterward. If the answer is "well, we'll just keep using it," it's not an MVP. It's a version 1 on a tight budget, and it's worth calling it that and designing it as such.
In our case studies there are projects that started this way. If you have an idea and don't know where to start, write to us: sometimes the best first version is smaller than you think.
