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.

Thought Habits

I believe habits are a major component for success of any kind.
And some habits are just a matter of how you think about things...

I realize that along the years I've been developing some thought habits - consciously or not.

For example, when I name files, I try to name them with the words for which I'll search for if I need to find this file in the future; many times I'll insert more than a single key-word, because my habit is to use the search capability of the OS. Another example is to pay attention to fallacies while considering someone else's arguments. There are others...

It becomes a habit when you trigger your mind to realize about those behaviours and apply them in the moment that you are thinking. By the way, a good book to understand habits: The Power of Habit, by Charles Duhigg.

One thought habit that I'm consciously currently trying to develop is focus. (I have a very divergent thinking, I'm very creative, and for that it's sometimes hard to me to converge and decide what to do)

Three techniques that I'm using and its inspirations:

1 - Once, I read a book about personal organization in which the main concept was "fix what's broken - only": make a list of the real problems that you are facing; things that are bothering you... then think why it happens; then find a solution... and then forget about trying to improve even more.

2 - MVP (Minimum Viable Product) is a concept strongly used in the start-up world. It means you should NOT try to build your final complete product, but rather to discover the minimum set of functionalities and requirements that bring some value, and try to prove your premisses before building your product. This will allow you to fix your original idea - because it's highly probable that it has some flaws. So, prototype solutions to learn more while incrementally building your final solution.

3 - The 80/20 rule. This is classic, but very few really use. It means to find the small subset of items / characteristics / functionalities (or whatever) that bring the biggest impact to your problem (or whatever). Usually there's only a small set of things with higher importance. Focus on the small set of things.

One example in which I'm trying to apply some focus habits: software development process.
We've been doing software for some time already... We tried many methods, tools and concepts, and with time we were able to identify some inefficiencies in our process.
So now we came with a set of "real problems for us" (not the problems of others, which say for example that you should use Scrum or whatever. We don't - it didn't work for us). For this set of problems we are able to identify some possible solutions, that we will have to test. But those are too many, and so we will focus only in some of them to begin with.

I tell you if it worked within some months...

Can you identify some good thought habits that you have yourself?
For the divergent thinking ones and creatives: how do you focus and converge and "pick one / some" when it's needed?

Talk to your users - but how?

So you're looking for insights on how to improve your user experience, why they're not using it like it was supposed to be, and why they are not coming back...? Well, I am.

You could make interviews, surveys, use software to track behaviour, insert some logs into your application, observe your users while using prototypes, etc.
And still, you would have to pick an approach: do you want to discover your user's "real needs"? Do you want to explain your "why's and why not's"? Do you want to improve in an specific behaviour or action?

The problem is: there's too many possibilities!

Here's my approach: believe in your guts!
(Yeah, right.. what the hell does it mean?!)

Ok, I'll explain.
When you started your software you had some premisses... You made the software with an specific target-user in mind, hoping that he would use your software for some specific needs, in an specific way, and for the use of your software you were implicitly considering that some context would hold.

Like: they will find your concept interesting and will want to register; they will tell their friends, they will have an iPhone or an Android; they will whatever... If you didn't think about this yet, it's about time. Check out The Entrepreneurs Guide to Customer Development in the section that it talks about MVP's - there you will learn about what I mean with "premisses". Read Crossing the Chasm, and there you will learn what I mean about your initial target-user. These are your guts talking to you - and so far it's the only one talking to you...

...So, before trying to improve anything, or to discover new things, or listening to someone else like your users, try talking to your guts first: test your premisses. Do your beliefs hold? Turn your beliefs into facts.

Only after this consider asking someone else. But this first part is hard enough...
Right now, you don't want to explain, neither discover and neither improve anything - you wanna test if you are right! Maybe second phase would be explain.

But first, test your beliefs the fastest, simpler and less costly as you can. Be creative.
Do you have ideas on how to test them? I surely have some ideas to share. Bring your beliefs on...

Well, this post is about just a part of the answer - the "where to start?".
But there are others, like "what to test?", "what to ask?", "how to ask?"...I might have some insights and references about them too.

Wanna talk about this?
What do you think about the subject? Leave your comments...