Thoughts on MVP

MVP stands for Minimally Viable Product. It’s as trite and banal a maxim in software as the 10X improvement. While widely adopted, interpretations vary. Here’s my take: The term “viable” is the central point of contention, and will be my focus. There’s two schools of thought: the fasçade types out to test as many feature hypothesis as possible, and those with scarce yet robust releases. Our initial premise was that early adopters are willing to put up with slowness and instability if the product were left-field enough. In other words, fascade-type. While that is true to some extent, retention ultimately comes as a byproduct of the diametrically opposing philosophy ~ doing the small things well. Retention is distilled to repeated use. It therefore should come as no surprise that minor faults compound with time. Faced with two options, a platform full of new features versus those with few, it becomes an effacing exercise to opt for the latter. To succeed in the former however, your escape velocity must exceed the growth of consumer expectations. In other words, the optimization of the your platform must be predate your users getting frustrated and leaving. This is unlikely. Fascade-type release are by nature deficient in sound architecture. Refactoring old code takes about 3 times as long, mostly due to entrenched thinking. What’s more, almost nothing outpaces consumer expectation these days. The greatest yield of your diligence will comes from honing the few central tenets of your offering, and delivering those reliably. For more, checkout Zero Defects of Philip Crosby of the Martin Company. W.E. Deming is also a good read. D