The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback

by Dan Olsen

The main reason products fail is because they don't meet customer needs in a way that is better than other alternatives.

The framework, which I call the Product-Market Fit Pyramid, breaks product-market fit down into five key components: your target customer, your customer's underserved needs, your value proposition, your feature set, and your user experience (UX).

The Lean Product Process consists of six steps: Determine your target customers Identify underserved customer needs Define your value proposition Specify your minimum viable product (MVP) feature set Create your MVP prototype Test your MVP with customers

“Product-market fit means being in a good market with a product that can satisfy that market.” My definition of product-market fit—which is consistent with his—is that you have built a product that creates significant customer value. This means that your product meets real customer needs and does so in a way that is better than the alternatives.

A market consists of all the existing and potential customers that share a particular customer need or set of related needs.

Customers are going to judge your product in relation to the alternatives. So the relative degree to which your product meets their needs depends on the competitive landscape.

The real-world manifestation of software products that customers see and use is the user experience (UX), which is the top layer of the Product-Market Fit Pyramid. Beyond software, this is also true for any product with which the customer interacts. The UX is what brings a product's functionality to life for the user.

a market is a set of related customer needs, which rests squarely in problem space. A market is not tied to any specific solutions that meet those needs. That is why you see “market disruptions”: when a new type of product (solution space) better meets the market needs (problem space).

We were trained to first focus on “what” the product needed to accomplish for customers before getting into “how” the product would accomplish it. You often hear strong product teams distinguishing between the “what” versus the “how.” The “what” describes the benefits that the product should give the customer—what the product will accomplish for the user or allow the user to accomplish. The “how” is the way in which the product delivers the “what” to the customer. The “how” is the design of the product and the specific technology used to implement the product. “What” is problem space and “how” is solution space.

Lean product teams articulate the hypotheses they have made and solicit customer feedback on early design ideas to test those hypotheses. This approach is the essence of Lean—and was actually first advocated for years ago by practitioners of user-centered design.

You've got to start with the customer experience and work backwards to the technology. You can't start with the technology and try to figure out where you're going to try to sell it.… As we have tried to come up with a strategy and a vision for Apple, it started with: What incredible benefits can we give to the customer? …Not starting with: Let's sit down with the engineers and figure out what awesome technology we have and then how we're going to market that. And I think that's the right path to take.

This internal testing tactic where you use your own product is called “dogfooding.”

behavior resulted in dissatisfaction for customers. It's true that customers aren't going to lead you to the Promised Land of a breakthrough innovative product, but customer feedback is like a flashlight in the night: it keeps you from falling off a cliff as you try to find your way there.

The important interface between problem space and solution space occurs between your value proposition and your feature set.

Unlike customers and their needs, which you can target but can't change, value proposition is the problem space layer over which you have the most control.

“Customers don't care about your solution. They care about their problems.”

You can develop hypotheses about your target market, but you won't truly know who your customers actually are until you throw your hook into the water and see what kind of fish bite. Once you have a product or a prototype to show customers, then you can gain clarity about the target market you're attracting.

Demographics are quantifiable statistics of a group of people, such as age, gender, marital status, income, and education level.

If you are targeting businesses, you'll use firmographics instead; these are to organizations what demographics are to people, and include traits such as company size and industry.

Psychographics are statistics that classify a group of people according to psychological variables such as attitudes, opinions, values, and interests.

When you use survey data, it is critical that you not use averages of the collected data to populate your persona. You want your persona to represent a real person and should not design your product for some nonexistent “average” customer. As Cooper illustrates, “The average person in my community has 2.3 children, but not a single person in my community has exactly 2.3 children.”

To be useful, a persona should be pragmatic and provide useful information that can help inform product design decisions.

One of the easiest ways to tell that a product team is starting with the solution space is that instead of articulating customer benefits, they list product features.

As with well-written Agile user stories, benefits should be written from the customer's perspective (using “I” and “my”). You'll also notice that each benefit begins with a verb: help, check, reduce, maximize. A benefit conveys value, which means it's doing something for the customer. Finally, many of the benefits speak to increasing something that's desired (tax deductions) or decreasing something that is not desired (audit risk, time required to accomplish a task).

As you talk with customers, you can keep asking them, “Why is that important to you?” until it doesn't lead to any new answers. This helps elevate the discussion from more granular, detailed benefits to higher-level benefits. This market research technique is called “laddering”; as you ask more questions, you are climbing up rungs on a ladder of related benefits. As you move up, ladders can converge, until you eventually reach the top of that particular benefit ladder.

As entrepreneurs, product managers, developers, and designers, we love to spend our time coming up with cool new feature ideas and designing great user experiences. However, those items sit at the top two levels of the pyramid of user needs. First and foremost, the product needs to be available when the user wants to use it. After that, the product's response time needs to be fast enough to be deemed adequate. The next tier pertains to the product's quality: Does it work as it is supposed to? We then arrive at the feature set tier, which deals with functionality. At the top, we have user experience (UX) design, which governs how easy—and hopefully how enjoyable—your product is to use. As with Maslow's hierarchy, lower-level needs have to be met before higher-level needs matter.

importance is a measure of how important a particular customer need is to a customer.

Satisfaction is a measure of how satisfied a customer is with a particular solution that provides a certain customer benefit. It indicates how well that solution meets their needs. Different products will have different levels of satisfaction for the same customer, and the same product can provide different levels of satisfaction to different customers.

There is not much point in pursuing low importance ideas, regardless of the satisfaction level, since they just won't create enough customer value. You want to address high importance customer needs.

the scale for the satisfaction axis is defined by the solutions that exist in the market—more specifically, by the “high water mark” of current solutions. When better solutions that deliver more customer value come out, the upper value on the right side of the scale gets redefined, shifting everything to the left. In contrast, the importance axis is more stable. The customer need to listen to music on the go was a constant throughout the four waves of new technical solutions across over 50 years.

A bipolar scale goes from negative to positive, whereas a unipolar scale goes from 0 to 100 percent of an attribute. It's usually best to measure satisfaction using a bipolar scale; since people can be satisfied or dissatisfied, a negative score makes sense. In contrast, importance is just a matter of degree—without any negative value—and therefore better measured with a unipolar scale.

middle. Significant research has been performed on the reliability and validity of various scales, and it is generally agreed that 5-point scales are best for unipolar and 7-point scales are best for bipolar—which explains why I recommend the choices above.

delighters. With performance needs, more is better. As the need is more fully met, the resulting customer satisfaction increases. Say you were shopping for a car and considering two different models. If they were identical in all aspects but Car A had twice the fuel efficiency (e.g., miles per gallon) of Car B, you would have a preference for Car A. Fuel efficiency is a performance benefit for cars.

Must-have needs don't create satisfaction by being met. Instead, the need not being met causes customer dissatisfaction.

Delighters provide unexpected benefits that exceed customer expectations, resulting in very high customer satisfaction. The absence of a delighter doesn't cause any dissatisfaction because customers aren't expecting it.

When you specify the needs your product will address, you are also deciding the other benefits it won't address. It can be difficult for some people to say, “No, our product won't solve that problem”—but that is the essence of strategy.

People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying no to 1,000 things.

It's important to list the must-haves, since they are required. However, since all products in the category have to have them, they are not the core part of your value proposition. The core elements are the performance benefits on which you choose to compete and the unique delighters you plan to provide.

Changing customer behavior is always difficult—especially in the upper right quadrant—and you need to create a certain amount of excess value to get customers to switch from a product they routinely use. The notion of needing to have “10×” better performance comes to mind again.

Agile thought leader Bill Wake created a set of guidelines for writing good user stories; to make them easier to remember, he uses the acronym INVEST: Independent: A good story should be independent of other stories. Stories shouldn't overlap in concept and should be implementable in any order. Negotiable: A good story isn't an explicit contract for features. The details for how a story's benefit will be delivered should be open to discussion. Valuable: A good story needs to be valuable to the customer. Estimable: A good story is one whose scope can be reasonably estimated. Small: Good stories tend to be small in scope. Larger stories will have greater uncertainty, so you should break them down. Testable: A good story provides enough information to make it clear how to test that the story is “done” (called acceptance criteria).

The main point of these calculations is less about figuring out actual ROI values and more about how they compare to each other. You want to focus on the highest ROI features first and avoid the lower ROI features.

To start with, your MVP candidate needs to have all the must-haves you've identified.

After that, you should focus on the main performance benefit you're planning to use to beat the competition. You should select the set of feature chunks for this benefit that you believe will provide enough for customers to see the difference in your product.

Delighters are part of your differentiation, too. You should include your top delighter in your MVP candidate. That may not be necessary if you have a very large advantage on a performance benefit. The goal is to make sure that your MVP candidate includes something...

don't recommend that you plan more than one or two minor versions ahead at the outset—since a lot of things are apt to change when you show your MVP candidate to customers for the first time. You'll learn that some of your hypotheses weren't quite right and will come up with new ones. You may end up changing your mind on which benefit is most important or come up with ideas for new features to address the same benefits.

Quantitative tests are good for learning “what” and “how many”: what actions customers took and how many customers took an action (e.g., clicked on the “sign up” button). But quantitative tests will not tell you why they chose to do so or why the other customers chose not to do so. In contrast, qualitative tests are good for learning “why”: the reasons behind different customers' decisions to take an action or not.

One good way to test your overall messaging is the five-second test. The idea is to show customers your home page or landing page for just five seconds and then ask them to tell you what they remember and what they liked. Because customers make snap judgements about products all the time, this can be a good way to see how well your messaging conveys what your product does and why someone would want to use it.

Buffer's first home page described what the product's value proposition was with a headline and three bullet points. It included a “plans and pricing” button, which was the only thing that visitors could click. Upon doing so, they were taken to a page that said “You caught us before we're ready.” Then they could enter their email address to be notified when the product launched.

fidelity refers to how closely the artifact looks like the final product, whereas interactivity means the degree to which the customer can interact with the artifact

The fake door or 404 page test is a good way to validate demand for a new feature that you are considering building. The idea is to include a link or button for the new feature and see what percentage of customers click on it. This lets you gauge whether customers actually want the feature before you spend the resources to build it. Since you haven't built the feature yet, the customers usually see a page thanking them for their interest and explaining that the feature is not built yet when they click on the link or button. You can also add a form asking the customer to share why they would find this feature valuable.