The goal of an MVP is to maximize learning while minimizing risk and investment.

Your aim should be to validate your hypotheses and assumptions, and no more. Your MVP does not need to be perfect looking, fully featured, scalable, or even involve code.

In fact, it doesn’t need to be a version of your product at all! A common mistake I’ve heard entrepreneurs make is to say, “OK, let’s start with our final product and figure out what features to cut so we can quickly ship an MVP.” That’s the wrong mind-set—assuming that you already know what the “final” product should look like before it makes first contact with customers.

More importantly, that approach assumes that your greatest risk relates to product functionality. For many prospective companies, the biggest risks are less likely to be around product functionality and more likely around distribution, aligning pricing with value, and ability to work with resources and partners. The most important question that your MVP can answer may be something like:

Understanding which questions you need to answer first will help you to craft the most relevant MVP.

There is no strict definition of what comprises an MVP—at least not in terms of how many features to include or what type of technology to use.

MVPs are a means of validating your biggest assumptions and minimizing your biggest risks, and those will be different for every company and product. Sometimes (as you’ll see later in this chapter) they aren’t even real products at all.

Minimum means that you are focusing on how to learn with the smallest investment of time and resources. If you find yourself planning an MVP that will take months to build, it’s probably not minimum. If you can’t explain your MVP in a couple of sentences, it’s probably not minimum.

What you build also needs to be viable. You should think of viability in two ways: providing enough of an experience to show value to your customers, and providing enough information to you to prove or disprove a hypothesis. For example, some people think of buying Google AdWords as an MVP. I don’t consider that a good MVP because all it tells you is that a person clicked on your link—it doesn’t tell you why, and you can’t assume that clicking indicates that he is willing to spend money.

As companies have written about their successful (and unsuccessful) experiments, some patterns in MVP types have emerged. Some common MVP types^[55] include:

For each of these, we’ll walk through what it is, provide an example of how it might work, and explain what you can learn from this style of experiment. We’ll also describe situations where each type of MVP works well (hint: all of you can benefit from a Pre-Order MVP).

A Pre-Order MVP is where you describe the intended solution and solicit potential customers to sign up and order it before it is available. The Pre-Order MVP is not about gauging interest; it is about gauging commitment. Collecting email addresses or even survey data from prospective customers is not sufficient.

For any product or solution you wanted to build, you could create a website describing the problem you’re solving. A Pre-Order MVP will often collect a credit card number with the promise that it will not be charged until the product is available.^[56] In some enterprise situations, a letter of intent or agreement to roll out a pilot program may suffice as well.

Based on your costs and the investment required to pursue this product, you might decide that you will only proceed if more than a certain number of customers pre-order.

Kickstarter is a Pre-Order MVP. While it’s primarily described as a crowd-funding platform, it is also effectively validating customer demand and willingness to commit financially to a solution. Even when the customer pledge amount is substantially less than the eventual product price, it is still a very strong signal. There is extremely high friction in getting customers to pay anything at all!

If thousands of people pledge money for a product that doesn’t yet exist, that’s a strong validation of demand. If the project can’t raise its funding goal, that suggests that the project is not solving a real problem for a sufficient number of customers.

The Audience Building MVP is a literal application of customer development: it involves building up a customer base in advance of building your product. Once you’ve identified a prospective customer base, you create a gathering place for them to come and get information, connect with like-minded people, and exchange ideas. As you observe your audience, you can measure what content, features, or people they engage most eagerly with. This allows you to validate demand for the features or services you’ll eventually build. Once you’re ready to release a product, you don’t have to worry about publicity or distribution: you know exactly where to find your prospective customers.

Moz,^[57] 37Signals, and Mint.com are all examples of companies that used blogging to build up communities in advance of releasing their products. All three companies, by the time they launched a scalable product, had a captive audience of thousands of relevant customers. It’s unclear, however, whether these blogs were used as validation of the product concepts. (In other words, would Mint.com have decided to scrap its personal finance product if it was unable to attract enough readers to the MintLife blog?)

A clearer example of an Audience Building MVP as validation is seen in the recently launched Product Hunt website, which provides a leaderboard of the best new products every day. Founder Ryan Hoover invested just 20 minutes on an MVP to assess his potential audience. Hoover used Linkydink, a way to share links via email, to create a simple mailing list and invited a few dozen people. If he didn’t see more mailing list signups, or if activity on the list petered out after a few days, Hoover was ready to conclude that the idea wasn’t worth pursuing. Only once he saw a rise in signups, activity, and enthusiasm did he start building a rudimentary site. Product Hunt is a side project for Hoover, but in its first two months of life has already attracted over 4,000 users.^[58]

Named for the concierge who helps you out in a hotel, in a Concierge MVP, manual effort is used to solve the customer’s problem. The customer knows that you are manually providing the solution. In exchange for a large investment of your personalized attention, she agrees to provide extensive feedback. The Concierge MVP allows you to offer the experience of using the product to customers before you actually build it.

Imagine that you saw an opportunity in connecting parents with customized, low-cost, educational activities for their kids. A Concierge MVP might entail contacting a half-dozen parents and having conversations with them about their children and how they choose activities for them. Armed with that information, you could manually research local activities and write up a list of recommendations for each parent.

This solution is not scalable at all: it would take hours per customer per week to provide your solution without automation. But what you learned during this intensive manual phase would dramatically reduce your risk.

You’d validate demand by following up personally to see which parents actually attended the suggested activities. You’d prioritize features by asking which pieces of information were critical (or missing) from your list. You might discover that your concierge clients consider this a “nice-to-have” service that they’d be unlikely to pay for. You would probably also discover that the criteria that parents use to choose activities for their children are not what you expected. All of this learning could occur before you started designing your site, writing code, or filling a database with information.

In a Wizard of Oz MVP, you provide a product that appears to be fully functional, but is actually powered by manual human effort. Unlike the Concierge MVP, the customer is not aware that a person is carrying out the tasks normally handled by software or automated processes.

Imagine that you want to solve the problem of allowing agile companies to localize their software more frequently. A Wizard of Oz MVP might present a few customers with an online dashboard where they could submit new text to be translated. But instead of an automated translation, you might have one or two Spanish speakers sitting in front of their computers waiting for a submission and quickly typing in translations on the fly.

Like the Concierge MVP, this solution is not scalable. But you could watch how customers interact with your fake dashboard, ask about the translation and turnaround speed and quality, and assess how much they would be willing to pay for your service.

A Single Use Case MVP is a working product or piece of technology that focuses on a single problem or task. This allows you to validate a single hypothesis.

Don’t confuse “small” with “shoddy”—the Single Use Case MVP is not a license to build a bunch of features as quickly as possible by skipping over design and user experience. The point is to do one thing and do it well. (Remember, the “viable” part of MVP means you need to provide value to the customer!)

Imagine that you wanted to solve the problem of companies spending too much time on customer support. A Single Use Case MVP might entail selecting a single channel and type of problem to start with. For example, you might allow customers to create templated email responses to messages containing a set phrase like “cancel my account” or “update billing address.”

This solution is scalable, but it’s only a fraction of what you envision. It doesn’t help with email that doesn’t contain a set phrase, and it doesn’t help with phone or live chat support. But it allows you to validate that customers are willing to use and even pay for the partial solution. As these early customers demand more features, you can use their requests to help you prioritize which parts of the solution you build next.

With a Single Use Case MVP, your customers will complain, and that’s a good thing. It means that customers have gotten some value from your product and they’re ready for it to deliver more value.

If the customers using a Single Use Case MVP aren’t complaining, it doesn’t mean that they want more features. It means they aren’t even seeing the potential for value. Throwing more features at them won’t solve that problem. Instead, it’s time to figure out why your highly focused hypothesis was wrong and how you can shift direction to get closer to what customers want.

Case Study: Hotwire

Hotwire was facing a challenge: its hotel bookings site was showing its age after 10 years of new features and workflows.

Product manager Kristen Mirenda and interaction designer Karl Schultz were able to form a clear hypothesis after observing customers interacting with Hotwire.com.

“Customers trying to use Hotwire to book a hotel abandon the process because they cannot figure out where their prospective hotel will be located. Map-centric search results should help increase hotel booking conversions.”

But that would require a massive change to the interaction of the current Hotwire.com site. No one was comfortable making a change of that magnitude overnight. “Hotwire’s hotel bookings bring in a large portion of the company’s revenue,” explains Mirenda.

Map-based search results on a shadow site

Instead, Mirenda, Schultz, and lead engineer Jim Tay led an effort to create a “shadow site” that would allow them to test their hypotheses on a very small percentage of Hotwire’s existing traffic.

They built an MVP version of the site centered around map-based search results. “The first version had no design, and you couldn’t sort or filter or even revise your search. None of those things mattered for our hypothesis around map usage.”

The site was designed so that a variable percentage of Hotwire’s normal traffic could be redirected to the new design. People who landed on the new site did not realize that they were part of an experimental group, though the new design did include a link to offer feedback (see Figure 7-1).

The first version of their MVP launched to just 1% of the customers coming to Hotwire.com. “It definitely put us outside our comfort zone to put something like that out into the world. We built in the ability to shut it off within hours, just in case,” says Mirenda.

Figure 7-1. Version 1 of Hotwire’s MVP lacked features, but validated the hypothesis that map-based search results provided a better customer experience and could ultimately be more profitable

Iterating on the MVP

Customer feedback on the experimental Hotwire site was mostly negative, focused on the missing sort and filter functionality, not on the big map in the center of the screen. And people were still booking hotels! Map engagement was up, and conversion for the experimental group only went down 17%—not bad for a completely unoptimized, feature-poor MVP.

Revising the MVP to solve pain points

As soon as the team had enough data to guide the next iteration, they turned off the 1% experiment and started building to solve for the next biggest pain points: lack of sorting and filtering. With each successive release, performance improved and the team was able to increase the size of the experimental group and get faster results.

Nonetheless, Mirenda and Schultz struggled a bit for acceptance within the company. Mirenda says, “As the first team to go lean, we hit all the potholes! For each mistake, we had measured validation for what not to do the next time—but that’s not what people were accustomed to. People weren’t used to hearing customer complaints—even if they didn’t affect overall usage.” Schultz agrees, “The benefits [of working lean] have to be shared widely so people can understand the value.”

The new site gains traction

Gradually the percentage of people who saw the new Hotwire site was at 50%, and performance caught up to the original site.

Hotwire has now adopted the new site with map-based search results for both the United States and international audiences. As the team continued to optimize, conversion rates continued to increase. Hotwire is a subsidiary of Expedia, which earned $4 billion in revenues in 2012.

The Other People’s Product MVP is where you use parts of an existing product or service to validate your ideas. In some cases, this is a variation of the Wizard of Oz MVP, where you may offer your customers a solution and then manually use a competitor’s tools or infrastructure to fulfill it. In other cases, it may involve using an existing API or framework to more quickly build a solution.

The defining feature of the Other People’s Product MVP is that you are piggybacking on competitors who are already solving the problem, as a way to more quickly learn and validate ideas.

For example, if you wanted to solve some of the problems with the taxi industry, you might sign up to be an UberX driver. In doing so, you’re not only spending your time but even making money for your competition! However, you would quickly learn which aspects of the service mattered and could talk to customers in order to identify opportunities for differentiation. By relying on an existing product’s marketing and infrastructure, you could hugely reduce the cost of learning.

In the beginning of this chapter, I talked about the importance of identifying your highest risk factors. Hopefully you built an MVP that helped you to answer some of your most pressing questions around distribution, value, business model, and functionality.

Most likely, at least some of your assumptions were shattered when your customers actually interacted with your MVP. Perhaps customers loved the functionality but balked at your price point; perhaps they were unconvinced by the prospective value proposition. The good news is that you almost certainly know more about your market and product than you did before.

Armed with your new knowledge, look at your hypotheses again. Which ones have you validated? Which ones were incorrect? For each incorrect hypothesis, what information have you gained about why it was incorrect? Based on this updated information, you can now formulate a more educated set of hypotheses.

In some cases, you may want to conduct customer interviews with a different audience. In others, it may be more appropriate to devise a different MVP that helps you learn about other aspects of your business.

There is unfortunately no magic dividing line between “yes, you’ve validated your MVP and your product will be successful” and “no, back to the drawing board.” It’s all one big gray area where you gradually gain more and more evidence that you’re on the right track.

For this reason, there is no point where you should stop doing customer development entirely. Even once you’ve made big “irreversible” decisions (we’re definitely building this service, we just hired an engineer, we quit our day jobs), you will benefit from continuously learning and validating.

In the next chapter, we’ll talk about ways to use customer development after you’ve already built a product, collected revenues, and developed relationships with your customers.