That MVP stands for minimum viable product everyone and their dog already know. Now, what does minimal actually stands for in this context?

A shitty product disguised as an MVP

If you have been working in product driven organisations for a while you might be familiar with this scene:

• An "MVP" is scoped out and set as ready for development
• During the process a lot of loose ends and questions arise
• A few are addressed. Most of them are saved for fixing in the future. After all, it doesn't need to be perfect. It is only an MVP.

Don't rely on tomorrow's release to clean up today's mess

...that release might never come after all.

Minimal is about the size of the scope - not the quality of the implementation

The concept of an MVP was created to help the testing and discovery part of the product development.

The main idea being to limit the scope size to be only the bare minimum necessary to test out the idea in the real world and discover if it is worth continuing with it or not.

See, we are only talking about scope. There is no mention of cutting corners for fixing later or accepting poor code just because this is an MVP.

That allows for being out there quickly–compared to building a full featured solution–while at the same time it gives you the opportunity to iterate quickly on the product that is in use.

There is a huge distinction here: when you develop a complete (albeit shitty sometimes) product, you are betting that your assumptions are right.

When you develop a minimally scoped product and focus on developing it after it is already in use, you get the chance to develop it based on the usage you are seeing in real life. And let me tell you something:

real life experience beats assumptions ever single time.

Summary

This is what you should take out of all of this

• Make a great product from the start
• Less features instead of shitty implementations
• Launch early - even though you feel like it is missing things
• Iterate aggressively based on the feedbacks you get.