If you’re a software product manager, chances are you’ve had to build MVPs and MVFs (minimum viable features). A minimum viable product is one that 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.
MVPs should give PMs the answers to the questions:
- What’s the minimum number of features your product needs to have in order to solve a core user problem?
- How can the product team identify only the most beneficial features that they can then build upon using analytics and usage data?
- What’s the best way to discover validated learnings about customers using the least amount of resources?
But how do PMs arrive at an MVP that answers those questions? It all depends on how deeply you understand the customer’s experience as they attempt to solve a problem, fulfill a need, or complete a task.
One way to get to this level of depth into user motivation and experience is by using a user journey map (we’ll get into it later in this guide).
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.
What does viable mean in the context of product development?
Literally speaking, viability just means when something works as intended. In the context of an MVP and product development, however, that definition is slightly different. Instead, a viable product is one that customers are willing to use regularly because it solves a specific need they have.
Note that viable doesn’t necessarily mean “willing to pay for this product” but “willing to use it regularly because it solves a problem they face.”
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. The goal of building a minimum viable product is to learn about what the target users consider as valuable.
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.
Identify the right opportunities with a user journey map
User journey mapping is a simple method for discovering the problems worth solving faced by users. It’s a useful mapping technique used by UX designers, marketers and product managers to determine all the actions a user takes to reach an end goal.
What a user journey map looks like depends on the individual type of product or project your team is trying to build. Generally speaking, user journey mapping involves a few steps:
- Identify the scope you’ll focus on. This can be as high-level as an overview of the end-to-end user experience, or a specific feature or interaction.
- Define the user, the scenario and the specific goal the user is trying to achieve. What will a successfully completed goal look like at the end of the journey? What are the expectations users have of the experience?
- Write down the actions and key activities (phases of the journey) needed to complete the action/experience. This includes any paint points and obstacles that get in the way of achieving that task successfully.
- Identify the opportunities. In each of the phases, are there any pain points that can be turned into a solution or a potential feature idea?
- Prioritize the order in which those features will be built and assign the work to be done.
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 their 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 are interchangeable with user research.
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 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 you learn about them without overspending.
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. The rest, as you know, 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 for 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. However, they’re 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 to 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 in agile product orgs, 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 the right user problems?”
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 iterate those MVPs. When done right, building an MVP will save you time, money and development resources.
Ready to take product planning to the next level? Create + share beautiful roadmaps with our ready-to-use templates.
Our guide to product ideas
Product managers use a wide array of sources of information that influence the ideas and features they’ll develop. So, with that in mind, we built a guide to help product leaders develop actionable strategies for capturing, organizing, processing and planning the product ideas that yield the most impact and value for an organization.