This weekend I was doing some coding for fun. As I was writing the program, I was also mulling over the concept of Minimum Viable Product (MVP) advocated by lean startup enthusiasts. Suddenly, it dawned on me how the MVP approach is similar to the programming best practices that we have come to follow all these years.
Any competent developer would know that it is inefficient to write a large complex program and not spend sufficient time in-between testing or debugging the various modules in it. Doing so would be a recipe for disaster. However, it so happens that most developers would much rather spend their time coding than spend their time testing or debugging. There is always the temptation to write the complete program and pass it through the compiler to see it compile and run without any errors. However, in reality, that will never be the case. Once the developer fire up the compiler he/she will be confronted with the multitude of bugs in their code. And, as the program now is fully written and has multiple modules, all of which have never been tested before, trying to fix a bug now would be similar to shooting in the dark and hoping to hit the target. Hence, the recommended approach in programming has always been to write as minimal code as possible, test it, write additional code, test it and continue this process until the program is fully complete and tested.
It is uncanny how this simple insight from programming also applies in building new products. Similar to the problem mentioned before related to programming, it is also a terribly inefficient way for entrepreneurs to spend years building a full blown version of their products walled off from everyone else, including their potential customers. If they do so, many of them find out the bitter truth only in the end that no one wants or needs their products. To address this problem, lean startup experts propose that entrepreneurs should start building a minimum viable version of their products, test with potential customers, and iterate on their minimum viable products until they get that right. This approach helps address the problems and inefficiency in achieving product/market fit. Similar to how an untested program almost never survives its first contact with the compiler, a non-iterated/non-tested product also will never survive the first contact with the market/customers. It is better to get a minimum viable product wrong and have the chance to iterate than to get a final product wrong after spending years developing it. Most entrepreneurs wish to emulate Steve Jobs and hope to get their products right the very first time. However, unfortunately, not all of us are Steve. Also, even with Steve’s supervision, not all of Apple’s products turned out to be a success. Apple Maps, iCloud, Mobile Me are some of the failures that readily come to my mind. So, ultimately, the most efficient approach that will also guarantee maximum success when it comes to programming or building new products is to always be testing and totest as early and as often as possible.
I recommend reading this excellent article from Treehouse blog that sheds more light on this topic.
minimumviablethoughts posted this




