Make MVP a VIP (Very Important Practice)

MVP, which stands for Minimum Viable Product, is a concept that became widespread as many companies began to adopt Lean Startup principles and practices.  Much like other popular movements (Agile for example) Lean Startup introduced ideas, such as the Minimum Viable Product, that can be very powerful and helpful for organizations, but that can also cause a great deal of friction if not understood and used correctly. In some of the companies I have worked with, the term MVP had actually begun to develop a negative connotation and caused the companies to avoid using it when it could have helped the most. In this article I want to revisit the idea of an MVP and talk about what it is and why it is an important practice.

​What is an MVP?

At a surface level, an MVP is the minimum amount of functionality that a product needs to have in order to learn from the users it is meant to serve. This MVP concept is a small piece of the larger lean start up mentality that focuses on finding ways to obtain real and valuable feedback as quickly as possible in order to avoid wasting money and time designing or building the wrong thing (validated learning). Based on the feedback that early users provide to an initial viable version of a product, companies can determine if they are on the right track or if they need to change direction. In the Lean Startup, author Eric Ries provides some great examples of companies that invested a lot of time and money based on their assumptions of what their users wanted, only to find that many of these assumptions were wrong. They waited to release their product so that they could add in a bunch of features that the users really didn't end up caring about. Afterwards, the product team realized they could have released sooner with fewer features and would have been able to focus earlier on more valuable features.

Depending on the stage your company or product is in, an MVP can take on different forms. One important note to make, however, is that an MVP is not meant to be a low quality product. Many of the organizations I've seen that are hesitant to employ an MVP mentality assume this is always the case and end up waiting too long to release their product to market. ​

​MVP as a Practice

The term MVP is normally used as a noun (it does have the word "product" in it after all). In this article, however, I use the word practice very intentionally as this is not only a valuable tool, but a practice that teams can get better at the more they try it. In this sense, MVP is more of a mindset than an output, that involves looking at a problem and figuring out the simplest way implement an experiment and learn as quickly and effectively as possible. 

This mindset acknowledges upfront that an initial version of a product or feature is unlikely to fully hit the mark (and that's ok, remember rework is inevitable). Teams that learn to approach problems this way and get comfortable with that fact, will then be able to turn uncertainty and feedback into advantages as opposed to risks. 

A good illustration of MVP in practice can be found in a training exercise that has become popular as organizations look for ways to innovate and respond to rapidly changing market conditions: the Marshmallow Challenge (if you have never heard of it I recommend checking out this TED talk which gives a good overview of the challenge and some of the key takeaways). In this exercise, teams of people are asked to construct the tallest structure they can using only raw spaghetti, string, and tape. The challenge part comes from the fact that the structure also needs to be able to support the weight of a marshmallow. There's a lot to learn from this exercise around rapid prototyping and design thinking, and in order to succeed, teams need to take an MVP approach as opposed to designing the perfect structure up front. Teams that do well quickly put together simple structures with their materials that allow them to get immediate feedback from their end user (the marshmallow) and change direction as needed. 

MVP in All Roles

In order for a team to really be able to take advantage of all the benefits of an MVP mindset, every role on the team needs to embrace it. One of the great things about Agile, Design Thinking, and Lean Startup methodologies is that they encourage cross-discipline collaboration. No responsibility falls solely on any individual and team members are encouraged to work on things that would normally be outside of their domain and comfort zone (including the practice of identifying and creating an MVP).

For many people this can be a completely new way of working and can take time and practice to adjust to. At first, teams will run into many of the issues and friction that have been present in methodologies such as agile development since their beginning. Product Managers and Product Owners will want to get as many features as possible in the shortest amount of time. Business Analysts will want to put together a full list of all the requirements that will be needed to meet market demands. Designers will want to create a full-fledged and beautiful solution. Developers will want to create a robust solution that accounts for all sorts of scenarios and edge cases. It is also very likely that nobody will want to launch until everything is just right.

With that being said, bringing everyone together across disciplines allows the team as a whole to have more of a learner mindset and ask questions that might seem obvious or too simplistic. If this questioning and curiosity is encouraged and practiced, teams will begin to see MVPs in places that they would have never thought was viable based on the context and experience of their role. For example, developers may ask a product owner if a much simpler version or piece of a feature would be enough to meet a user's needs. Or, a marketing specialist might ask a designer if they can create two lower fidelity designs, as opposed to one fully fleshed out version so they can run an a/b test.​ This combination of perspectives along with an MVP practice will allow teams to find quicker ways to learn from their users and find the work that is going to be most impactful to them.

How do you feel about the idea of an MVP? Have you found the term to have negative connotations within your organization?