When the Minimum Viable Product is Not Enough
The concept of the Minimum Viable Product (MVP) is popular and relevant to software development. However, the term gets tossed around with diverse meanings, and has different applicability in varying situations. Here are three considerations that may help clarify when an MVP makes sense or not:
Is it a market test or a product?
You can find radically different interpretations of “MVP”: Some use the term to describe a minimalist way to test the waters, to assess if a product will have an audience or not, while others use the term referring to what would be the basis for a 1.0 product launch.
Scott Selhorst has already written about confusion over the words “minimum” and “viable” (and which one you should emphasize), but I think there is just as much confusion over the word “product.”
Eric Ries has said, “The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on.”
It is kind of vague: He mentions shipping a product, but he is also talking about targeting forgiving early adopters, with the goal of gathering their feedback.Thus we have people considering a video or a landing page to be an “MVP” at one extreme, and companies using the MVP concept to define when they tell the world “use this product!” at the other. Paul Kortman writes of an MVP that his company released that didn’t work, and the consequences:
“So our earliest adopters, the people who trusted us, we pushed off a cliff in the name of Lean Startup. What am I supposed to tell them… ‘Sorry it was an MVP?’”
Ben Zifkin has also pointed out that lemming-like adoption of MVP concepts can lead to some ridiculous situations. “There is a huge focus on the MINIMUM part. It seems as if there is a race to the bottom where companies are doing all they can to ship a product that is just good enough to prevent major backlash.” Certainly he is interpreting “product” to mean “product,” not “market test,” as are most critics of MVP.
Personally I think the word “product” is abused if you are considering an MVP to be a PowerPoint, a video, a landing page, or complete vaporware. To me, a product is a product, and in that sense, the notion of an MVP is still often (not always) a wonderful concept. It depends on other factors…
Is this a revolutionary new idea or a product for a proven market?
The idea to write about MVP came about while I was considering the Adobe InDesign 1.0 release, and the architecture that went into building that product. Adobe InDesign was certainly not “MVP” in many senses: the level of investment; the depth of focus on architecture; the time spent on development before the release, all of these fly in the face of standard MVP practices. In one sense it was “minimal” in that it was not entirely feature-rich: For example, someone made the decision that the initial release did not have to have bullets or tables. But even the first release had an extremely highly evolved architecture. As Lanette Creamer, who was intimately involved with the InDesign product at Adobe, writes of it:
“A product like InDesign 1.0 can’t happen in 1 year. Those who are concerned with the minimum viable product aren’t inspiring. Have you ever wanted to work your hardest to barely scrape by? What about the maximum breathtaking experience. That’s worth your heart & soul as a developer, & that’s what makes InDesign great. It wasn’t the minimum anything. It went for the jugular.” ‘
Aha, MVP was not so relevant to that situation? Why was that?
Well, a wonderful article at PandoDaily makes the point that some products are disruptive, reflecting new and untested concepts, while some are going after a well-known, predictable, existing market, trying to sustain innovation rather than be disruptive. InDesign was competing mainly with the very robust and highly evolved QuarkXPress; thus, they had little need to toss off an experiment.
OK, InDesign was the type of situation where MVP concepts didn’t really apply. Because MVP has to be considered in the context of “startup” sorts of innovation, it wasn’t particularly relevant in that case (beyond their smart decision to release something solid enough but not yet robust).
Twitter, on the other hand… who’d have thunk we would find so many humans spitting out 140-character messages throughout their days? It was a novel concept and something worthy of the MVP idea. It was also such a simple concept that it could be built by a much smaller team than InDesign.
Basecamp is somewhere in between. It actually went after a market that was fairly mature, and they faced competitors with robust offerings, but they embraced a minimalist philosophy nonetheless. There are definitely virtues in critically analyzing the merits of a feature, and not following the crowd or placing too much value on the personal assumptions of salespeople or engineers, but really assessing what is needed and most sensible.
How self-contained and non-extensible should it be?
Another consideration is extensibility. Extensibility has a cost, both initially (architecting for extensibility is a fine art) and in ongoing development (the extensibility of features must be maintained). It is a big commitment. Yet for some forms of software it has huge value. In some cases it will make the difference between success and failure.
It is very common for extensibility to be implemented as an afterthought with software. This may be prudent in terms of getting to market or testing a market, yet the cost of implementing extensibility after the fact is higher, and when re-architecture is not an option, sacrifices are often made in terms of extensibility. In the case of InDesign, we are eternally grateful that the product was built with a serious, architectural commitment to extensibility from the beginning, Although rare, in this case it was a great decision by Adobe.
Extensibility can be very valuable even in new software that is in the “disruptive” category. The Twitter API, for example, has probably had a very positive impact on the adoption of the platform. There are now over 100,000 applications leveraging the Twitter API. Beyond considerations of mere extensibility, it is, generally speaking, worthwhile to consider investing in architecture up front, even with disruptive software, and there are cases in which this investment can help avoid a rewrite of a success.
When speaking of MVP, first decide what a “product” means and what you are aiming at with that product. For products representing new or disruptive concepts, MVP can be an effective strategy; yet even there it is conceivable that architectural investment beyond a minimalist approach will produce the best results.
