How would you feel if you hire a handyman to make a custom bed for you, and on the first day, he assembles few wooden pieces into a platform and then never returns because he got busy with other things… Not very happy, right? Sure, the platform can be used to put a mattress and sleep temporarily but you certainly wanted much more! I personally would not only be upset about it, I will also never hire that handyman again.
Well, same happens with many MVPs (Minimum Viable Products) some times. MVPs are core to the Lean Startup principles of product creation and many times people use the term (as it is fashionable to do so) to just cut the scope – which is not what it is supposed to be. Reducing scope is definitely a big part of creating an MVP, but only a part. It requires a lot of (often) additional thinking. Let’s look at few examples –
- Your goal was to create a mobile app which works on all major Platforms, but the MVP only works on iOS. Is that a good MVP? Maybe or maybe not. Depends on how much thought was given on how the MVP – if successful – will evolve into a full product. If there was absolutely no thought given to cross-platform considerations and iOS was done only because of lack of time and resources it may require a lot of (re)work to build the full cross-platform app. Was that a good MVP then?
- Your SaaS application was supposed to be a full multi-user program with lots of complex multi-user usecases, but the MVP you have works only in single user mode – again with no thoughts given to the various very important scenarios of a multi-user environment. I think that may not be a good MVP either.
- Your mission-critical application that deals with customers’ financial data is supposed to work in online as well as offline mode. Your MVP only solves for the online usecase with no plans whatsoever to solve for the offline mode – which for sure has a very different set of problems to deal with. Not a good MVP in my opinion.
Few months ago I came across this nice article by the fastmonkeys.com team (http://bit.ly/V0R6Dv) which talks about MVP in detail and also demonstrate the concept by this awesome image from the spotify product team. It’s worth a read.
MVPs are supposed to be Minimal (Minimum) and Viable both – and often times these two requirements are at odds with each other. Truly minimal may not be viable and truly viable may not be minimal. And that is the hard part. But many times the Minimal part is given a lot of emphasis and the Viable part is ignored. Focusing only on Minimal helps us have the Prioritization/ Resourcing conversion in the short term, but ignoring Viable will almost always cost in the long run.
Let’s also see how the Lean Startup Gurus who popularized this concept talk about it.
Eric Ries defines MVP as –
that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time
Steve Blank defines MVP as –
a concise summary of the smallest possible group of features that will work as a stand-alone product while still solving at least the “core” problem and demonstrating the product’s value
In other words, MVP is a mini version of the product that has only a select few features of the envisioned product and can help validate one or more hypotheses.
So the key things here to think through for an MVP are –
- Are there hypotheses that you are trying to test and validate with it?
- Have you built (or do you have) a mechanism to measure the results?
- Do you plan to iterate through the “Build-Measure-Learn” cycle in your effort to the final product creation?
If the answer to these questions (and especially to #3) is “no”, you may just be using the term MVP to call what should be otherwise called a ‘reduced scope’.
In addition, there are some other implications of the thought process behind MVPs. From one of the earlier examples above, say you create a new feature for single-user mode of your existing application and don’t solve for multi-user usecase. Who are you leaving behind? Chances are: your higher value customers (assuming multi-user implies higher value); which is so counter-intuitive.
If we are cutting scope only because of lack of time or resources, and not to follow the lean model of development iterating from MVP on to the full version through learning cycles, let’s just not use the term MVP.
MVP is not the same as ‘reduced scope’.