Unviable Product, Minimum Product, Minimum Viable Product
There are several variants of the MVP.
The idea of an MVP is to iterate at a lower level of quality than you’d like, to discover what’s really needed.
But this concept can be split into multiple gradations, in increasing order of quality:
Unviable Product is so minimal that you know it won’t meet users’ needs.
Minimum Product is when you don’t know if it’s viable yet, if it needs users’ needs.
Minimum Viable Product is the version that’s validated by users.
Unviable Product (UP)
An unviable product may not have a name or an app icon. It may not respect users’ privacy or security. It may not meet Apple’s rules for mobile apps. It might not support different screen sizes, OS versions or browsers. It may not have a Log Out button — the only way to log out might be to clear cookies or reinstall the app. It may not have error handling so, if you’re offline, the app may lose your updates. The UX may be so bad that someone needs to explain to you how it works to onboard you. If it’s a camera app, the shutter button might be a button with the text Shoot on it rather than a round button with no text, as is expected. The app may support only one orientation. On first run, when you grant it permission, you may have to kill the app and restart it for it to work because that code path hasn’t been coded up yet.
An unviable product is a prototype, to scratch your own itch. Or for use by you and your team members. And perhaps a few friends and early adopters who are builders, too.
An unviable product is something that’s so minimum that you know it can’t be an MVP. You shouldn’t even try, because you know it can’t work. It’s like a car without brakes. You should treat it only as a basis for further development. You shouldn’t treat it as an MVP by marketing it, for example.
Minimum Product (MP)
A minimum product is one step better than an unviable product: it has a chance of being an MVP, which is to say that it has a chance of meeting users’ needs. This means meeting Apple’s rules for distribution, and having an app icon. It can’t lose user data. You should give at least some thought to privacy. It can’t invariably crash on first run. And so on.
Minimum Viable Product (MVP)
You may launch a 0.1 Minimum Product, but users may say it needs to be easier to use. So you improve the UX, and launch 0.2. Users may say it does too little, so you expand its scope and launch 0.3. Users may then say it’s too buggy, so you fix the bugs, and launch 0.4. This may be the Minimum Viable Product, the first version that users accept.
You know only in retrospect which version was the MVP, because users are the ones who’ll decide if it’s viable. So watch out for forward-looking statements like “We’ll launch an MVP next month.” That’s a sign you’ve gotten an MP confused for an MVP, as people often do [1].
Conclusion
Ask yourself, “Do you users want it?” If the answer is:
No: You have an Unviable Minimum Product.
Don’t know yet: You have a Minimum Product.
Yes: You have a Minimum Viable Product.
Use the above classification to think about where you are and what your next step should be in your journey, to bring clarity to yourself and to other stakeholders.
[1] Using the wrong terminology is often an indication of a deeper problem, such as failing to understand the concept of an MVP, such as when a stakeholder insists on improving a product before launching it. The whole philosophy of an MVP is to launch things at a lower quality than we’re comfortable with, to discover what’s needed, because we can’t know what users want ahead of time. Too many people treat it as a buzzword, rather than understanding the concept and how to apply it.