The MVP approach sucks – sometimes.

Defining an MVP is a great approach to deliver value quickly to your customers and also to get good feedback on functionality very early in the development process so that you can base future decisions on that feedback.

Let’s start with a definition. What is an MVP? Here is the definition from Wikipedia:

A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

And another definition from the book The Lean Startup:

Version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

To me the two key goals of a Minimum Viable Product are

• be quick to market
• get early feedback for future iterations

So why does the title of this blog say that MVPs suck sometimes? It’s when we deploy an MVP into production and then never listen to the feedback and never invest in future iterations.

In that case, the only value we will get out of an MVP is being quick to market. And of course that in itself is a value but you are risking to get unhappy customers because sure enough by delivering an MVP you are setting the expectation that feedback will be evaluated and eventually the piece of functionality will evolve into something fully featured.

Many of you probably know this picture comparing an MVP to a classic iterative approach.

I fully agree with the second row of the picture, but the important piece here is that the product evolves over time from a skateboard (something minimal to get from A to B) to a car (something pretty efficient and comfortable to get from A to B)! If you keep the skateboard for years without improving it you will end up with unhappy and frustrated customers.

Also, …. the agile teams who worked on the MVP will be disappointed that they cannot iterate on the product. It feels like an unfinished job. You might think that this is unimportant detail, but the contrary is true. It directly impacts the motivation and the engagement of the team. More about that topic in my post about what employees really motivates.

Of course, sometimes it is just fine to stop after the MVP is delivered.

• You might decide that the skateboard is just fine and customers are actually happy with the MVP for long-term… in that case: awesome; job done!
• You might learn that no customer actually wanted the skateboard and you retire it. Stop selling it. That is also a perfectly legit approach.

Getting feedback from the market and not iterating on it because you are already asking teams to work on the next top priority is what will hunt you down at some point future and has a negative impact on team morale.

So what’s the alternative? I think there are two, but really there is only one. And also…  maybe there are some that did not come to my mind …

1. Stop defining MVPs, deliver a fully featured product (how again do I know  what fully featured means??!)
2. Start focusing and embrace the MVP approach.

In my opinion, only #2 is the only long-term sustainable way to go. Everybody involved in the process of delivering software to customers should push for this. It is not easy because there are always so many important things that one could work on, but it will pay off over time because it allows for focus and the customer feels heard.

I’d love to hear your opinion on the topic!