What is a Minimum Viable Product?
A minimum viable product (MVP) solves the user’s problem in the most basic way. MVPs allow product teams to cost-effectively learn about their users so that PMs can focus on building the right thing.
Many of the products you use every day started as MVPs. Inside this guide, you’ll find examples of how PMs validated their ideas before building their MVP and determine which features make it into the MVP. From learning and iterating on this process, PMs can build stronger MVPs that form the basis of the world’s most loved products.
Let’s face it, MVPs are confusing. Anaid Chacon @ Dropbox doesn’t think the “V” is very viable in Product to Product, a podcast for / by product people. Find out why.
Why build minimum viable products?
Before any serious development work goes in, PMs use MVPs as a key part of their product strategy to validate the product and to mitigate risk. Instead of going to market with a product that’s been heavily developed, product managers build and ship a barebones version of the product to test the waters with their target users. Minimum viable products stress the importance of learning about its target users and delivering value.
MVPs can be built & shipped without investing a ton of time, money and development resources. In fact, not only do MVPs save time and money, but they also help PMs learn about their target users, focus on their core solution, and avoid the dreaded feature trap (when a product tries to do too many things at once and ends up not doing any one thing well).
Lastly, MVPs are a vehicle for achieving product/market fit. The metrics and learnings gained from real users in your minimum viable product should translate into product improvements that make strides towards product/market fit.
Before you build an MVP, validate
Before building and shipping an MVP, PMs often validate that their product has a promising customer base/audience. This is commonly done via A/B tests on a page dedicated to their product (landing page), videos or a crowdfunding campaign.
Real life examples:
Dropbox's video validated that customers wanted the SaaS product—they posted a demo video to Hacker News and got lots of immediate feedback via comments, and later invited viewers to a simple landing page to capture emails, which grew their beta list from 5,000 to 75,000 overnight.
Buffer's simple landing page detailed how it would help users by scheduling tweets. It also collected emails to validate customer interest in their product. They later even added a pricing page and also validated that people were willing to pay for the service.
Does $$ = validation? Maybe. If users are willing to click on a “pay” button or enter their credit card information, you have strong validation for your product idea. But it’s worth noting that not all MVPs charge as a tradeoff for the learnings they get from users—your pricing structure will depend on your product.
As you learn from and iterate on your MVP, you may continue to offer your “minimal” product for free, but then charge for add-on features. Experimenting with different payment models will help you determine what you should be charging for, and how much people are willing to pay for it.
What should go into your minimum viable product?
“Identify the most valuable problem you can solve for the market, ship something that validates how right/wrong you are, rinse and repeat. The “something that validates how right/wrong you are” is the MVP.”
- Rob Bayley, Director of Product @ Roadmunk
The process is more iterative than linear (i.e. identify the problem → solve the problem), but each time you learn from and iterate on your product, you get closer to finding product/market fit.
To do this, distill your user problem and the proposed solution into their most basic forms. (Many organizations use Toyota’s 5 Whys approach to do this.) Next, narrow in on the features that solve that one key problem. The MVP must directly address that problem—no other features matter.
Determining the features that belong in your most basic solution is also a matter of prioritization. PMs say prioritizing features is one of the most difficult parts of their job.
There are many frameworks to do this—the MoSCoW method is one way you can sort your feature wishlist into must haves, should haves, could haves and won’t haves. Must-haves are the non-negotiable features that need to be part of the product for it to function and are the only features that should be in your MVP. Your should-haves, could-haves and won’t-haves are dependent on their importance in relation to time-sensitivity, the availability of resources, or the impact on customer satisfaction.
Prioritization doesn’t have to be a pain. We’ve rounded up the seven of the top prioritization frameworks in one place for you here.
Finding your MVP’s core features can be validated by data. You can bake in tests to validate whether a feature is a “must-have” before you even start building your MVP.
For example, you can A/B test a product landing page by showcasing 4 features to one user set and 5 features to another. If users are still willing to sign up with a smaller feature set, maybe that fifth feature isn’t a must-have feature right now. When pricing gets added to the mix, you can also experiment with showcasing four vs. five features for the same price. (Remember to only test one variable at a time so that it can be isolated.)
Whichever features you decide on, your MVP’s feature set needs to offer value. Ensure that whatever you ship is functional by itself—if it was never improved again, it would still be useful to your customers.
This well-known diagram “Start with the skateboard” by Henrik Kniberg, an ex-Spotify agile/lean coach, illustrates this well—in the top half, products one through three are neither feature-complete (they need important features to be useful to customers,) nor narrative-complete (none of them solve the user problem—to get from A to B). None of the products can confirm whether the solution is effective at solving the user problem until the fourth step. In the second row, your user consistently gets usable products that will help your product team learn about your users quickly and on the cheap.
Examples of MVPs
After deciding which features will make it into your minimum viable product, there are a few different ways you can package and ship these features, like in a concierge or “Wizard of Oz” product.
One example of a successful MVP is from Spotify, who wanted to ship a bufferless music streaming experience. They developed a simple desktop app with an interface that included playlists, and multiple buttons to hit play/pause button or go to the previous/next song. They put Spotify into the hands of their friends and family, and got validation from their “users” that:
- People are happy to stream (as opposed to own) music, and
- The technology was feasible.
Their working prototype helped convince music labels as well as investors and the rest is history.
Concierge products are MVPs that simplify a solution by replacing automated processes with manual ones, where users receive the white-glove treatment. The people serving up the solutions are the product, but it’s not scalable.
One of the most well-known concierge products is the 2007 version of Airbnb. During a design conference, its co-founders listed their SF apartment to help cover rent. On a barebones website, they opened up their loft as cheap accommodation to guests. They uploaded pictures of their apartment, set up three air mattresses and promised breakfast. And they got 3 paying guests. Their MVP validated their assumptions that people would be willing to pay in a stranger’s home rather than a hotel, and the users knew that the people behind the website were the ones offering up their home.
Wizard of Oz products give users an experience that feels automated but is actually similar to concierge products since the solution to the user problem is delivered manually. Like the Wizard of Oz, it’s actually the team hiding behind a “mask” (the product/website) and solving the user problem, not the product itself.
For example, Zappos opened up as an online retailer selling shoes, but each time a user placed an order, Zappos would physically go a shoe store to buy the shoe and then manually ship it to the user. The user was served a seemingly automated experience (where everything is served up online), but it was real people delivering the experience.
Learn from and iterate on your minimum viable product
Your MVP isn’t one and done, and there won’t ever be a final version of your product. Building-measuring-learning is a key part of agile methodology, and the learnings you’ll get after your MVP is in the hands of your users will either help you confirm your product position or push you in a different direction.
To determine what’s next, look at your success metrics—they’ll depend on your product. Ask yourself, “Which metrics would be moved if we were solving our user problem?”
Some examples of success metrics include confirming your user's perception of the most valuable features via a feature-flow analysis. You might also look at repeat users, or concrete metrics like whether your product reaches 10,000 weekly users or contracts $10,000 every month in signups. Based on your own metrics, determine whether there’s enough interest in your idea to keep going. Does the data show that your business can run off this product?
If your product gets traction toward solving your users’ problem, keep going and repeating the feedback loop.
“You generally tend to drag the failures. The successes show themselves up pretty quickly.”
- Anaid Chacon, Product Manager @ Dropbox
If not, getting customer feedback on your MVP will help you pivot your product until you get to product/market fit. Just repeat the feedback loop, refine your idea and keep improving your product.
Iterating or pivoting is a normal and very important step in the entire MVP process. Your team now has valuable knowledge about what doesn’t work and can course-correct, reset, or test a new hypothesis.
Anyone can launch a minimum viable product, but the most successful PMs are able to take user insights and learn and iterate on that product. Done right, building an MVP will save you time, money and development resources when you take the time to learn about your users.'
Ready to take product planning to the next level? Create + share beautiful roadmaps with our ready-to-use templates.