Minimum Viable Product (MVP): From whose perspective should the “Minimum” be considered?

What is Minimum Viable Product (MVP) and why you should care

Very simple bookmark made from Origami

Anyone who has been involved in software development will probably have heard of the word MVP…unrelated to the Most Valuable Player award. It is a concept introduced by the entrepreneur Eric Ries in his book “The Lean Startup”. It has been 8 years since his book was published (I was surprised myself when I looked it up), but working in software development, I have seen the word MVP being thrown around carelessly, interpreted and understood wrongly, and become corrupted in its usage nowadays. I will explain the reason later.

I believe one of the problems is the way MVP is interpreted. MVP is the abbreviation of Minimum Viable Product and can be explained as follows.

It is extremely difficult to fully understand the full context of something in a different language and describe it in words that everybody can understand. I myself have supervised the translation of a book called “Lean UX” into Japanese and found that the word “Minimum” is often interpreted as “Products with Minimum Features”, either because the word made a strong impression or because businesses find it more convenient put in that way.

The point is Viable, not Minimum

Here’s an example of something I have seen happen before.

A company has decided to start a new service. After discussing with various stakeholders, a list of features they wanted us to build was put into a spreadsheet and those with high priorities are labeled “High”, which is usually around 1/3 of the list. The worst cases are when features with unproven value are given priorities. It’s even worse when there is no rationale behind it. Some people argue that the ones labeled “High” represent the MVP. They even have vague items with “Medium” priorities, so what’s the point?

While we can directly translate the Viable in MVP to “Practical” or “Feasible”, this perspective changes radically when considered from the viewpoint of the users instead of the company. From whose perspective should “Minimum” be considered? Being too concerned about practicality can result in a poor product with no value.

Yes, that’s why many people fail when trying to incorporate new ways of doing things.

This is what happens. The important thing is to consider what the user sees as a practical product. It is very difficult to explain what the word practical means. So, I often show this illustration to the parties involved to get their understanding.

This illustration comes from the blog of an Agile Coach who works in a consultant firm in the U.S. I think it’s awesome that this person changed the Viable in MVP to Usable/Lovable to provide a better understanding of the word.

Consider a user that needs a lot of time to move from his/her current location to the destination. It is inconvenient. If you consider minimum features as MVP and build the product on the basis of individual features, the distinction between minimum and extra will become more and more vague as time passes, forcing you to add all the functions to increase its utility. That’s illustrated on the top row.

On the other hand, the bottom row introduces the skateboard as the initial approach to solve the user’s problem to observe if the user sees value in the product and test if the product is practical in their daily lives. It may not be enough to satisfy the user, but if the user sees value in it and takes him/her one step further to solving the problem, we can take the next step to expand on the idea to further shorten their travel time.

Long live MVP

MVPs have specific purposes. As it is a part of the development strategy in Lean Startup, it is dangerous to throw it around carelessly. “We have a product with minimum features. The MVP is clear and ready to go,” the software development must never end like this. If that happens, you should probably reconsider whose perspective it is when you say Minimum and who you are truly trying to impress with the MVP.


  • If you have the list of functions at your fingertips, reduce that list to half its size. Then, reduce it to half again. Start from there.
  • Then, visualize and illustrate the hypothesis testing cycle and continue to add value.

UX Director @ Chatwork. Ex- Pivotal Labs, Medium Japan