At my company, I frequently hear the term "MVP" being used by PMs, developers, and designers alike. What exactly does this mean, and why is it so important for agile software development? MVP stands for 'minimum viable product'. It is a development technique in which a new product gets just enough core features for it to function.
The goal of the MVP is to quickly get feedback from customers and improve the product without having to invest a lot of time or money that could potentially go to waste. From the customer's interaction with the MVP, the product can then go through cycles of improvement that result in a full-featured product that customers will love.
The term MVP is by no means boxed-in to just software development and code. Take a look at some famous examples of tech entrepreneurs using a minimum viable product to validate and improve upon their early products:
- Zappos founder Nick Swinmurn took pictures of shoes at a shoe store and posted these pictures on his website. Whenever a customer ordered shoes on his site, he went back to the store to purchase those shoes, then packed and shipped the shoes to the customer.
- Dropbox founder Drew Houston created a simple video demoing how Dropbox worked. The team initially faced challenges pitching to potential investors because these investors couldn't see how the product worked. The video, narrated by Drew, visually demonstrated Dropbox's usefulness.
- The three founders of Airbnb piled air beds into their apartment and put up an ad prior to a large political convention. People actually responded to the ad and ended up renting the air beds.
Again, the minimum viable product is more important as a learning tool rather than being about the product itself - it's to first validate whether customers will use the product, then to highlight areas of refinement and additional useful features.
What I described above about the MVP also holds true in software and product development. The MVP should allow the team to collect the maximum amount of user data and feedback with the least effort. The challenge is defining what an actual MVP should include since there are so many stakeholders and teams involved with conflicting priorities.
It's a good practice to ask around the PMHQ community to get an idea of what other product experts consider to be a good MVP.
How does this translate to product management? A PM often deals with limited time and money. As a result, it's wise to focus on building a simple MVP and iterate based on initial customer feedback. The PM needs to prevent scope creep and manage stakeholders, driving home the point of putting out a minimum viable product in the first place. Instead of risking overspending on features that don't end up being used, building a product with just the core features will help the team quickly learn and make adjustments along the way to the final product.
Looking to create your own MVP for a side project? You might want to check out our popular course: One Week PM where you'll learn the fundamentals of product management, how to launch your own MVP for a side project, and how to dominate product manager interviews.