16 September 20268 minute read
Minimum viable product is one of the most abused phrases in software. It is often used to mean “the cheapest thing we can show”, which produces a thin shell: a few screens, a login, a dashboard with nowhere useful to go. That is not an MVP. It is an unfinished demonstration, and it teaches you almost nothing about whether the product should exist.
A serious MVP is the smallest version of the product that still completes a valuable job for a real user. It can look modest. It should not feel hollow. People must be able to start, finish and trust the outcome.
Start with the job, not the feature list
Write down the user, the situation they are in, the job they need done and what “done well” looks like. Then draw the shortest path that gets them from first arrival to that outcome. Everything that does not sit on that path is a candidate to defer, however attractive it looks in a workshop.
That path is the product. Account types, notification preferences, extra reports, multiple roles, theming, and “nice to have” integrations are usually later. The core workflow, the data it needs, the permissions that keep it safe and the feedback that tells you it worked are not optional decoration. They are the product.
What you can cut, and what you must not
Cut breadth, not the spine. You can launch with one user type rather than five, one journey rather than a suite, one integration rather than a marketplace, and manual operations behind the scenes where volume is still low. You should not launch without a way to recover from mistakes, without a clear owner for the data, or without enough reliability that a first customer will try it twice.
- Keep: the primary user, the primary job, the data required to complete it, and a credible way to handle failure.
- Defer: extra personas, optional reporting, adjacent features, and polish that does not change whether the job can be finished.
- Avoid: a public launch that depends on heroic manual work you cannot sustain, or a demo that cannot be used with real information.
Make the MVP a learning instrument
If you cannot say what you will learn from the first users, you have specified a build, not an MVP. Decide in advance what would cause you to continue, change direction or stop. That might be whether a particular type of customer will complete the journey, whether an operational bottleneck actually moves, or whether people will trust the output enough to stop using the spreadsheet they have today.
Build just enough instrumentation to see that. You do not need a full analytics platform. You do need to know whether the valuable path is being used, where it stalls, and what people do instead.
Now, next, later
A healthy MVP conversation produces three lists. Now is the complete valuable path. Next is the smallest set of additions that would make that path usable by a wider group. Later is everything else, parked without apology. If “now” still looks like a full product roadmap, the cut has not been made yet.
Founders and sponsors often fear that a tight MVP will look insubstantial. The opposite is usually true. A product that does one important job properly is easier to explain, easier to sell and easier to improve than a wide surface that does not quite work.
