
Thoughts on MVP - danm07
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:<p>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.<p>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.<p>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.<p>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.<p>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.<p>The greatest yield of your diligence will comes from honing the few central tenets of your offering, and delivering those reliably.<p>For more, checkout Zero Defects of Philip Crosby of the Martin Company. W.E. Deming is also a good read.<p>D
======
pedalpete
It sounds to me like you are trying to balance deep vs wide in an MVP.

Wide being a large group of features/hypothesis, deep being more focus on
fewer features.

I think it depends on the situation, but for the most part I believe MVP
should be neither of these things, or somewhere in the middle.

It isn't about testing many hypotheses, it is about testing one hypothesis.
"Is there a market for x".

The answer isn't to build a robust release or build a facade for many tests,
but to build the minimum amount to answer that question. You don't want to
build deep into the technology of a single 'feature', and you don't want to
build many features. What is the minimum number of features and the minimum
amount of those features that can be built in order to answer the hypothesis.

