1. Determine your target customers
2. Identify underserved customer needs
3. Define your value proposition
4. Specify your minimum viable product (MVP) feature set
5. Create your MVP prototype
6. Test your MVP with customers
The last three steps reference the important Lean concept of a minimum viable product (MVP). I discuss MVP in detail in Chapters 6 and 7, but it's basically the minimum amount of functionality that your target customer considers viable, that is, providing enough value. When you are building a new product, you want to avoid building more than is required to test your hypotheses with customers. The term MVP clearly applies when you're building a completely new version 1 product (v1 for short). In addition, the idea of an MVP makes sense if you are redesigning an existing product or building v2.
The Lean Product Process also applies when you are not building a whole product, such as when you add functionality to or improve an existing product. In those situations, you can think of the process steps applying to a “minimum viable feature” instead, if that's clearer.
Step 5 also refers to your MVP prototype. I intentionally use this broad term to capture the wide range of product-related artifacts you can test with customers. While the first “prototype” you test could be your live product, you can gain faster learning with fewer resources by testing your hypotheses before you build your product.
Not all six steps are required for every product or feature. Certain steps are required only when you're building a completely new product. Take, for example, determining your target customers, identifying underserved needs, and defining your value proposition. Once you've successfully completed those steps for your product, you may not need to revisit those areas for a while. But after launching your v1 product, you would continue to improve and add functionality by looping through the three remaining steps: specifying which features to pursue, creating the features, and testing the features with customers.
To increase your chances of achieving product-market fit, the process is designed to encourage a certain amount of rigor in product thinking. In a sense, the process is a checklist to help make sure you've thought about the key assumptions and decisions to be made when creating a product. If you are not making these assumptions or decisions explicitly, then you are making them implicitly. The Lean Product Process helps you articulate the assumptions and hypotheses in your head (which you can revise later as you iterate). If you skip these critical thinking steps, you leave important elements – such as target customer and product strategy – to chance.
A key concept in Lean manufacturing, which inspired Lean Startup, is the concept of rework: having to spend time fixing something that you did not build correctly the first time. Minimizing rework is a key tactic for eliminating waste. In addition to helping you achieve product-market fit, the Lean Product Process also enables you to do so more quickly by reducing rework.
To be clear, you will have some rework with the Lean Product Process. It is an iterative process that requires you to revise your hypotheses, designs, and product as you make progress – all of which could be considered rework. The goal of the process is to achieve product-market fit as quickly as possible. Quick but rigorous thinking that avoids or reduces rework helps achieve that goal.
You can think of the Lean Product Process like the drills that karate students learn and practice as they make progress earning higher and higher belts. After mastering the core techniques from their drills and becoming black belts, students are able to mix, match, and modify what they have learned to create their own custom style. Martial arts master Bruce Lee eloquently said, “Obey the principles without being bound by them.” He also said, “Adapt what is useful, reject what is useless, and add what is specifically your own.” I encourage you to heed his advice as you read and practice the ideas and guidance in this book.
Along those lines, I would enjoy hearing any questions or feedback you have, as well as your experiences applying the ideas in this book. Please feel free to share them at the companion website for this book: http://leanproductplaybook.com. There, you can also see the latest information related to the book and contribute to the conversation about how to build great products.
Before jumping to the first step of the Lean Product Process, I discuss in the next chapter the important concept of problem space versus solution space. Understanding this fundamental idea will help clarify our thinking as we work our way up the Product-Market Fit Pyramid.
Chapter 2
Problem Space versus Solution Space
The Lean Product Process will guide you through the critical thinking steps required to achieve product-market fit. In the next chapter, I begin describing the details of the process, but before I do, I want to share an important high-level concept: separating problem space from solution space. I have been discussing this concept in my talks for years and am glad to see those terms used more frequently these days.
Any product that you actually build exists in solution space, as do any product designs that you create – such as mockups, wireframes, or prototypes. Solution space includes any product or representation of a product that is used by or intended for use by a customer. It is the opposite of a blank slate. When you build a product, you have chosen a specific implementation. Whether you've done so explicitly or not, you've determined how the product looks, what it does, and how it works.
In contrast, there is no product or design that exists in problem space. Instead, problem space is where all the customer needs that you'd like your product to deliver live. You shouldn't interpret the word “needs” too narrowly: Whether it's a customer pain point, a desire, a job to be done, or a user story, it lives in problem space.
The Space Pen
My favorite story to illustrate the concept of problem space versus solution space is the space pen. When NASA was preparing to send astronauts into space, they knew that ballpoint pens would not work because they rely on gravity in order for the ink to flow. One of NASA's contractors, Fisher Pen Company, decided to pursue a research and development program to create a pen that would work in the zero gravity of space. After spending $1 million of his own money, the company's president, Paul Fisher, invented the Space Pen in 1965: a wonderful piece of technology that works great in zero gravity.
Faced with the same challenge, the Russian space agency equipped their astronauts with pencils. You can actually buy a “Russian space pen” (which is just a cleverly packaged red pencil).
This story shows the risk of jumping into the solution space prematurely and the advantage of starting in the problem space. If we constrain our thinking to “a pen that works in zero gravity,” we may not consider creative, less-expensive solutions such as a pencil. In contrast, having a clear understanding of the problem space (devoid of any solution space ideas), allows for a wider range of creative solutions that potentially offer a higher return-on-investment. If the pencil and space pen were equally adequate solutions, then avoiding one million dollars of research and development cost would clearly be the preferable alternative.
To avoid fixating on pen-based solutions, we could rephrase the problem space as: “a writing instrument that works in zero gravity.” That would allow for a pencil as a solution. But that's still anchored on “a writing instrument” solution. We can do even better than that: “a way to record notes in zero gravity for later reference that is easy to use.” That problem space statement would allow for more creative solutions such as voice recording with playback. In fact, considering out-of-the-box solution ideas can help you refine your problem space definition, even if they aren't feasible. In this case, a voice recorder would probably not be as good a solution as a Space Pen. It would need a power source and would require playback to refer to the notes again, which would be less convenient than being able to scan and read them. But undergoing this thought exercise would allow us to further refine our problem space definition to: “a way to