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

After finishing: Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value written by Teresa Torres, I picked up The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback by Dan Olsen. This book explains the exact steps to follow which can lead to building a Minimum Viable Product (MVP) that achieves Product Market Fit (PMF).

Who is this book for?

If you are working on building a new product or working on existing product to make it better, then you should read this book. This applies to product leaders, product managers, product designers as well as product developers.

Usual Disclaimer

This post is by no means a summary of the book, the notes mentioned here are extracts from the book. If you find these interesting, please pickup a copy of the book and give it a go.

Book Notes

Introduction: Why Products Fail and How Lean Changes the Game

The main reason products fail is because they don't meet customer needs in a way that is better than other alternatives. This is the essence of product-market fit. 

PMF Pyramid

Product-Market Fit Pyramid breaks down Product-Market fit down into 5 key components: 

• Your target customer
• Your customers underserved needs
• Your value proposition
• Your feature set
• 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 MVP feature set
• Create your MVP prototype 
• Test your MVP with customers

Achieving Product-Market Fit with the Lean Product Process

PMF means being in a good market with a product that can satisfy that market - You have built a product that creates significant customer value. This mean that your product meets real customer needs and does so in a way that is better than the alternatives. 

Your product is the top section of the product market fit pyramid, which consists of 3 layers. The market is the bottom section of the pyramid, consisting of two layers. Within the product and market sections, each layer depends on the layer immediately beneath it. Product-market fit lies between the top and bottom sections of the pyramid. 

The PMF Pyramid separates the market into its two distinct components: the target customers and their needs. As you try to create value for customers, you want to identify the specific needs that correspond to a good market opportunity. 

A product is a specific offering intended to meet a set of customer needs. The real world manifestation of software products that customers see and use is the user experience (UX), which is the top layer of the PMF Pyramid. 

The set of needs, that you aspire to meet with your product forms your value proposition, which is the layer just below "feature set". Your value proposition is also the layer just above customer needs, and fundamentally determines how well the needs addressed by your product match up with the customers.

When you are building a new product, you want to avoid building more than is required to test your hypothesis 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. 

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 process 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 PMF as quickly as possible. 

Problem Space versus Solution Space

Any product that you actually build exists in solution space, as do any product designs that you create - such as mockups, wireframes, or prototypes. 

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. Whether it's a customer pain point, a desire, a job to be done, or a user story, it lives in problem space. 

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. 

It's product team's job to unearth these needs and define the problem space. One way is to interview customers and observe them using existing products. Such techniques are called "contextual inquiry" or "customer discovery", you can observe what pain points they run into even if they don't explicitly mention them to you. You can ask them what they like and don't like about the current solutions. 

The reality is that customers are much better at giving you feedback in the solution space. If you show them a new product or design, they can tell you what they like or don't like. They can compare it to other solutions and identify pros and cons.

Problem space and solution space are an integral part of the PMF pyramid. Unlike customers and their needs, which you can target but can't change, value proposition is the problem space layer over which you have most control.

Determine Your Target Customer

Matching a product with its target customer is like fishing. Your product is the bait that you put out there and the fish that you catch is your target customer. 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. Once you have a product or a prototype to show customers, then you can gain clarity about the target market you're attracting. 

In some cases, especially for business-to-business products, the customer who will use your product (the user) is not the same person who makes the purchase decision (the buyer). The buyer often has distinct needs from the end user that need to be addressed to achieve PMF, and you should define your target buyer in addition to your target customer when warranted. 

The technology adoption life cycle divides a market into five distinct customer segments based on their risk aversion towards adopting new technologies.

• Innovators: They are technology enthusiasts who pride themselves on being familiar with the latest and greatest innovation. 
• Early Adopters: They are visionaries who want to exploit new innovations to gain an advantage over the status quo.
• Early Majority: They are pragmatists that have no interest in technology for its own sake. They adopt new products only after a proven track record of delivering value. 
• Late Majority: They are risk averse conservatives who are doubtful that innovations will deliver value and only adopt them when pressured to do so. 
• Laggards: They hate change and have a bias for criticising new technologies even after they have become mainstream. 

Identify Underserved Customer Needs

Customers are generally not skilled at discussing the problem space; they are better at telling you what they like and dislike about a particular solution. Good interviewers excel at listening closely to what customers say, repeating statements back to ensure understanding, and asking additional probing questions to illuminate the problem space. 

You should ask a set of questions about each benefit statement, such as:

• What does this statement mean to you?
• How might this help you?
• If a product delivered this benefit, how valuable would that be to you?

Possible responses: no value, low value, medium value, high value, or very high value.

• For a response of high or very high value: why would this be of value to you?
• For a response of low or no value: why wouldn't this be of value to you?

These questions help you to see if the way you're describing the benefit is clear to users. They also help you learn how valuable the benefit is and why. 

Once you have identified the various customer needs, you have to decide which ones you want to address. You need a good way to prioritise among the different needs - and prioritising based on customer value is a good approach. We can do this via a framework based on importance and satisfaction.

Importance Vs Satisfaction

Importance is a measure of how important a particular customer need is to a customer. Importance is a problem space concept, separate from any specific solution space implementations.

Satisfaction is a measure of how satisfied a customer is with a particular solution that provides a certain customer benefit.

The power of the framework comes when you look at importance and satisfaction together. Importance is on the vertical axis and satisfaction is on the horizontal axis. The bottom two quadrants represent low importance of the need for a customer. There isn't much point in pursuing low important needs. The upper right quadrant is high importance as well as high satisfaction. This would be the case in a market where the leading products are robust and do a good job of meeting customer needs. The upper left quadrant is high importance of need but low satisfaction with current solutions. Customer needs in this quadrant are important but underserved. As a result, they offer excellent opportunities to create customer value. 

Kano Model

The kano model plots a set of two parameters on horizontal and vertical axes:

• How fully a given customer need is met
• The resulting level of customer satisfaction. 

The utility of the model is that it breaks customer needs into three relevant categories that you can use: performance needs, must-have needs, and delighter's. 

• Performance needs: more is better. As the need is more fully met, the resulting customer satisfaction increases. 
• Must-have needs: don't really create satisfaction by being met. Instead, the need not being met causes customer dissatisfaction. They are "table stakes" or "cost of entry" - boxes that must be checked for customers to be satisfied with your product. 
• 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. 

Needs migrate over time. Yesterday's delighters become today's performance features and tomorrow's must-haves. The fact that your product has a delighter doesn't matter if it's missing a must-have. You have to meet basic needs before you can get credit for performance features. And your product must be competitive on performance features before delighters matter. 

Define Your Value Proposition

When you specify the needs your product will address, you are also deciding the other benefits it won't address - that is the essence of strategy. 

To create your product value proposition create a table. The first column, you list the benefits - one per row, grouped by type. You want to include the must-haves. performance benefits, and delighters that are relevant to you and your competitors. You should have a column for each relevant competitor and a column for your product. 

Once you have established the benefits and competitors, you want to go through each row and score each of the competitors and your own product. The entries for must-haves should be "Yes". For performance benefits, you should use whatever scale works best for you: "High", "Medium" and "Low". Delighters are typically unique, so just list each delighter on a separate row and then mark "Yes"where applicable. 

Specify Your Minimum Viable Product (MVP) Feature Set

For your MVP, you want to identify the minimum functionality required to validate that you are heading in the right direction. For each benefit in your product value proposition, you want to brainstorm as a team to come up with as many feature ideas as you can for how your product could deliver that benefit. You should be practicing divergent thinking, which means trying to generate as many ideas as possible without any judgement or evaluation. There will be plenty of time later for convergent thinking, where you evaluate the ideas and decide which ones you think are most promising. Later you can score each idea on expected customer value to determine a first-pass priority. The goal is to identify the top three to five features for each benefit. 

User stories are a great way to write your feature ideas to make sure that they corresponding customer benefit remains clear. Well-written user stories usually follow the template:

As a [type of user]

I want to [do something]

so that I can [desired benefit]

Once you have written high-level user stories for your top features, the next step is to identify ways to break each of them down into smaller pieces of functionality. The goal is to find ways to reduce scope and build only the most valuable pieces of each feature. 

After you have finished chunking your feature ideas, you should perform a second-pass prioritisation that accounts for both the value and the effort. When you are building a product or feature, the investment is usually the time that your development resources spend working on it. When you have two feature ideas with the same ROI, it's best to prioritise the smaller scope idea higher because it takes less time to implement. 

Once you are done chunking, scoping, and prioritising, you can create a small grid that lists the benefits from your value proposition and that lists, for each benefit, the top feature ideas broken into chunks. 

Once you have organised your list of features chunks by benefit and prioritised the, it's time to start making some tough decisions. You must decide on the minimum set of functionality that will resonate with your target customers. 

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. Delighters are part of your differentiation, too. You should include your top delighter in your MVP candidate. 

Create Your MVP Prototype

A pyramid of four hierarchical layers is used to describe a product's attributes: functional, reliable, usable and delightful. 

What MVP should have

The pyramid on the left illustrates the misconception that an MVP is just a product with limited functionality, and that reliability, usability, and delight can be ignored. Instead, the pyramid on the right shows that while an MVP has limited functionality, it should be "complete" by addressing those three higher-level attributes. 

The first way to categorise MVP tests is by whether they are aimed at testing your product or your marketing. A landing page test is an example of marketing test. An MVP test used to validate your product will involve showing prospective customers functionality to solicit their feedback on it. 

The second dimension on which MVP tests differ is whether they are qualitative or quantitive. Qualitative means that you are talking with customers directly, usually in small numbers. Quantitive research involves conducting the tests at scale with large number of customers. 

Apply the Principles of Great UX Design

You are clear on the feature set you believe should be in your MVP. UX the top layer in the PMF Pyramid - brings your product's features and benefits to life for the customer. A product with great UX feels easy to use. It's effortless to find what you're looking for an to figure out what to do next. You don't even notice the user interface and are able to focus on accomplishing the task at hand. The product may even be fun to use and convey emotional benefits such as confidence in your abilities or peace of mind. A great design may lead you to what psychologists call a state of "flow", where you are completely immersed in using the product. 

The first key attribute of a great UX is usability. Usability focuses on the user goals and the tasks they need to perform to achieve those goals. What percentage of users are able to successfully complete each task? The more user effort required to take an action, the lower percentage of users who will take that action. The less user effort required, the higher the percentage of users who will take that action. 

The second key attribute of a great UX is delight. Strong usability helps avoid a poor UX, but it is not enough to deliver a great UX. Usability answers the question, "Can customers use your product?" Delight answers the question, "Do customers enjoy using your product?". Delight, goes beyond simply avoiding user frustration and evokes positive emotions. 

The framework for UX design is the following iceberg, only a small portion of UX design is visible and immediately apparent - but there is much more beneath the surface. Starting at the bottom, the four layers of the iceberg are conceptual design, information architecture, interaction design and visual design. 

UX Design Iceberg

• Conceptual design: Is the underlying concept that forms the essence of the user experience. 
• Information architecture: Determines how you structure your product's information and functionality. 
• Interaction design: Defines how the user and your product interact with one another. 
• Visual Design: Is how your product looks. 

You should also consider these principles of composition when creating and evaluating your designs:

• Unity: Does the page or screen feel like a unified whole or a bunch of disparate elements?
• Contrast: Is there enough variation in colour, size arrangement and so forth to create visual interest?
• Balance: Have you equally distributed the visual weights of elements in your design?
• Use of space: How cluttered or sparse does your design feel?

Test Your MVP with Customers

User feedback is incredibly valuable because it identifies what you don't know. When you are so close to your product, it is difficult - often impossible - to perceive it as a new customer does. As a result, you have "product blindness": blind spots for the issues that a new user will readily encounter within minutes of using your product. User testing is the antidote for product blindness.

Qualitative user tests require that you show customers your product or design deliverables - wireframes, mockups or prototypes - to solicit their feedback. 

You can gather much richer data sitting next to a user versus sharing a screen. You can see the user's screen and face when you're in his or her presence, and can pickup little things like sighs, facial expressions, and other subtle cues. When you are early in defining and validating your MVP, moderated testing is the way to go to ensure you can ask questions and get rich customer feedback. When you are farther down the road and feeling more confident about your MVP, unmoderated testing can be a useful tool. 

The top way that moderators perturb the results is by asking leading questions, such as "That form was easy to fill out, wasn't it?" Moderators who ask rhetorical and leading questions care more about confirming that the product is good than they do about getting actual, authentic feedback. The point of user testing is not to make ourselves feel good; the point is to get objective feedback from real customers. 

If a user takes an action on a prototype but doesn't verbalise that they did or why they did, a good moderator might say, "I see you just clicked on that button. could you tell me why?" Open questions give the customer plenty of latitude in answering. They usually begin with "why", "how" and "what". In contrast, closed questions limit the customer's possible responses to yes or no. 

If the users have difficulty understanding or using your product, it's important not to help them, as painful as that may feel. Your goal is to keep the test as real as possible; you're not going to be able to hold every customer's hand after your product launches.

It's crucial to differentiate between feedback on usability versus PMF. Feedback on usability has to do with how easy it is for customers to understand and use your product, whereas feedback on PMF has to do with how valuable they find your product. 

Iterate and Pivot to Improve Product-Market Fit

The Hypothesize-Design-Test-Learn Loop

• You start with the "hypothesize" step, where you formulate your problem space hypotheses. 
• In the "design" step, you identify the best way to test your hypotheses. 
• In the "test" step, you expose your product or artifact to customers and make observations, which lead to validated learnings. 
• You complete the loop by using this validated learning to revise and improve your hypotheses.

These revised hypotheses will inform your next iteration through the loop. The more quickly you can learn, the more quickly you can deliver additional customer value and improve your PMF. 

At the end of each testing wave, you want to look across all the users to see how many gave the same feedback, either positive or negative, which you can express as a percentage. Those percentages should help you prioritise the changes you make to your MVP. 

If you find that you are not making progress as you try to iterate, I recommend you pause and take a step back. Brainstorm with your team about what all the possible problems could be. Map each problem back to the corresponding layer of PMF Pyramid. You may find that you are iterating at a higher level than where the true problem lies. For e.g., if your hypothesis about your target customer is wrong, iterating your UX design won't make much difference. You want to start at the bottom of the pyramid and work your way up until you identify which of your hypotheses are incorrect. When you change one of your main hypotheses it's called a pivot. A pivot is larger in magnitude. 

You shouldn't change direction every time you hit a rough patch, nor should you drop what you're doing to chase each cool new idea you come up with, also known as a shiny object syndrome. You should consider pivoting if you just don't seem to be achieving gains in PMF after several rounds of trying to iterate. If, despite your best efforts, your target customers are only lukewarm on your MVP, you should consider a pivot. 

Build Your Product Using Agile Development 

There are many risks that could impede your while trying to build your blueprint. You may run into issues with technical feasibility, where what you have designed is impossible or too challenging to build, either in general, or with the resources you have available. Your product may be feasible but have such a large scope relative to your resources that it will just take too long to build. An important part of PMF is having the right product at the right time. 

Agile methodologies break the product down into smaller pieces that undergo shorter cycles of requirements definition, design, and coding. Because you are planning in smaller increments, 

• You can react to changes in the market or other new information more quickly. 
• Your product reaches customers earlier. 
• Teams can reduce their margin of error in estimating scope by working in smaller batch sizes. 

There are known knowns. There are things we know we know. We also know there are known unknowns. That is to say, we know there are some things we do not know. But there are also unknown unknowns. The ones we don't know we don't know!

Agile frameworks are like shoes: You really have to try them on to figure out how well they fit. It's often wise to just pick the methodology that sounds best to you and try it out for a few months. Many teams start by trying out either Scrum or Kanban. 

Kanban tends to work best with smaller development teams. The lower process overhead and the lack of a predetermined iteration length can enable faster delivery of product. But as a development organisation grows to multiple teams, Kanban can start to become more challenging. If you organisation has multiple development teams across which you need to coordinate work, then the predictable cadence of Scrum can be beneficial. 

Measure Your Key Metrics

Attitudinal information is what customers say about their attitudes and opinions. In contrast, behavioural information has to do with what customers actually do. The following framework maps Attitudinal information and behavioural information against Qualitative and Quantitative ways of collecting information.

What testing type to use when

Quantitive research can tell you how many customers are doing (or not doing) something. But it won't tell you why the customers are doing it (or not doing it). On the flip side, qualitative research will help you get at the underlying reasons for why customers do what they do. But it won't tell you how many people do what they do for each particular reason. 

You should not invest in trying to grow your business until after you have achieved PMF. To check if you have achieved PMF, you can use this survey where you can ask the users of your product the question, "How would you feel if you could not longer use [product X]?". The four possible responses are:

• Very disappointed
• Somewhat disappointed
• Not disappointed (it isn't really that useful)
• N/A - I no longer use [product X]

Products for which 40 percent or more of users replay "very disappointed" tend to have PMF.

Analytics are critical for any product team to fully understand how their customers are using the product. Analytics can't give you the entire picture; you also need qualitative research to know your customers. But you are flying blind without analytics. 

AARRR! framework is also called "Startup Metrics for Pirates" (for obvious reasons) it measures - acquisition, activation, retention, revenue and referral. It is recommended to track 2-3 key metrics for each of the five elements of his framework. 

AARRR Framework

At any point in the life of your business, one of the five macro-metrics in the AARRR model will be more important than the others. It's also called "Metric That Matters Most" or MTMM for short. Your MTMM is the metric that offers the highest ROI opportunity for improving your business right now. At some point, after you make significant progress on your MTMM, it will no longer be the MTMM - since a different metric will now offer higher ROI opportunities. The MTMM changes due to the phenomenon of diminishing returns. 

When you are working on a new product, you need to first achieve PMF. Until you know that customers find your product valuable, it doesn't make sense to spend lots of resources trying to acquire customers. Nor does it make sense to optimise conversions. If customers find value in your product, they will continue using it; otherwise, they won't. Retention is the macro-metric most closely related to PMF. For this reason, it is typically the first MTMM for a new product. 

Once you confirm strong PMF with a healthy retention rate, you know that a high enough percentage of customers that get through your front door and use your product will stick around. It usually makes the most sense to focus next on making sure the highest percentage of prospects who show up at your front door make it inside. 

Once you have optimised retention and conversion, it often makes sense to focus on acquisition - identifying new and better ways of attracting prospects. 

Three most important retention curve parameters are - initial drop-off rate, rate of descent, and terminal value - are direct measures of PMF. The stronger your PMF, the lower your initial drop-off rate, the lower your rate of descent and the higher your terminal value. Terminal value is the most important of these three parameters, since it answers the question, "What percentage of customers who tried your product continue to use it in the long run?"

Every business can be expressed as an equation. The goal is to come up with a quantitive representation of your business constructed from a set of metrics that you can use to optimise your business results. One equation you can start with that applies to every business:

Profit = Revenue - Cost

This equation tells you that you can increase profit by increasing revenue or decreasing cost. To make this metric more actionable, you are going to break down these higher-level metrics into formulas of more detailed metrics to go several level deeper. This is called "peeling the analytics onion".

Revenue = Paying Users * Average Revenue per Paying User

Paying Users = New Paying Users + Repeat Paying Users

New Paying Users = Free Trial Users * Trial Conversion Rate + Direct Paid Signups

Profit = Number of Customers * Profit per customer

Profit per customer = Revenue per Customer - Cost per Customer

Use Analytics to Optimise Your Product and Business

The great thing about a live product is that analytics let you clearly see the results of changes that you make. With a good A/B testing framework, you can easily conduct experiments and make improvements rapidly. Companies that do this well have an advantage over their competitors. 

Product Analytics Process

• The first step in the Lean Product Analytics Process is to define the key metrics for your business. 
• Next, you need to start measuring these metrics so you can establish a baseline value for each one. 
• Next step is evaluating each metric's upside potential. This is where you assess each metric through an ROI lens. 
• Once you have assessed each metric's upside potential, you move on to the next step in the process: selecting the metric that offers the most promising opportunities for improvement. This is the metric that matters most (MTMM). 
• Then you want to brainstorm as many improvement ideas as you can for this top metric. 
• Then you want to estimate how much each idea will improve the metric. You also want to estimate the effort for each idea so you can evaluate ROI. 
• You then pick the highest ROI idea to pursue. 
• Next, you design and implement the top improvement idea. 
• Of course, you hope your target metric improves. But you've made progress even if it doesn't because you have gained valuable learning. You now revisit your list of ideas to improve the metric and select the next best idea, repeating the loop.
• Eventually, you should see the target metric improving after trying several ideas. 
• At some point, a different metric will offer greater opportunities for improvement. This new metric becomes the MTMM. 

The hypotheses you made in one layer of the PMF Pyramid, affects all layers above it. You UX is the easiest layer to change, you can also change your feature set, but it takes more effort. But the foundational elements of PMF - your target customers, their underserved benefits, and your value proposition - are difficult to change once you've built your product. Once you've locked in your hypotheses for these layers, they are like a set of interconnected tectonic plates. If you move one of them after you've already built your product, much of the product you've built will no longer be relevant - like an earthquake that reduces a building to rubble. When that happens, human nature can make you want to salvage and reuse as much as of your work as you can. But doing so can add onerous constraints to your solution space, which is suboptimal when you are changing your problem-space hypotheses. You would be better off building again from scratch on top of the new foundation. 

Conclusion

This book is a practical guide on how to build a product that customers love. The content in this book is very actionable. I would highly recommend reading this book for anyone working towards building a product!

Book Notes: Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value

In one of the groups, I stumbled upon this awesome book for Product Discovery: Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value written by Teresa Torres. After reading this book, I kinda understood the entire process of product discovery for the first time. 

Who is this book for?

If you are working on building a new product or working on existing product to make it better, then you should read this book. This applies to product managers, product designers as well as product developers.

Usual Disclaimer

This post is by no means a summary of the book, the notes mentioned here are extracts from the book. If you find these interesting, please pickup a copy of the book and give it a go.

Book Notes

The What And Why Of Continuous Discovery

The work that you do to decide what to build is called discovery work and the work that you do to build and ship a product is called the delivery work. 

Product Manager, Designer and Software Engineer, they are collectively responsible for ensuring that their products create value for customers in a way that creates value for the business. 

There are six mindsets that must be cultivated to successfully adopt the habits of continuous discovery. 

• Outcome oriented: This means rather than defining your success by the code that you ship, you define success as the value that code creates for your customers and for your business. Rather than measuring value in features and bells and whistles, we measure success in impact - the impact we have had on our customers lives and the impact we have had on the sustainability and growth of our business. 
• Customer centric: This mindset places the customer at the centre of our world. It requires that we not lose sight of the fact that the purpose of business is to create and serve a customer. 
• Collaborative: This requires that we embrace the cross functional nature of digital product work and reject the siloed model, where we hand off deliverables through stage gates. 
• Visual: This encourages us to step beyond the comfort of spoken and written language and to tap into our immense power as spatial thinkers. 
• Experimental: This encourages us to don our scientific-thinking hat. 
• Continuous: This will help us evolve from a project mindset to a continuous mindset. Rather than thinking about discovery as something that we do at the beginning of a project, we will learn to infuse discovery continuously throughout our development process. 

A Common Framework For Continuous Discovery

We are shifting from an output mindset to an outcome mindset. Rather than obsessing about features, we are shifting our focus to the impact those features have on both our customers and our business. 

If the product trios tasked with delivering a desired outcome want to pursue business value by creating customer value, they will need to work to frame the problem in a customer-centric way. They will need to discover the customer needs, pain points, and desires that if addressed would drive their business outcome. Customer needs, pain points and desires are collectively called as "Opportunities". 

To reach their desired outcome, a product trio must discover and explore the opportunity space. The opportunity space, however is infinite. This is precisely what makes reaching our desired outcome an ill-structured problem. 

The two of the most important steps for reaching our desired outcome are:

• How we map out and structure the opportunity space
• How do we select which opportunities to pursue. 

Opportunity solution tree are a simple way of visually representing the paths you might take to reach a desired outcome. The root of the tree is your desired outcome-the business need that reflects how your team can create business value. Next is the opportunity space. These are the customer needs, pain points and desires that, if addressed, will drive your desired outcome. Below the opportunity space is the solution space. This is where we will visually depict the solutions we are exploring. Below the solution space are assumption tests. This is how we will evaluate which solutions will help us best create customer value in a way that drives business value. 

The tree structure makes it easy to communicate the big picture while also diving into details when needed. Your tree should visually show what solutions you are considering and what tests you are running to evaluate those solutions. Instead of communicating your conclusions. 

Focusing On Outcomes Over Outputs

When we manage by outcomes, we give our teams the autonomy, responsibility, and ownership to chart their own path. Instead of asking them to delivery a fixed roadmap full of features by a specific date in time, we are asking them to solve a customer problem or to address a business need. 

This strategy leaves room for doubt. An outcome communicates uncertainty. It says, We know we need this problem solved, but we don't know the best way to solve it. It gives the product trio the latitude they need to explore and pivot when needed. 

Managing by outcomes communicates to the team how they should be measuring success. A clear outcome helps a team align around the work they should be prioritising, it helps them choose the right customer opportunities to address, it helps them measure the impact of their experiments. 

Visualising What You Know

It's easy when working in a team to experience groupthink. Groupthink occurs when a group of individuals underperform due to the dynamics of the group. It's critical that each member of the trio start by developing their own perspective before the trio works together to develop a shared perspective. 

• Start by turning each of your individual maps into a collection of nodes and links. A node is a distinct moment in time, an action, or an event, while links are what connect nodes together. 
• Create a new map that includes all of your individual nodes. 
• Collapse similar nodes together
• Determine the links between each node
• Add Context: What are they thinking, feeling and doing at each step of the journey? 

Continuous Interviewing 

The purpose of customer interviewing is not to ask your customers what you should build. Instead, the purpose of an interview is to discover and explore opportunities. Opportunities are customer needs, pain points, and desires. They are opportunities to intervene in your customers lives in a positive way. 

Too often in customer interviews, we ask direct questions. We ask, "What criteria do you use when purchasing a pair of jeans?" or "How often do you go to the gym?" But these types of questions invoke our ideal selves, and they encourage our brains to generate coherent but not necessarily reliable responses. 

Direct questions require that we recall facts without context. This process is prone to cognitive biases - common patterns in mental errors that result from the way our brain process information. 

The key to interviewing well is to distinguish what you are trying to learn (your research questions) from what you ask in the interview (your interview questions). Our primary research question in any interview should be: What needs, pain points, and desires matter most to this customer?

Since we can't ask our customers direct questions about their behaviour, the best way to learn about their needs, pain points, and desires is to ask them to share specific stories about their experience. You'll need to translate your research questions into interview questions that elicit these stories. 

Instead of asking, "What criteria do you use when purchasing a pair of jeans?" - a direct question that encourages our participant to speculate about their behaviour - we want to ask, "Tell me about the last time you purchased a pair of jeans." Excavating the story takes practice. It might feel awkward at first. It will definitely feel inefficient. 

An interview snapshot is a one-page designed to help you synthesise what you learned in a single interview. It's how you are going to turn your copious notes into actionable insights. 

Product trios should interview together. The more diverse your interviewing team, the more value you will get from each interview. 

Mapping The Opportunity Space

How do we decide which opportunities are more important than others? How do we know which should be addressed now and which can be pushed to tomorrow? It's hard to answer either of these questions if we don't first take an inventory of the opportunity space. 

Our job is to address customers opportunities that drive our desired outcome. That is how we create value for our business while creating value for our customers. Limiting our work to only the opportunities that might drive our desired outcomes is what ensures that our products are viable over the long run and not just desirable in the moment. 

The tree structure will help us visualise and understand the complexity of opportunity space. Trees depict two key relationships - parent-child relationship and sibling relationships. Both will help us make sense of the messy opportunity space. 

• The parent-child relationship will be used to represent subsets - a child opportunity is a subset of parent opportunity. 
• Siblings should be similar to each other - in that they are each a subset of the same parent - but distinct in that you can address one without addressing another. 

When we learn to think in the structure of trees, it helps us deconstruct large, intractable problems into series of smaller, more solvable problems. This allows us to ship value quickly. It might not solve the bigger opportunity completely, but it does solve a smaller need completely. Once we have accomplished that, we can move to the next small opportunity. Over time, as we continuously ship value, we'll chip away at the larger opportunity. Eventually, we'll have solved enough of the smaller opportunities that we will, in turn, have solved the larger opportunity. 

Prioritising Opportunities, Not Solutions

The vast majority of our conversations take place in the solution space. We assume that success comes from launching features. This is what is called "the build trap". This obsession with producing outputs is strangling us. Our customers don't care about the majority of our feature releases. A solution-first mindset is good at producing output, but it rarely produces outcomes. 

Our customers care about solving their needs, pain points and desires. Product strategy happens in opportunity space. Strategy emerges from the decisions we make about which outcomes to pursue, customers to serve, and opportunities to address. 

By addressing only one opportunity at a time, we unlock the ability to deliver value iteratively over time. Focusing on one opportunity at a time allows the trio to explore multiple solutions setting up good compare-and-contrast decisions. 

You won't be working with each top-level opportunity in isolation. You don't want to ask ,"Should we pursue this opportunity?" That's a "weather or not" question that leads to poor decisions. It makes us susceptible to confirmation bias, and we forget to consider opportunity cost. Instead, you'll compare and contrast the set of parent opportunities against each other. 

If your opportunity space is well structured, you can now ignore all but this branch of the tree for the rest of your assessment. If your chosen parent is the highest priority, then the highest-impact opportunity to address next will live under that branch. Then repeat this process for the children of our primary top-level opportunity. We'll compare and contrast the children against each other and choose a front runner. You always want to choose a leaf-node opportunity because our goal is to delivery iterative value over time. 

Teams should assess opportunities using the following criteria:

Opportunity sizing: This helps us answer the questions: "How many customers are affected and how often?"

Market factors: Help us evaluate how addressing each opportunity might affect our position in the market. 

Company factors: Help us evaluate the strategic impact of each opportunity for our company. 

Customer factors: Help us evaluate how important each opportunity is to our customers. 

Supercharged Ideation

Our first idea is rarely our best idea. As we generate more ideas, the diversity and novelty of those ideas increases. The most original ideas ten to be generated towards the end of the ideation session. We want to learn to push beyond our first mediocre and obvious ideas, and delve into the realm of more diverse, original ideas. 

Alternating between individual ideation and group sharing of ideas can improve the quality of ideas generated in subsequent individual ideation sessions. Participants should start by ideating on their own. Then they share their ideas with the group. Then they go back to ideating on their own.

Take advantage of incubation. Incubation occurs when your brain continues to consider a problem even after you've stopped consciously thinking about it. You've probably experienced this often in your life. After working on what seems like an unsolvable challenge all day, you finally go home and take a break. After a good night's sleep, you come to work, returning to the problem. Instantly, you identify a solution. 

Once you have generated 15-20 ideas for the same target opportunity, its time to start evaluating your ideas. Start by asking for each, "Does this idea solve the target opportunity?"

Next, you'll "dot-vote" as a team to whittle your set down from lots of ideas to three ideas. To dot-vote, allot three votes per member, As you vote, the only criteria you should be considering is how well the idea addresses the target opportunity. You aren't voting for the coolest, shiniest ideas. Nor are you ruling out the hardest or even impossible ideas. 

Everyone on the team should be excited about at least one idea, and each idea should have a strong advocate in the group. If that's not the case, revisit your set of ideas, and dot-vote again. 

Identifying Hidden Assumptions

Confirmation bias means we are more likely to seek out confirming evidence than we are to seek out disconfirming evidence. We pay attention to and remember the data that supports our perspective and often ignore or forget the data that undermines our perspective. 

The escalation of commitment is a bias in which the more we invest in an idea, the more committed we become to that idea. 

The best product teams complete a dozen or more discovery iterations every week. This pace is possible only when we step away from the concept of testing ideas and instead focus on testing the assumptions that need to be true in order for our ideas to succeed. By explicitly enumerating our assumptions, we can start to look for both confirming and disconfirming evidence to either support or refute each assumption. Additionally, assumption testing is faster than idea testing, and the faster pace helps us to guard against the escalation of commitment. 

Assumptions come in all shapes and sizes:

Desirability assumptions: Does anyone want it? Will our customers get value from it?

Viability assumptions: Should we build it? There are many ideas that will work for our customers but won't work for our business. If we want to continue to serve customers over time, we need to make sure that our solutions are viable - they create a return for our business.

Feasibility assumptions: Can we build it? We primarily think about feasibility as technical feasibility. 

Usability assumptions: Is it usable? Can customers find what they need? Will they understand how to use it or what they need to do?

Ethical assumptions: Is there any potential harm in building this idea? 

Story mapping is a popular technique in which teams map out each step end-user have to take to get value from a product or service. Story mapping forces you to get specific about how an idea will work and what you expect your end users will do. 

To story map your ideas:

• Start by assuming the solution already exists. 
• Identify the key actors. Who need to interact with whom for the idea to work?
• Map out the steps each actor has to take for anyone to get value from the solution. 
• Sequence the steps horizontally over time. 

Use your story map to uncover hidden assumptions. Throughout your story map, every time you assume that an end-user will do something, you are making desirability assumptions, usability assumptions and feasibility assumptions. Sometimes story maps can help us uncover viability and ethical assumptions as well.

Pre-mortems, happen at the start of the project and are designed to suss out what could go wrong in the future. It encourages you to ask "Imagine it's six months in the future; your product or initiative launched, and it was a complete failure. What went wrong?"

Another way to generate assumptions, particularly viability assumptions, is to use your opportunity solution tree to work backwards from your solution back to your outcome. 

Assumption mapping is an exercise to quickly identify "leap of faith" assumptions - the assumptions that carry the most risk and thus need to be tested. 

With assumption mapping, you'll be quickly evaluating each assumption on two dimensions: "How much do you know about this assumption?" and "How important this assumption is to the success of your idea?".

Each assumption lives in one spot on the two-dimensional grid. We are going to start by testing the assumptions in the top-most, right-most corner. We will start with two or thee assumptions that fall in the upper-right corner. Those are the most important assumptions with the weakest evidence - the assumptions that are called your "leap of faith" assumptions.

Testing Assumptions, Not Ideas

As we start assumption testing, we want to make sure that we carry forward the idea of comparing and contrasting our ideas against each other. We want to systematically collect evidence about our assumptions underlying all three ideas. The more we learn about each idea, the more likely we are to compare and contrast the ideas against each other. 

To collect reliable data, we want to focus on collecting data about what people actually do in a particular context, not just what they think or say they do in general. A strong assumption test simulates an experience, giving your participants the opportunity to behave either in accordance with your assumption or not. This behaviour is what allows us to evaluate our assumptions. 

We don't want to invest the time, energy and effort into an experiment if we don't even have an early signal that we are on the right track. Rather than starting with a large scale experiment, we want to start small. 

With assumption testing, most of our learning comes from failed tests. That's when we learn that something we though was true might not be. Small tests give us chance to fail sooner. Failing faster is what allows us to quickly move on to the next assumption, idea, or opportunity. 

There are two tools that should be in every product team's toolbox - unmoderated user testing and one-question surveys. 

Unmoderated user testing service allows you to post a stimulus and define tasks to complete and questions to answer. Participants then complete the tasks and answer the questions on their own time. 

Many assumptions can be tested with quick answers to a single question. This is where one-question survey tools can be tremendously helpful. 

Measuring Impact

It's easy to get caught up in successful assumption tests. The world is full of good ideas that will succeed on some level. However, an outcome-focused product trio needs to stay focused on the end goal - driving the desired outcome. We need to remember to measure not just what we need to evaluate our assumption tests, but also what we need to measure impact on our outcomes. 

Managing The Cycles

It's easy to think that, if we simply follow the process, we'll come out the other side with a product that customer love. Unfortunately, it's not that simple. The reality is this process is a messy, winding path with lots of twists and turns. Most of the work in discovery is not following the process - it's managing the cycles. The fruit of discovery work is often the time we save when we decide not to build something. 

Show Your Work

When preparing for a meeting with stakeholders, we tend to focus on our conclusions - our roadmap, our release plan, our prioritised backlog. The challenge with this approach is that our stakeholders often have their own conclusions. It's easy to have an opinion about outputs. When we anchor the conversation in the solution space, we encourage our stakeholders to share their own preferences. When you frame the conversation in the solution space, you are framing the conversation to be about your opinion about what to build versus your stakeholders opinion. 

When meeting the stakeholders, don't start with your conclusions. Instead, slow down and show your work. Start at the top of your opportunity solution tree. Your stakeholder needs to fully understand the opportunity you are pursuing before you share solutions with the. This is what sets the context for how to evaluate solutions and moves the conversation away from opinions and preferences. 

Start Small, And Iterate 

When product teams engage with their customers week over week, they don't just get the benefit of interviewing more often - they also start rapid prototyping and experimenting more often. They remember to doubt what they know and to test their assumptions. They do a better job of connecting what they are learning from their research activities with the product decisions they are making. 

Conclusion

This book is a bible for product development. It explains the right way to build the product with so much detail, I am a big fan. I would highly recommend reading this book for anyone working on the product!