When the Minimum Viable Product is Not Enough

Dispelling misconceptions around the notion of MVP

Max Dunn
Max Dunn
Jul 22, 2013 · 5 min read

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?

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?

“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?

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.

Thanks to Stef Lewandowski and Andrew Brennan.

    Max Dunn

    Written by

    Max Dunn

    Silicon Publishing co-founder focused on Adobe InDesign Server and online editing solutions. Author of WYSIWYG XML Authoring in the XML Handbook.