Many first releases described as a minimum viable product are not minimum at all. They are a version one with the rough edges sanded off: accounts, settings, an admin area, three integrations and a dashboard nobody has asked for yet. The word “minimum” survives in the name and nowhere else.
That is understandable. Every feature on the list has a reason behind it, and cutting one feels like shipping something worse. But a larger first release is rarely a better one. It takes longer to reach anyone, it teaches you less once it does, and everything in it has to be carried from then on.
What a first release is for
An MVP is not a small product. It is a question with software around it: will people use this, for this job, in this way? The release exists to get an answer you can act on, as early as you can get it.
That changes what belongs in it. A feature earns its place if the answer depends on it. Everything else, however sensible, is a guess about a future you have not reached yet, and the release is how you find out whether you get there.
Why first releases grow
Scope rarely grows through one bad decision. It grows through a series of reasonable ones:
- Fear of a thin first impression. A release that does one thing can feel exposed, so a few extras are added to make it look complete.
- Everyone’s one feature. Each person involved has a feature that matters to them. Each is small on its own. Together they are a second product.
- Comparison with mature competitors. The product you are measured against has had years to grow. Matching its feature list on day one means building those years in months.
- “While we’re in there.” Once a part of the system is open, extending it feels cheaper than coming back later. Sometimes it is. Often it only moves the cost somewhere less visible.
None of these is wrong on its own. The trouble is that nobody weighs them together, so the list only ever grows.
What too much costs
The obvious cost is time. Every feature is design, build, testing and review, and the release date moves with each one. The less obvious costs arrive after launch.
Feedback gets harder to read
When a product does one thing and people do not use it, you know where to look. When it does twelve things and use is low, the signal is spread across all twelve. Was the core idea wrong, or was it buried under options? A crowded first release makes the one question you set out to answer harder to answer.
Everything you ship, you keep
Features are not one-off costs. Each one has to keep working through every later change: tested, documented, supported and migrated. A feature that ten people use still has to survive the next redesign. In the first months, when a product changes fastest, that weight slows every change you make.
Early decisions harden
A larger release makes more decisions permanent before you know which ones matter. The data model, the navigation, the pricing, the words on the screen: once people depend on them, changing them has a cost. The fewer of these you commit to early, the more room you keep to follow what you learn.
Writing down what it will not do
When we scoped our own product, the E-Bike Battery Passport, the list of what the first release would not do was written down next to the list of what it would. No GPS tracking, no ride statistics, no remote locking, no firmware updates, no marketplace and no blockchain. Several of those would have made an impressive demo. None of them was needed to answer the question the product exists for: can manufacturers, dealers, workshops and recyclers share one record of a battery that all of them can trust?
The order was decided just as early. The business portal and the public passport page came first, and the mobile app second. The first release was online only, although the API behind it was built so that offline work could be added later without reworking it. That distinction matters. Deferring a feature is cheap; deferring the decision that makes it possible can be expensive.
An explicit “not now” list does two things. It stops the same discussion coming back every week, and it makes the trade visible: everyone can see what was set aside, and why.
When more is the minimum
Some things look like features and are really conditions. In a product that holds records for many companies, keeping each company’s data apart from every other, and recording every important action in an audit log, were in the first release from the start. Without them the question could not even be asked, because nobody would put real records into a system they could not trust.
The test is the same as for everything else: does the answer depend on it? For a note-taking app, an audit log is scope creep. For a system that businesses rely on to show a regulator what happened, it is part of the minimum. Minimum is measured against the question, not against a feature count.
Deciding what stays
A useful way to cut scope is to start from the outcome rather than the feature list:
- Write the question down. One sentence: who should be able to do what, and how will you know they did?
- Describe the shortest path. The fewest steps a real person takes to reach that outcome, from arriving to done.
- Keep only what the path needs. Every step on the path needs something to make it work. That is the scope. Anything off the path goes on the “not now” list.
- Make success observable. Our own criteria were written as things we could watch happen: a consumer understanding a passport within ten seconds, a workshop adding a repair record in under two minutes. A criterion you cannot observe cannot tell you anything.
- Set a date and hold it. When something new comes up, it replaces something on the list rather than joining it.
A test for any feature
Ask what you would learn if this feature were missing from the first release. If the honest answer is “nothing we couldn’t learn later”, it can wait.
Small is not the same as unfinished
A focused release is not a licence to ship something rough. The parts that are there should be as good as you can make them: fast, clear, accessible and dependable. People forgive a product for not doing everything. They are much less forgiving of one that does a few things badly.
A small release should feel complete in what it does, not in how much it lists.
That is also where the saved time goes. Fewer features leave room for the details that make a product feel considered: clear empty states, useful error messages, and copy that says what happens next. Those are the things early users notice, and they are the first to disappear when the list is long.
Starting smaller
Cutting scope feels like a loss, because the cost of a missing feature is easy to see and the cost of including it is not. A missing feature has a name, a person asking for it and a moment in a meeting. The cost of an extra one is spread thin: a little more testing on every release, a little more to explain to every new user, a little less room to change direction. It helps to turn that around. Every feature left out of the first release is one you can still build later, this time with evidence behind it. Every feature put in is one you will maintain whether it turns out to matter or not.
A good first release is modest about how much it does and precise about why it exists. That precision is what makes the feedback useful, and useful feedback is the reason to release early at all.
