Why MVPs?
In all my time building products and working with startups, I have never found a more powerful, versatile tool than the MVP (or Minimum Viable Product for those who are new to this concept). Unless you have unlimited time, funding, and confidence, you should begin your startup journey with an MVP.
MVPs will help you answer the key question that every startup faces, “What should I build and for whom?” More specifically, they can minimize the four key risks that every new product faces:
Value risk — Will customers choose to pay for your product (or become regular users if the product is free)?
Usability risk — Is your product designed so customers can use it efficiently and enjoyably?
Feasibility risk — Can your team build and maintain the product given your available time and resources?
Business viability risk — Does your product support the company’s business objectives?
But after years of designing, building, and testing MVPs – and getting tons of questions about the process –– I haven’t found a concise, authoritative guide explaining how to go about this. So here is my attempt at providing such a resource.
What is an MVP?
You’ll find lots of definitions for the term “MVP” and this is a big source of confusion. So here’s a simple definition that has held up for me over the years:
An MVP is simply a prototype. BUT, as the name implies, it is“viable.”
OK, but what do we mean by viability?
The MVP can be experienced by your target customer without the kind of hand-holding or explanation that is required for a traditional prototype. In effect, it is a simulation of the experience they will have when using your product.
The MVP is designed in such a way that it is capable of reliably testing at least one hypothesis (we’ll get to this concept shortly).
And of course, MVPs are minimal. How minimal? As minimal as you can make them and still test at least one hypothesis. In fact, some of the best MVPs don’t involve writing a single line of code.
How can this be? Let’s take an example. Suppose you want to test the following hypothesis: “Twitter users would be interested in a product that enables them to queue up tweets for later posting.”
This is exactly the hypothesis that Buffer.com started with when they designed their MVP, which consisted of two static web pages. The first page described the product and displayed a link to pricing information. When users clicked on the pricing link, a second page explained that the product wasn’t ready yet and displayed a field for the user to add their email to a waiting list.
These two simple pages were enough to validate Buffer’s hypothesis and convince them to build a second MVP to test pricing. Ultimately the company went on to launch a very successful product.
Types of MVPs
The Buffer example is known as a landing page MVP. Here are some other popular types:
Wizard of Oz — This approach combines minimal amounts of software on the front end with humans on the backend to fulfill customer requests. Customers interact with the software without realizing that most of the functionality is being performed by people. A famous example is the Zappos MVP.
Concierge MVP — This approach is identical to a Wizard of Oz MVP, except it uses little or no software and the customer is fully aware they are interacting with a human.
Piecemeal MVP — In this approach, existing software products are used to simulate the experience of the final product. For example, if you are planning to build a group dieting app, you might create a Facebook group to test hypotheses about peer-to-peer interactions. With piecemeal MVPs, you can also combine multiple software products to create an even more realistic simulation.
Hypotheses Definition
When you test an MVP, you are running an experiment. Its purpose is to test hypotheses about the problem you are targeting, your proposed solution, or both. To define your hypotheses, follow these steps:
Determine which risk areas to focus on — Decide which of the four risk areas your MVP will assess. While you can assess any type of risk with an MVP, they are best for assessing value risk and business viability risk. Unless your MVP has a high degree of fidelity or is designed to solve complex technical problems, you should not use it for assessing usability or feasibility risk.
Define your hypotheses — Define at least one hypothesis to test. You can test as many you like but we recommend a limit of five to keep things manageable. Each hypothesis should target at least one of the risk areas you chose. Very important: always test your riskiest hypotheses first. Otherwise, you may be fooled into thinking your MVP was successful, only to find out later that other, bigger risks went untested.
Define your validation criteria — This is how you will determine whether a hypothesis was valid or not. For example, with the Buffer MVP, the percent of visitors who sign up for the waitlist could be one of our validation criteria.
Define your target values — This is the threshold for each validation criteria that you feel will validate your hypothesis. In the Buffer example, we might decide that a 25% conversion rate is necessary to validate the hypothesis.
Here are examples of hypotheses from an actual MVP I designed to test an employee training solution:
MVP Testing
Once you’ve designed your MVP and defined your hypotheses, the next step is inviting people to use it. Unless you need a large, statistically valid sample, a few dozen is probably sufficient. Here are some suggestions on recruiting:
Social media — Recruit friends, family, colleagues, and strangers on Facebook, Twitter, Discord, Linkedin, and wherever else you hang out online.
Facebook ads — Facebook is an excellent way to affordably target specific market segments. In addition to recruiting, you can also experiment with potential marketing tactics by varying ad copy and design. By tracking ad spend and conversions, you may even be able to forecast your customer acquisition cost.
Search marketing — If you envision users someday finding your product through search, recruiting MVP users through search ads can be very effective and affordable.
Lastly, before launching, test your MVP with teammates, friends, and family to make sure the user experience is as expected and you are able to capture the necessary data to validate your hypotheses. Even then, you may want to invite customers slowly to make sure everything is working and you have time to pay adequate attention to the incoming data.
Additional Points to Consider
Multiple MVPs are common — Your first MVP may not give you the confidence to start building your product. In that case, feel free to keep experimenting. You can iterate on an existing MVP by making design changes or changing the recruiting criteria. Or you can launch an entirely new MVP.
MVPs are not a silver bullet – Multiple iterations take time (and sometimes money). And with each iteration, you may get diminishing returns for your efforts. Therefore, you may find yourself at a crossroads where you’ll have to decide whether to pursue or cancel your idea without complete data.
Maintain a minimal mindset — The goal of any MVP is to maximize learning at the lowest possible cost. As you design your MVP, always ask “Is there a way to make this even simpler?”
Don’t get hung up on definitions — You will find lots of debate about the definition of an MVP and the different types of MVPs. Don’t let this stop you from forming hypotheses and finding creative ways to validate them.
How’s that for a guide? Let me know in the comments if I succeeded or if you have further questions!
Helpful Resources
Check out these articles for more info on MVPs and related concepts.
Eric Reis, Minimum Viable Product: a Guide
Silicon Valley Product Group, Viable Product vs. Minimal Product
Steve Blank, Perfection by Subtraction
Open Classrooms, The Four Types of MVP
Comments