Consolidated from two 2021 posts on the MVP myth and updated. We still get asked to build an MVP most weeks, and we still say the same thing.
The minimum viable product came out of lean and agile thinking and became part of the vocabulary. At its core it is sound: the first released version of a product should include only what is needed to test the assumptions behind it. Facebook’s first release was profile pages for one college. It worked.
The problem is what “minimum” has come to mean in practice. Too many MVPs are cold, checklist-driven things that take the word to heart: how little can we get away with? The result is a single-workflow, bug-laden release that does the thing but does not do anything with gravity, magnetism, or difference. If the first thing your customers see is undifferentiated, why would they switch to it? And why would you release it?
A slight philosophical shift
We aim for a first release instead. The phrase does two jobs. It reminds everyone that there is more to come, that software is built in increments and the first one is not the last. And it reframes the question from “what is the least we can build” to “what is the smallest release that is genuinely valuable and genuinely ours.”
A first release also starts, somewhat pessimistically, from the assumption that things will go wrong. Assume the failure and you can plan around it: validate the assumptions, look at the product from every user’s viewpoint, and put the riskiest work first. It is usually not more expensive than an MVP. It is more deliberate.
Three myths about the first release
Myth 1: it has to include every important feature. During planning and research, customers and users will ask for a great deal. The first release is the smallest set of features that lets you validate the core assumptions, with the thing that makes your product special kept in. Everything else goes to the next release.
Myth 2: it should match what competitors already have. If you ship what the other guys ship, customers have no reason to move. Streamline hard, but keep the differentiating features. If your differentiators do not rank near the top when you prioritize, ask whether the market wants the product at all.
Myth 3: it is only for consumer startups. A first release is just as valuable for an internal operations tool at a fifty-person company. You need buy-in from the people who will use the system, and the fastest way to get it is to put something real in their hands and listen. Otherwise you have a bag of code.
How to decide what goes in
Prioritization should be a collaborative exercise between you and the team, not a vendor’s guess. The method we use is simple enough to do at a whiteboard.
Score every candidate feature on three things, each on a four-point scale: value to the business, value to the user, and the value of the data it produces. Use a scale with no midpoint, because a five-point scale produces a wall of threes. Add the scores. The features at the top are your first release. The features below the line go to the backlog for release two, where feedback from real users will re-sort them, often in ways that surprise you.
Two things fall out of this. Not all of your favorite features will make the first release, unless you are willing to move the schedule and the budget. And what you thought was the most important feature is sometimes not, which is exactly what you needed to find out early.
What this has to do with how we work
Everything. It is why every new build starts with a VDP Sprint: the research, the mockups, and the prioritization above happen before anyone writes production code, and the scope that comes out of it is a first release, not a wish list. It is why we work to a fixed budget with controlled scope, so the first release is sized to the money and ships. And it is why our success rate is what it is. Across hundreds of projects since 2005, 96.5% have succeeded, against an industry where roughly 70% of software and data projects fail or run over.
You are not trying to build the “best” product. You are trying to build your users’ favorite. Put those two in a fight and the favorite wins every time.