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.