Introduction

In Chapter 3, we discussed different techniques for identifying your customer. Whether you are delivering a fixed- scope project or iteratively building a new product, your business will not be possible without having customer needs at the center of your delivery model. Customers define which businesses succeed and which businesses fail. In Lesson 3, we discussed Lean UX techniques for identifying proto-personas and understanding their needs. We also covered multiple techniques for user segmentation and analysis, including empathy maps and customer journeys.

However, in many instances, our understanding of what the customers need (or even who the customers are) is not accurate. No matter how well we know those customers, our understanding of what they need is just an assumption, a hypothesis that needs to be validated. As Henry Ford is said to have stated, “If I had asked people what they wanted, they’d have said ‘a faster horse'.” A true product visionary frequently comes up with ideas that others have not yet suggested or tested, and yet there is a need to validate those ideas before implementing them commercially.

This need is described by Eric Ries in his book Lean Startup [1]. In his opinion, the ability to validate a customer hypothesis before building new products or delivering complex business solutions is as applicable to Fortune 500 companies as it is to startups. Business success can be engineered by following the right process, which means it can be learned and applied as part of the Agile framework.

This chapter covers the Lean startup method and other techniques that allow you to validate customer needs before the product is built. This approach saves time and money and helps shape and prioritize deliverables based on customer needs. It fits within Agile, flexible delivery and ensures that the organization is delivering the product that will be of value to customers. We will review multiple frameworks for conducting this research, such as Google Ventures’ design Sprints, and use templates, such as Validation Canvas, to record all the steps in defining whether to “pivot” or “persevere” with product delivery.

We will review multiple techniques for conducting this research, such as “concierge MVP” or “exploration,” and we will discuss user research techniques. We will also discuss innovation and disruptive solutions, which may redefine our product concepts. As a result of all these activities, we will define MVP (minimum viable product) based on customer needs and identify all the necessary details to build a prioritized list of features and start execution.

 Tip

Even though the concepts of customer identification, hypothesis validation, product definition, and delivery are introduced in a logical sequential order in this textbook, it does not mean that they are always linear. Lean startup is built on the Lean concepts of the PDCA (plan–do–check–act) cycle, which is an iterative four-step management method used in business for the control and continuous improvement of processes and products. This cycle, proposed by Walter Stewart and later developed by William Deming, establishes a continuous feedback loop from the customers. Lean startup rebrands it as a “build–measure–learn” cycle. This means that throughout Agile delivery, we repeatedly go back to validating the customer hypothesis and redefining the product and its features.

Lean Startup: Fail Fast, Succeed Faster

In May 2013, Steve Blank, a Silicon Valley entrepreneur and a professor at Stanford, UC Berkeley, and Columbia University, published an article entitled “Why the Lean Start-Up Changes Everything.” In this article, he stated: “Launching a new enterprise—whether it’s a tech start-up, a small business, or an initiative within a large corporation—has always been a hit-or-miss proposition. According to the decades-old formula, you write a business plan, pitch it to investors, assemble a team, introduce a product, and start selling as hard as you can. And somewhere in this sequence of events, you’ll probably suffer a fatal setback. The odds are not with you: As new research by Harvard Business School’s Shikhar Ghosh shows, 75% of all start-ups fail” [2].

Imagine that there is a way to predict which product, initiative, or undertaking is going to be successful before building it rather than after it is delivered to customers. How can we learn from the customers what they need before we deliver anything to them? The worst way is to ask customers what they need. They would tell you that they want a faster horse, according to the quote by Henry Ford at the beginning of this chapter.

According to 2002 research conducted by The Standish Group [4], 45% of the features in the software products they surveyed were never used, and 19% were rarely used. In Lean terminology, these instances are referred to as “waste.” Besides creating those unneeded features, companies need to maintain this code, upgrade it, and include it in subsequent releases of the software (Figure 4-1). Over a period of time, this level of waste can be quantified as 30–45% of the total product cost.

 Topic for a Group Discussion

In groups, identify a software or hardware product or service that you all know and are using on a regular basis. Talk about its features. Are you aware of all the features that your group members are actively using? Are there any you have not been using? Conduct a quick online research to identify the features you may not be aware of or the ones you are aware of but are not using. Discuss why this is happening. Are you and your groupmates using the same features and ignoring the others or are the rarely used or never-used features different for each of you? Share the findings between the groups.

Incremental delivery proves to be the best way of minimizing risk over a period of time. By delivering a product incrementally, we learn from the customer and adjust the deliverables for the next iteration, depending on customer feedback. As an example, for a 12-month initiative in the case of incremental value delivery every month: if we deliver a product to the customer after month one and find out that the customer is not interested in the product or not satisfied with its pricing or quality, we have one month’s work to redo and 11 months to course-correct. If we wait until month 12 to deliver and find out that the product is not viable, we have lost the work of 12 months and have no time to produce a viable alternative. Figure 4-2 clearly shows that the risk is progressively increasing month after month unless interim deliverables are validated by the customer.

What if we do not need to wait until the first deliverable? While there is no crystal ball, there is a proven way to find out what the customer needs before building the actual product. This framework is referred to as “Lean startup.”

Lean startup defines a way to come up with a hypothesis about customer needs and validate it, similar to the way the Apple team of researchers validated early iPhone prototypes. According to Eric Ries, “Every business plan begins with a set of assumptions. It lays out a strategy that takes those assumptions as a given and proceeds to show how to achieve the company’s vision. Because the assumptions haven’t been proved to be true (they are assumptions, after all) and in fact are often erroneous, the goal of a startup’s early efforts should be to test them as quickly as possible” [1].

The Lean startup approach relies on the concept of “validated learning.” This principle describes learning generated by prototyping or implementing an initial idea and then measuring it against customer feedback to validate its effect. Typical steps in validated learning include the following: (1) specify the goal, (2) specify the metrics that represent the goal, (3) act to achieve the goal, (4) analyze the metrics if there is progress in achieving the goal, and (5) improve and try again. Each test of an idea is a single iteration in the value delivery process. While the term “validated learning” was introduced by Eric Ries as part of Lean startup principles, it can be applied universally.

Validated learning is applicable to almost any product or service. For example, for web products, we can use web analytics using tools such as Google Analytics and Amplitude. These tools provide capabilities to track the number of sessions (visits), the number of new sessions vs. returning visitors (this helps to determine if the website is attracting new visitors and whether it offers enough value to warrant return visits), channels (e.g., direct, organic search, referral, email, paid search, other advertising, social and display), bounce rate to define its “stickiness” (percentage of single-page website visits), conversion rate (purchases and other steps in the engagement cycle, such as email subscriptions, contact form submissions, content downloads, engaging in a live chat, and watching videos), and other relevant data.

The validated learning cycle in a Lean startup is described in Figure 4-3.

Besides validated learning, Lean startup includes experimentation to validate a hypothesis and iterative product releases to shorten the feedback loop depicted before. The Lean startup has been adopted by large corporations and smaller startups around the world due to its ability to minimize risk by shortening the feedback loop and its ability to bring the customer into the center of the development cycle.

 Five key questions to review:

1. 1.

   What is Lean startup?

    
2. 2.

   Why is Lean startup so popular?

    
3. 3.

   Is Lean startup an approach that is relevant for startups only? Why?

    
4. 4.

   Why was the first iPhone so successful in the market?

    
5. 5.

   What does it mean to “fail fast, succeed faster?”

    

Customer Hypothesis: Fall in Love with the Problem, not with the Solution

The biggest mistake that may happen while identifying the product or service, or defining the scope for an internal deliverable, is to focus on the solution. It frequently seems that innovators come up with new disruptive ideas, implement them, and start looking for customers. In fact, this is the way to create products and services that no one is interested in, except for their creators. Lean startup provides a mechanism to validate assumptions before building the product by checking if the problem exists and, if it does, whether customers are passionate enough about solving it so that they prioritize it above others.

As an example, when selecting customers to validate a weight loss program, it is not sufficient to ask respondents if they would like to lose weight. Most of them would most likely respond that they would. Instead, the question to ask is the following: “Have you tried before, and if yes, what did you do?” This way, you would be able to select those who willingly invested their time and effort into a weight loss program before; hence, they have demonstrated that they take it seriously and are willing to invest their time in the research.

This approach is implemented by startup incubators, which provide mentorship and support to startups for the first three to six months and then allow the graduating teams to build their businesses. They start by helping startup teams empathize with their customers – observe them (for this technique, we use the term “Gemba” from Japanese, translated as “the real place”) or interview them to understand whether the problem that the businesses are solving is a real problem for their prospective customers. The startups that begin with the opposite rarely survive. For example, I mentored one of the education startups, which was teaching children who had dyslexia to read by using newspaper articles as an example. They created a collection of newspaper articles of different complexity and questions related to them. However, they found that the children were not interested in reading outdated articles because the content was not relevant to them. This is one of the examples where a solution came before the actual problem. Once they found this out, they were able to focus on relevant context rather than the complexity.

When stating the hypothesis, work from your customer or persona. (Persona analysis was described in detail in Chapter 2.) Persona types have to be as narrow as feasible in order to make this process accurate. For example, for a face-to-face educational company providing test preparation services, the hypothesis is that students need support in their studies, and the assumption is that children of a certain age are still open to classroom learning for their test prep. It is important to define the right metrics. If 50% of the students are interested in the face-to-face test prep, is it enough? For that, we need to quantify the market and make assumptions about the number of students in the area where we have our physical office. To make this type of a major strategic decision, we take a lot of concepts into consideration before coming up with relevant metrics.

Eric Ries talks about two types of metrics: actionable metrics and vanity metrics. While both types may seem informative, vanity metrics are misleading, while actionable metrics help validate hypotheses. As an example, he uses a test prep company called Grockit, which changed its strategy based on moving from vanity metrics based on the number of users to actionable metrics based on customer trends for each newly released feature.

As the fifth step, upon review of the metrics and all relevant data, the organization or the team implementing the initiative, building the product, or providing the service needs to make a decision: “pivot” or “persevere.”

The Grockit example shows the importance of “falling in love with the problem, not with the solution.” Whether with Grockit or with Learnist, Farbood stayed true to his passion for solving the problem of the availability to high-quality education for anyone; however, he pivoted in selecting the ways to make learning accessible, based on the “build-measure-learn” feedback loop. The most important part of using actionable metrics for a company is to be prepared to listen to the voice of the customer and empathize with their needs, not with the solution the company already has in mind.

 Five key questions to review:

1. 1.

   Why is it important to validate the customer hypothesis before building a product?

    
2. 2.

   What are the five steps to validate the hypothesis?

    
3. 3.

   How do companies decide between actionable metrics and vanity metrics? Why are vanity metrics harmful?

    
4. 4.

   In the Grockit example, how did the company’s strategy change based on switching to actionable metrics?

    
5. 5.

   Why is it important to “fall in love with the problem, not with the solution”?

    

Pivot or Persevere

In order to validate or invalidate a customer hypothesis, it is not sufficient just to measure the outcomes. It is important to structure multiple “build-measure-learn” feedback loops to stage experiments, measure results, and “pivot” (switch to another product definition) or “persevere” (continue with the chosen product strategy). With each pivot, there is a new set of assumptions that comes up, and a new experiment is created based on these assumptions. However, there is no need to validate all the assumptions: the right way is to start with the most fundamental and least obvious assumption, referred to as the “most risky” assumption. The experiment is based on validating this riskiest assumption, and if it is confirmed, the next step is to “persevere” and develop the idea further, and if not, the next step is to “pivot” and suggest another solution, based on the learnings from this research. This continues until the hypothesis is confirmed and the solution that addresses the customer’s problem is found.

A pivot is a substantive change to one or more components of the business model. The decision to pivot is not easy. It requires an ability to look at the problem objectively. Many companies fail to do so and build products that customers are not interested in. It includes selecting the right actionable metrics, setting up success criteria, and staging their experiments in a thoughtful and methodical way to validate their assumptions. The companies that are able to take an objective look at customer feedback succeed, and those who ignore the needs of the changing market and the feedback from their customers, such as Kodak, Blockbuster, and Xerox, fail to pivot.

Kodak’s failure is not about the failure to embrace disruptive innovation. It has nothing to do with technology either. Here’s an example from my own experience. In 1994, when I was a visiting scholar at Stanford University, I was invited to a live demo of digital photography. Kodak researchers came over to the campus to show us pictures printed without a film. And yet Kodak suffered strategic failure because it failed to recognize the emerging customer need and tried to protect its film business. It was the wrong choice not “pivoting” the traditional model that set Kodak on the path to bankruptcy. You can read about it in the book by a former Kodak executive, Vincent Barabba, The Decision Loom: A Design for Interactive Decision-Making in Organizations [7]. Kodak’s failure was not caused by their inability to see digital photography as a disruptive technology – they invented it. The failure was caused by their inability to understand customer needs and the resulting desire to ignore the invention in order to protect their existing business, that is, their inability to pivot.

This ability has a lot to do with the “working backward” model discussed in Chapter 2, which is the ability to work backward from the customer, empathize with customer needs, and pivot based on what we learn from customers. And frequently, this learning will be different from what we hear from customers, so we need to be prepared to think long term, based on customer problems, not based on what they tell us they need.

In the digital photography demo that I attended back at Stanford in 1994, there were about 20 or so faculty and students in the room, and while all of us were genuinely amused, no one could envision that this would become the technology of the future. The digital camera was large and ugly, the quality of the printed picture was off, and the file size was huge. None of the participants’ responses showed any indication of commercial success. When I asked the researchers whether they felt this was a successful demo, they surprised me by saying that it was. I questioned this, and they explained that they were not looking for product approval – this would be vanity metrics for them in today’s terminology. They were looking for ease of use: each of us was able to take a picture, save it, and send it to print. In order to decide whether to pivot or persevere, they validated their “riskiest assumption” that people would be able to navigate the digital photography process easily and seamlessly – a great example of a well-structured validation experiment, which, unfortunately, was not carried forward by company management.

Let’s review some examples of the companies that were able to pivot successfully and then built their business based on the ideas they pivoted toward. You may not even be aware of the first iterations of well-known companies. For example, have you heard about an app called Burbn? In 2010, Burbn was created as a location-based HTML-5 app. The app allowed users to check into locations, make plans (future check-ins), earn points for hanging out with friends, post pictures, and much more.

It took a year to build a complete native iPhone app, but the customers were not pleased with its early version. It felt cluttered and overrun with features. Based on customer feedback, the team cut everything in the Burbn app except for its photo, comment, and “like” capabilities. What remained was Instagram. A week after its launch in 2010, they had 100,000 users, and the rest is history.

Was Burbn a bad application? Definitely not. One of the early customers shared that he found Burbn interesting because it was showing relevant locations and because this was an HTML-5 approach that was slick at that time. However, based on customer feedback, the team was able to pivot successfully, which resulted in creating one of the most successful businesses of the 21st century. It is important to understand the bold decision that was made: after a year of hard work, the team cut most of its functionality in favor of phone capabilities, and by doing that, they were able to listen to their customers, who defined their needs as social photo exchange rather than interactive location mapping [10].

 Topic for a Group Discussion

In groups, review other well-known examples of well-known companies that pivoted from lesser-known predecessors. Have you heard of a podcasting platform Odeo, predecessor of Twitter? A PDA payments product for Palm Pilots? Only incidentally did they build a web interface to allow users to make payments to each other without their Palms, which pivoted into PayPal. Other examples include Tune In, Hook Up, a video dating site, which became YouTube, and an online video game entitled “Game Neverending,” which became Flickr.

 Tip

The “pivot or persevere” approach is equally applicable to large corporations and fixed-scope initiatives. It helps identify “how” to validate a customer problem and come up with the right solution that addresses this need.

 Five key questions to review:

1. 1.

   What does it mean to pivot? For example, if a company is rebranding its website, is it pivoting? If an insurance company is expanding globally, is this an example of pivoting?

    
2. 2.

   Why is it important for any company or for any project leader to make a decision to pivot or persevere?

    
3. 3.

   What are some examples of well-known companies that were able to pivot successfully?

    
4. 4.

   What does it mean to “work backward” from customer needs in your understanding?

    
5. 5.

   Do only startups “pivot or persevere”? Can you talk about examples from this chapter or from your own experience when a large company or a project had to pivot to address customers’ problems?

    

User Research

In order to validate or invalidate a hypothesis, it is important to hear from customers. This is done via user research.

User research focuses on understanding user behaviors, needs, and observations through a number of techniques, from the observation of users in their natural surroundings to interviewing them about their experience with a working product and everything in between. It is an iterative and cyclical process.

 Tip

In this chapter, we cover the universal concepts of customer analysis and validated learning. These approaches apply to a product (a deliverable with its own life cycle, available to customers as long as there is a need for it), a project (an initiative of any size and scope with a specific outcome and specified constraints, such as budget, timelines, and scope), or a service (availability of a specific functionality to the customer via channels established within the customer’s agreement with a provider). This is relevant for software, hardware, or any other undertaking. For the purpose of this chapter, there is no specific distinction between the types of the effort – customer analysis and validated learning are equally important, no matter what the goal is.

 Topic for a Group Discussion

In groups, identify the key problem statement for the persona types you came up with in Chapter 2. How would you structure the experiment to validate this problem statement? What is the riskiest assumption? Who would you interview and what questions are you going to ask them? What would your success criteria look like?

Validation Canvas

In order to organize and structure validation experiments, companies use a simple template referred to as the “Lean Validation Canvas.” This template allows them to make assumptions, validate hypotheses, and record pivot or persevere decisions (see Figure 4-4).

Step by step, the Lean Validation Canvas is used to record each customer’s information, their problem to solve, the riskiest assumption, the experiment, and the results.

If the hypothesis is confirmed, the solution is confirmed. If not, it is time to pivot. A pivot is a change in the business model; it is not an enhancement or an incremental change – it is a fundamental revision. We can think of these as course-correction mechanisms. These are high-level changes in strategy or execution that impact the whole business model.

Types of pivots include the following:

Customers need pivot. If customer feedback shows that the problem that was assumed is not a major concern for them, it requires repositioning, or a completely new product, or finding a project that solves the actual need.

Zoom-in pivot. This pivot is used if the original feature becomes the whole product. It is done to deliver fast or because other features are not addressing customer needs. Earlier in this chapter, we reviewed the case of the Burbn app, which lost all its features except for those that were photo related and became Instagram.

Zoom-out pivot. This is a reverse pivot when a single feature does not cover major customer needs and thus is not sufficient to support a product. In this case, additional features are validated and introduced into the product.

Platform pivot. In this case, there is a change needed from an application to a platform or vice versa. However, most customers buy solutions, not platforms.

Channel pivot. “Channel,” in sales terminology, is the mechanism by which a company delivers its product, project, or service to customers. Channel pivots usually require unique pricing, features, and competitive positioning.

Each of the experiments and its findings is recorded on the Lean Validation Canvas until the hypotheses get validated.

 Five key questions to review:

1. 1.

   What is the goal of validated learning?

    
2. 2.

   How does the Lean Validation Canvas help?

    
3. 3.

   What are the three types of experiments?

    
4. 4.

   What are the types of pivots described in this section?

    
5. 5.

   There is another type of pivot, called the customer segment pivot. What do you think it means? Are you aware of any examples from your personal experience?

    

Design Sprints and Design Thinking

Design thinking is an iterative process focused on understanding the user and the user’s problem. Design thinking helps identify strategies and solutions that might not be obvious based on observation and research. Design thinking is based on a deep interest in understanding customer needs. It is founded on questioning and validating the problem, its assumptions, and associated solutions. It is very useful when defining and validating a problem that is not well understood or is simply unknown by adopting a hands-on approach to testing and prototyping. It involves ongoing experimentation and brainstorming, including prototyping, sketching, testing, and validating ideas.

Google Ventures created a methodology of design Sprints – five days of intense user research built on the five phases of design thinking. This methodology is described by Jake Knapp et al. in the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days [12]. Design Sprint at Google Ventures is a unique five-day process for answering crucial questions through prototyping and testing ideas with customers. It’s a combination of business strategy, innovation, behavioral science, and design packaged in a step-by-step process that anyone can use.

Design Sprints implement the Lean startup “build-measure-learn” feedback loop in a unique way that takes only five days. On Monday, participants map out the problem and pick an important place to focus. On Tuesday, they sketch competing solutions on paper. On Wednesday, they make decisions and turn their ideas into a hypothesis. On Thursday, they create a realistic prototype. On Friday, they conduct user research and test this prototype with potential customers (see Figure 4-5).

The five steps of the design Sprint are described in detail on the Google Ventures website. This method enables a thorough and structured way of conducting user research.

MVP (Minimum Viable Product)

Once the research is conducted, the time comes to define the minimum viable product, or MVP. MVP is an iterative, low-risk way of building a minimal valuable deliverable for the customer. It is a concept that stresses the impact of learning in product development. MVP is an early version of the product that has just enough features to satisfy early customers and initiate the feedback loop that will inform product development going forward. MVP minimizes risk because it helps test the assumptions about whether the product meets customer needs, and by doing this, MVP minimizes waste.

The most effective way to create an MVP is by prototyping the experience and simulating the use of the product or service in question. This includes low-fidelity prototypes, which are paper based, or high-fidelity prototypes simulating parts of the actual product or service. For software products, there are tools such as InVision, which allows you to create clickable prototypes in minutes. In their book Lean UX [13], Jeff Gothelf and Josh Seiden describe types of prototypes and discuss the choice of prototyping technique.

Once MVP is defined, we can proceed with defining the product (see Chapter 5).

 Five key questions to review:

1. 1.

   What is design thinking?

    
2. 2.

   What are the five phases of design thinking according to d.school?

    
3. 3.

   What does it mean to ideate as part of the design thinking process?

    
4. 4.

   How does Google Ventures implement design thinking in their design Sprint model?

    
5. 5.

   Why is MVP so important in Agile product management?

    

Key Points