Talk with anybody involved with software development these days and there’s a good chance you’ll hear about minimal viable products. Over the past few years the phrase has exploded in popularity, largely due to Eric Reiss’ book The Lean Startup, where he proposes entrepreneurs leverage a continuous innovation as a means of product development. At this point the term is being tossed around everywhere—from two person start-ups working in coffee shops to large development teams building software for the major names throughout Silicon Valley.
A minimal viable product (MVP) is a software development strategy where only the essential features are built and then released in an attempt to validate whether a market for a product (or feature) exists. The basic idea is the development team should spend the least amount of time and money getting something out the door in order to gather feedback—determining whether people want to use, or buy, their product. For example before spending $100k building a website with all the bells and whistles it’s a good idea to get something simple into the hands of a few people in order to validate the basic concept. This makes it easy and cheap for a team to test a product idea and pivot if nobody wants to use it.
But with the meteoric rise of the term MVP much of its underlying meaning has been lost. The phrase itself has been co-opted and applied, often incorrectly, to a wide variety of situations, to the point that many of its core principles are ignored or skipped entirely.
As a designer this bothers me a great deal, because it typically results in a compromised user experience, which often leads to an unsuccessful product or feature. If you’ve found yourself in a similar situation, frustrated when term “minimal viable product” is tossed out to justify a compromised design or shortcuts in the development process, here are a few essentials elements that are often glossed over when discussing (and implementing) a minimal viable product.
- MVP is a development process not a product
At the heart of the MVP strategy is iteration and testing. If you’re building a product or feature but have no plans to immediately measure its success, then build the next version using those findings, you should not be working with an MVP mindset. - “Viable” is as important as “Minimal”
It’s easy to fixate on the minimal part (and many people do) but getting a handle on what is viable for your particular product is more important. Defining what’s “viable” can be difficult, it’ll depend on the market you're competing in and the makeup of your users/customers. Try to find a balance between moving quickly and providing a quality user experience where customers find value in using the product. - Target your audience
Eric Reiss wrote MVPs should target early adopters. He concluded this group of users is willing to provide feedback and can be forgiving because they’ll better understand the potential of the product. You may argue with his conclusion (I would, because it’s very difficult for anyone, even early adopters, to envision a product's potential) but at the very least you should be targeting a segment of users and not releasing your MVP to 100% of the world. People are not generally forgiving of software—they may try something once but if they’re not satisfied it’ll be an uphill battle to re-engage them.
As a designer I freely admit to being biased towards a polished product (Maximum viable product sounds good to me), but after participating in a range of projects that featured some concept of minimal viable product I see a great deal of value in the strategy. Being able to quickly deploy, gather feedback, and iterate until you’ve created a valuable product can be an excellent way to develop software. But the speed at which the MVP mindset has overtaken the industry worries me. It’s essential that product managers, engineers, and designers understand both the pros and cons, and weigh the effects it may have in a specific market or group of users before embarking down the “minimal viable” path. Without this deeper understanding it’s all too easy to release a sub-par experience into a competitive marketplace or to a group of people who will dismiss the product and never give it second chance, no matter how much work is put into a second version.
Great article. The term MVP is a rebranding of a concept that has been prevalent in software engineering since the dot-com boom. Once software was no longer pressed on to CDs and could be readily updated, there was no need to build all of the features into the first and only release. We used to just call it “v1”. The term “MVP” is preferred because it emphasizes the often overlooked “viable” part, which is essential in creating successful products.
Viability is a sum of novelty and quality. An MVP is about releasing a reduced feature set that is rock solid in quality. Features in isolation can’t dictate their novelty. A product needs to be framed in context of the market to define its USP. To be viable a product needs to be appreciably better, distinct from, or cheaper than any competitors. Why were millions of users ready to leave MySpace in favor of a less feature rich Facebook? Quality. MySpace would crash and show error messages on a regular basis. Facebook had zero novelty, but total quality. Facebook could offer a substantially better user experience and millions flocked to it.
Even the greatest product designer can’t be sure of the course the universe is going to take. Being agile and able to pivot with ebbs and flows of our ever changing world is critical. Especially considering how cheap and easy launching a software product is today compared to 10 years ago. Competition can appear from anywhere, anytime. While a rigid company is busy getting all the bells and whistles polished, a small guerrilla outfit can bring an MVP to market and establish entry barriers to their competition.
A fine example of this was Instagram launching without a website. Instagram focused on having the best picture filters and a seamless sharing component. They did not need to segment their audience as their MVP product was solid in quality and unique in its offerings. In fact, as soon as they knew they were on to a winner, it was crucial to scale up as quickly as possible to take the market. Many competitors tried to move in on their market share by offering essentially the same service with a web viewer. The extra feature was not a large enough incentive to make users switch. Instagram could not be beaten on novelty or quality, and were free to iterate on their design.
Small high-quality feature sets are the difference between a products that establish market dominance and those that drive customers away, forever.
@Martin, completely agree with your comments. Execution is as important as the idea itself. Coincidently enough in an earlier draft of this article I used both Facebook and Instagram as examples for the exact same reasons you noted. Thanks for the comment.