Minimal Viable Product (MVP)

The concept of MVP can be misleading...

This post is a discussion for people who already know about MVP. And this is only my own opinion on the subject.

Straight talk: if it's an MVP, it's not your final product. It's a model; and you always lose something in a model. It follows that if you have built your MVP, you have NOT built your product yet. So, you still can't know if it's good or not. A failure in your MVP not necessarily means your complete Product would fail too.

Minimal

Many people interpret the MVP as an "initial product", but I think you should not.

Your MVP is NOT something to "start with and adapt later on" based on feedbacks of your customers. The name of this is "not well-thought product" (NWTP for short). Because if you have thought carefully about your product, if you dream with its possibilities of success, if you believe in it, you will want to discover if it will stick or not! You can never live without knowing it for sure. You will never trade your "big idea" for an evolving amorphous thing.
You can change your mind and change your product based on the feedbacks of your MVP, for sure. But that's called "giving up of your original product". It's a valid option. You can go on with your evolved MVP that turned into a product that people really want to buy - but if you didn't build your original product, you can never say that this idea is really better or not than the other. You gave up of your original product.

Notice also that an MVP is NOT the same as a "fast prototype"; it's not a "mini-product".

A prototype is also a model, but used to materialize a concept, show a vision.. at most, test the technical challenges of your idea. However, an MVP is used to test something on the business side of your idea.

And notice that "minimum" doesn't mean "fast". It can be that for the purposes of your MVP it will take longer to build, and it's fine... "Minimum" doesn't mean "simple" - it can be complex. "Minimum" just means "minimum": it takes the time, and the size, and the complexity that is needed in order to minimally test an specific premiss of your business.

The minimal complexity that you need depends on what you are testing. It's worthless to build something faster and simpler for testing something else. You can actually learn things with this simpler test, but you can not learn the thing that you wanted to test. You can break down your product and test individual concepts in separate; but you can not simplify the tests themselves. And if the test is related to the integration of different concepts, well, you will have to implement the many parts. You can simplify your test, but only until the limits of the premiss to be tested.


Viable

Of course the MVP is named "minimum" to imply that you should lower the complexity the most you can, and build it the fastest you can... But the most important of all is the outcome of your test for "viability". To test the viability of your product is your goal. Not to build "something fast". Not "discovering your product", or your niche.

You want to test premisses of your product and discover upfront if it's Viable.

But if being a "starting point" is not the point of an MVP, what is it? Your MVP should "test" your Product in small parts. It should prove premisses. A well-done MVP is one that if fail, can prove a fundamental flaw of your Product concept, so that you can fix it, or give up of it, or evolve it.


Product

So, coming back to the P part of the MVP, and assuming that you are trying to build your great-Chuck-Norris-product-idea, your MVP should be something that leads you towards this product.

All MVPs should have a "purpose".
You can test fundamental premisses of your product, like "do people like the general concept?", "will they understand this feature?", "how much our cloud service is gonna cost?", "what's the logistics involved?", etc. You can test UX, before even implementing any software, using paper, pictures, wireframes.... You can test the dynamics and gamification. But dynamics can be a little trickier in some cases: it could depend on a set of features expected to drive attention of your user in a flow of triggers and actions... and maybe you will have to really implement this minimal set of features.
Defining what are the premisses to test is critical. Otherwise you will happen to only build some (other) starting product, but not an MVP. After defining them, be creative to test them minimally. But remember that in some cases you can not help taking some time to build your MVP.

And finally, remember that you can build different MVPs to test different parts of your product. In parallel or in sequence. Deriving one from the other, or building them independently. Doesn't matter; what matters is testing for the viability of your product before building it.

Our project, Spotwish, did not start with the concept of MVP in mind - because I didn't know it before. And even after knowing, I had not understood it until recently.
But now I realise that we have actually have made (by chance) some tests of premisses. Now I know that I can take a little easier on myself, by noticing that not all MVP's can be simple and fast to build - and in our case it's a really difficult one, with some premisses very complex to test.
Nonetheless, Spotwish is still a work in progress, far from our vision. And it's much easier to focus and get confidence on your project when you learn the real meaning of MVP - and specially when you learn what kinds of mini-products are not MVPs.

Could we have launched it earlier, with less functionalities? Yes. But we would not be testing our original vision. But do we really need to build the whole concept for testing the original idea? No. However, we have to build a reasonable part of it. At least we haven't yet discovered an easier way, considering that we are not in the mood of just trying to "discover a product", or a "niche", or building a "starting product". We really believe in our original idea, and we are trying to find means to test it thoroughly. For some concepts, it can take time.