The concept of a minimum viable product (MVP) has been around for years. MVP embodies the hypothesis that it is better to first build the smallest version of a new product, only serving a subset of customers, before expanding. The idea is to learn in an efficient manner what the customers really want, so that the next version of the product incorporates those desires.

The problem is that MVPs are rare. The term has been completely coopted to justify a lack of technology/business discipline. Don’t get me wrong: The idea is a great one, just mostly unattainable—sort of like your doctor’s advice of eating right and exercising every day. We all know it is a good idea, but very few people achieve it. Why? It is simply too difficult in practice.

(Related: Where agile goes next)

So why do so many companies think they are creating an MVP? I suspect they do because they have gone through some sort of exercise of scratching their desired features off of a list.

I am sure everyone reading this is saying “Not me, I did it right!”

I will bet you are wrong.

An example may be helpful at this point. In my fictitious company, we will build the next billion-dollar coffee-delivery system. It will revolutionize coffee delivery everywhere. The initial design is to get coffee to businesses so they no longer have to use inferior services and consume bad coffee—simple enough.

During the design meetings, the scope radically increases to delivering coffee to homes and businesses, delivering different types of coffee, scheduling coffee delivery, and delivering other types of products, such as doughnuts. Some brave soul stands up and declares that writing all of this software is going to take years, so everyone sits back down and starts cutting back scope.

All is good, right?

Sorry, but you are fooling yourselves. It’s like thinking parking in a farther-away spot is going to help you train for a marathon. Not a chance!

Here are some concepts that an MVP embodies that are often overlooked:

  • There’s only one way to do it. There should be only one way to put an order in for coffee, one way to pay, one user type…
  • Do it the simplest way. Each action should only be able to be performed in its easiest state. So your coffee delivery service is going to deliver coffee between 10 a.m. and 4 p.m. This way there is no need to schedule specific times, access codes, weekend hours, or any of that.
  • There are no undos, redos or try-agains. Sorry, but MVPs don’t allow for orders to be canceled, orders to be changed, etc.

Since I seriously doubt the stakeholders will be able to agree on the best way to do it, the simplest way to do it, and to keep the complexity down, I strongly suggest using an approach I call layering. This is one of the approaches Amadeus uses within its ID-GEM Business Impact Software Delivery Process.

How to do a layering approach

  1. Pick the core features that are critical to the system. Example: A user can indicate that they want coffee delivered and provide an address.
  2. Pick which part of your screens will accomplish the simplest version of the core parts. Example: The section of the coffee ordering screen where you pick your quantity.
  3. Code those parts of the system first.
  4. Then start adding in other features and feature depth. Example: A login screen, order status updates, credit card updates, order screen enhancements, etc.
  5. Repeat steps 2-4 with each iteration adding more and more complex functionality.

Using this approach will force the conversation to be about priorities, which is essential. This allows the organization to build the most important, simplest versions of the features first, which is sort of a sneaky way of backing into an MVP. Problem solved.