It's common for people to refer to early versions of software as MVPs (Minimum Viable Products).
Only, that's not what an MVP is meant to be.
People say:
"ship it early"
"try something out"
"get feedback"
"don't worry about polish"
and "you should be embarrassed about these versions"
But these aren't descriptions of an MVP; they're descriptions of a prototype, and the two are not the same.
A prototype is an early, experimental version intended for getting feedback.
You'll probably use multiple prototypes (or versions of them) until you find an MVP, or confirm that the prototype isn't going to make an MVP.
People tend to focus on the "Minimal" part of the MVP and forget about the rest. If it's not a "Viable Product", then it's not an MVP.
It's not an MVP if there aren't enough people willing to pay for and use it as it is for it to be a sustainable product/business.
Then, once you've proven you've done enough to make it a viable product, then you can add polish, more features, focus on performance or scalability, promote widely, etc.
It's not an MVP if:
- It's a free beta version
- It's only being tested internally
- It includes more features/functionality than are absolutely necessary
- You only demonstrate it privately
- Your only feedback is from influencers seeing a private preview
- People aren't paying for it (or you're not monetising it in other ways)
Of course, there will be some who read this (and probably don't get this far) who will claim that they use the term MVP to mean a prototype. If everyone using the term understands it the same way, then this may not be an issue. But if you start using terms beyond how they were originally defined or intended and you haven't verified that everyone you're communicating with understands this the same way, then there can be confusion, which can lead to wasted time/effort and broken assumptions.