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!