The main idea of the book:
It is based on the learnings from continuous discovery habits coaching program, Teresa's experience in product companies, and as a product coach. It also aligns with Marty Cagan's philosophy of Product Operating Model.
She argues that human centered design should be obvious - i.e. customer focus rather than competitors etc. A good product team obsesses about customer needs, pain points and desires and invests a lot in aligning customer and business needs in creating the best products. To do that, the team must focus on doing right kind of continuous product discovery.
Chapter wise summary from the book:
Part 1: What is continuous discovery?
Chapter 1: What and why of continuous discovery
Agile manifesto:
It advocated for shorter cycles with more frequent customer feedback.
It proposed working at a pace that could be sustained continuously, rather than furiously scurrying from one milestone to another.
It advocated for maximum flexibility—having the ability to adapt to customer feedback quickly and easily.
It advocated for simplicity.
Cross-functional team are mainly composed of "product trio" i.e. product managers, designers, and software engineers:
Product managers bring the business context—they help teams ensure that the products they are building are viable for the business. They ensure that the business that supports the product will survive over time, allowing the team to further satisfy customers’ needs.
Designers bring visual, interactive, and systems design chops that help to ensure that customers will understand how to best use a product and delight in that use.
Software engineers bring the technical chops to ensure that the product is reliable, stable, and delivers on its promise.
All three roles are critical to the success of any digital product. They are collectively responsible for ensuring that their products create value for the customer in a way that creates value for the business.
Chapter 2: A common framework for continuous discovery
The 6 pre-requisite mindsets:
Outcome oriented: think about outcomes rather than output. That means rather than defining your success by the code that you ship (your output), you define success as the value that code creates for your customers and for your business (the outcomes). Rather than features (the output), we should care about the impact (the outcome).
Customer-centric: Place the customer at the center of your product world. Customer need must be at par with the business need.
Collaborative: Reject siloed model and make team decisions while leveraging the expertise and knowledge of the individuals.
Visual: move beyond written and spoken language and try to create visual / spatial thinkers. (optionally see: Mind in motion: https://www.youtube.com/watch?v=gmc4wEL2aPQ)
Experimental: Become scientists in identifying and conforming assumptions. Experimental mindset is needed.
Continuous: Discovery is not in a phase but should be continuously done across the development process.
What should continuous discovery look like?
Min. weekly touchpoints with customers
By team who builds the product
By conducting small research activities
In pursuit of desired outcomes.
At many companies, there is a tension between business needs and customer needs. Example:
Advertisements before you can see the content
Showing extra costs after you are in the middle of booking
Delaying checkout so that you need to go through other enticing products
Additional points:
Peter Drucker "Goal of a business is to convert society's needs into opportunities for a profitable business.
Begin with the end in mind - i.e. start from thinking the outcomes of your product rather than the features.
Because products such as ice cream and Disney are not solving problems but fulfilling a desire or tapping into an opportunity, Rather than customer problem, we call them opportunities, i.e. customer needs, pain points, and desires.
A sample OST:
The root of the tree is your desired outcome: The business need that reflects how your team can create business value, i.e. the value created for the company or organization you work for.
Next is the opportunity space: These are the customer needs, pain points, and desires that, if addressed, will drive your desired outcome. I.e. the various opportunity spaces are different customer opportunities we have, but all of them satisfy our business need too.
Below the opportunity space is the solution space: This is where we’ll visually depict the solutions we are exploring.
Below the solution space are assumption tests: This is how we’ll evaluate which solutions will help us best create customer value in a way that drives business value.
Only include opportunities which was relevant to your outcomes
By mapping the opportunity space, the team is adopting a customer-centric framing for how they might reach their outcome.
A visual shared understanding through the OST helps bring the team together, avoid opinion battles, and work together towards identifying many possible solutions and selecting the best one.
Four villains which lead to poor decision making:
Looking at a problem too narrowly
Looking for evidence which confirms our beliefs (i.e. confirmation bias)
Letting short term emotions affect our decision - i.e. falling in love with our sudden impulses
Overconfidence - that our ideas will be successful.
Whenever there is a request from stakeholders, the first thing we ask ourselves is "whether or not to build the feature?" We should avoid it. We should rather see it the suggestion as just one option and check for other solutions to fulfill the opportunity. i.e. we should ask
"What else could we build?"
And once we have a few solution ideas, we should ask
"which of these customer needs is the most important for us to address right now?"
Good discovery doesn't prevent us from failing. It simply reduces the chances of failure, but failures will still happen.
Rather than product manager being responsible for the problem space, the trio together is responsible for the problem and opportunity space both.
Both problem and opportunity space evolve together as we find out new ideas and see if they will work or not.
How to communicate to your stakeholders:
The key to bringing stakeholders along is to show your work. You want to summarize what you are learning in a way that is easy to understand, that highlights your key decision points and the options that you considered, and creates space for them to give constructive feedback. A well-constructed opportunity solution tree does exactly this. Rather than communicating your conclusions, you are showing your thinking and learning that got you there. This allows your stakeholders to truly evaluate your work and give you feedback on basis of the information you have gathered till now.
Part 2: Continuous discovery habits
Ch. 3: Focus on outcomes over outputs
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. If the product trio finds flaws with their initial solution, they can quickly shift to a new idea, often trying several before they ultimately find what will drive the desired outcome.
As a general rule, product trios will make more progress on a product outcome rather than a business outcome. Remember, product outcomes measure how well the product moves the business forward. By definition, a product outcome is within the product trio’s span of control. Business outcomes, on the other hand, often require coordination across many business functions.
E.g. a company which makes dog food:
We can increase the accountability of each team by assigning a metric that is relevant to their own work.
product team which makes dog food, a good outcome is increasing the no. of dogs who like the food. This is in control of the product team.
Marketing team - good outcome is - more dog owners are aware of the benefits of the product and come to try the product i.e. the dog food
Customer-support team - good outcome - decrease the average response times while maintaining customer satisfaction level. Together all three groups are contributing to the business outcome of increasing customer retention.
The product trio brings customer and technology knowledge to the conversation and should communicate how much the team can move the metric in the designated period of time (usually one calendar quarter). The trio should not be required to communicate what solutions they will build at this time, as this should emerge from discovery.
If the business needs the team to have a bigger impact on the outcome, the trio will need to adjust their strategy to be more ambitious, and the product leader will need to understand that more ambitious outcomes carry more risk. The team will need to make bigger bets to increase their chance of success, but these bigger bets typically come with a higher chance of failure. Similarly, the product leader and product trio can negotiate resources (e.g., adding engineers to the team) and/or remove competing tasks from the team’s backlog, giving them more time to focus on delivering their outcome
stable product trio focused on the same outcome over time is so critical. Every time we mix up the team or change the outcome, we take a learning tax as the team gets up to speed
The research suggests that product trios, when faced with a new outcome, should first start with a learning goal (e.g., discover the opportunities that will drive engagement) before being tasked with a performance goal (e.g., increase engagement by 10%). This approach can be particularly helpful because it’s common to have uncertainty around the best way to measure your outcome. So first a learning goal, then follow it with smart performance goal when it can be comfortably set.
Product trios tend to fall into four categories when it comes to setting outcomes:
they are asked to deliver outputs and don’t work toward outcomes (this is, by far, the most common scenario);
their product leader sets their outcome with little input from the team;
the product trio sets their own outcomes with little input from their product leader;
the product trio is negotiating their outcomes with their leaders
In all the 4 scenarios, try to renegotiate and come to a good product outcome for your product. To see ideas on how to do it, check book pg. 45.
Avoiding anti-patterns:
Too many outcomes at once -> have only one outcome at a time.
Shifting between outcomes every few months -> assign an outcome and stick to achieving it for a few quarters at least.
Setting individual outcomes in the Trio -> it is detrimental. Set team outcome always (i.e. outcome for the trio together)
Setting outputs rather than outcomes -> To shift your outcome from less of an output to more of an outcome, question the impact it will have.
Focusing on one outcome to the detriment of some other important outcome -> primary outcome should be combined with monitoring health metrics that make sure there aren't long term detrimental effect elsewhere. It should be made sure by the trio or a supporting team to inform the trio whenever the set outcome achievement is worsening some other outcome.
Ch 4: Visualizing what you know
Start with your desired outcome and how can we achieve it.
Define a scope for exploration. This scope shouldn't be too broad because that can become overwhelming, but also too narrow that we exclude innovative ideas.
There’s not one right scope. The key is to have a conversation as a team about the scope that gives you room to explore while staying focused on your outcome.
Once you’ve defined the scope of your experience map, you are ready to take an inventory of your individual knowledge before working to develop a shared understanding of what you collectively know
Every member of trio should start developing their own perspective of the solution and ideas / information before working together to make a common view. This is because group think makes a group perform at the level of least capable member. We must counter that in a Trio.
In instances where it’s important that we explore multiple perspectives, the easiest way to get there is for each product trio member to do the work individually
Rather than text, use just drawing. Drawing is more specific. It forces you to be concrete. You can't draw something specific if you haven't taken the time to get clear on what those specifics are.
Try to draw what you know and not to generalize vague thoughts about your customer.
Explore the diverse drawings from the trio and ask questions to understand their viewpoint.
Rather than finding errors, try to find differences and be curious why they did what they did.
Once you have a clear understanding of everyone's perspectives, draw a shared team perspective.
Create the final map using nodes (events / experiences) and links (connecting the nodes) and all the needed context.
Avoid anti-patterns:
Getting into endless debates -> debates might even happen when you both agree. So, just draw and it will show the exact moments of difference of opinion. And you can capture both first.
Using words instead of visuals -> use boxes, arrows and stick figures. Everything works. Drawing engages a different part of your brain than language does and helps us see patterns which are not detectable in words many times.
Moving forward as if your map is true -> it is your perception of truth, but the customer testing needs to be done before the map can be acted upon.
Forgetting to evolve the map as you learn more -> evolving the map visually will keep the team perspective clear and shared.
Chapter 5: Continuous Interviewing
Any product trio should build the habit of interviewing weekly.
The purpose of interviewing is not to ask your customer what you should build. Instead, the purpose of an interview is to discover and explore opportunities.
As we saw with visual voicemail, we can’t always rely on our customers to tell us what they need or want. Instead, you’ll learn how to use your customers’ own stories to discover their unmet needs.
Customers are not very good at understanding their own behavior. Our brains are exceptionally good at creating coherent (but not necessarily true) stories that deceive us.
We built a product based on a coherent story told by both the thought leaders in our space and by our customers themselves. But it wasn’t a story that was based in reality. If you want to build a successful product, you need to understand your customers’ actual behavior—their reality—not the story they tell themselves.
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 behavior, 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 you use when purchasing a pair of jeans?" ask "tell me about the last time you purchased a pair of jeans?". This story tells what behavior happened rather than perceived behavior.
So ask experience stories related to an experience rather than decision making criteria related to that experience
Also the question will keep changing depending on the stage we are in defining the experience map. The same customer or a new customer is visited every week or so, so the amount of questions can be kept more specific to the problem at hand in that week.
When asking for the story, inform them to tell the story in full detail and you will ask the missing details as follow up questions after their experience.
If the customer is still not going in the details, start from where you want to start (location, mood, whatever) and ask "Where" "how" "what" questions about the experience if needed to dig the details. You can use your experience map to find out the right nodes and links to ask questions about.
Keep the interview grounded in specific stories to ensure that you collect data about your participants’ actual behavior, not their perceived behavior.
The golden rule of interviewing is to let the participant talk about what they care about most.
When we rarely interview, a disappointing interview can feel painful. When we interview continuously, a disappointing interview is easily forgotten
With the help of interview snapshot, you need to keep on synthesizing as you go.
These interview snapshots will help you remember specific stories
The more visual your snapshot, the easier it will be for the team to remember the story your collected - even weeks and months after.
Quick facts section help you understand how the stories you heard in the interview might be similar or different from those you heard in other interviews from other customers.
The photo or memorable quotes will act as the key to unlock these specific interview memories.
Opportunities are needs and not solutions. Be sure to represent opportunities as needs and not solutions.
If the participant requests a specific feature or solution, ask about why they need that, and capture the opportunity (rather than the solution). A good way to do this is to ask, “If you had that feature, what would that do for you?”
Example: "I wish I could just say the name of movie I am searching for" … question if you have this feature, what would that do for you? "no need to type long for movie" … two possibilities (rather than one) opened up, 1. voice command 2. auto complete.
Draw the stories you collect similar to experience map using nodes and links. This way it is easy to identify a pattern across multiple interviews as well as keep your team aligned on the interview outcomes.
Weekly interviewing is a strong delivery practice. We don’t want to think about interviewing as a step in a linear process. Instead, our goal is to interview continuously.
About continuous interviews benefits " We killed an opportunity on Tuesday, chose a new one on Wednesday, and used our already-scheduled interviews on Thursday to learn about the new opportunity.”
From a habit standpoint, starting or stopping a habit is way more difficult than continuing the habit. So, To nurture your interviewing habit, interview at least one customer every week.
Automate the customer recruiting process so that irrespective of the circumstances (escalation, sick leaves, high work load), the interviewing is never sacrificed. When a customer interview is automatically added to your calendar each week, it becomes easier to interview than not to interview. This is your goal.
Recruit the people who are using your product / service or are interested in using them at the closest interaction level. That means if they are using your product, ask if they would be willing to sign up for an interview for 10€ or so. If they are visiting your site, ask them to schedule a meeting with you, if the product is not launched, just run ads and ask the people clicking on the ads and landing on your webpage to give you the interview for money.
You can also ask the customer facing teams to recruit for you. They can do it by including you in a call with customer and you can ask your questions in the last 5 mins. Also, you can give them triggers when they should schedule an interview between you and the customer. Such as in case of any complaints, schedule an interview. A subscription cancellation, a customization request. Any chance to talk with a customer can be turned into a short interview opportunity for you.
Example: "I’d love for you to share your feedback with our product team. Can we schedule 20 minutes for you to talk with them?” If they say “Yes,” have your colleague schedule the interview.
While most product teams worry their customers are too busy to talk with them, for most teams, this won’t be true. We dramatically underestimate how much our customers want to help.
In case of very low number of customers or high value customers (CEOs, billionaires etc.), try to get regular interviews with customers in customer advisory board of the company. In this case, the customers remain the same, so try to mix it with the other methods to get a wider customer range for your product opportunity finding.
Product trios should interview together. Rather than one being able to customer voice and dominate discussions, the goal is for all team members to be the voice of the customer. That is why the Trio should interview together. Also, various professional backgrounds pick various part and criticality of the story, so by having trio, the final story is way richer.
Avoid anti-patterns:
Relying on one person to recruit and interview -> reduce dependency on one person and make the whole team habitual to recruit and interview
Asking who, what, why, how, and when questions -> don't ask these overwhelming questions. Rather stick to story based questions which start with "Tell me about a specific time when …"
Interviewing only when you need it -> continuing interview habits is easier than starting and stopping it.
Sharing your notes or recording -> rather than the whole interview or transcript, send a short summary such as the interview snapshots. This way you only share the most relevant part of interview and don't make the investment part for the consumer too big.
Stop to synthesize a list of interviews -> never start or stop. Just keep synthesizing it on a continuous manner every few days.
Chapter 6: Mapping the opportunity space
Our job is not to address every customer opportunity. Our job is to address customer opportunities that drive our desired outcome. This 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 outcome is what ensures that our products are viable over the long run and not just desirable in the moment.
Our goal should be to address the customer opportunities that will have the biggest impact on our outcome first. To do this, we need to start by taking an inventory of the possibilities.
Therefore, opportunity space should be mapped using the Opportunity solution Tree (OST was introduced in Ch 2). A sample is below:
There are two benefits of using the OST.
Tackle big problems step by step by handling the sub-problem
Delivery value fast, and over a long time (aligns with Agile manifesto as well)
This structuring is hard work but pays off very well in long run
Each opportunity should be distinct from every other opportunity.
To help with the map, you can use either the customer interview stories or our opportunity map. Map the identified opportunities across the nodes / links to keep a clear account of all opportunities across an experience / timeline.
For adding any opportunity, always ask:
Is this opportunity framed as a customer need, pain point, or desire and not a solution?
Is this opportunity unique to this customer, or have we seen it in more than one interview?
If we address this opportunity, will it drive our desired outcome?
The trick is to find the sweet spot between giving you enough structure to see the big picture, but not so much that you are overwhelmed with detail.
This is not one and done exercise. The opportunity tree will change and evolve with time and you will visit it very often.
Avoid common Anti-patterns:
Opportunities framed from your company's perspective -> Always frame opportunities from customer perspective. Always ask the question for any opportunity: "Have we heard this in an interview?" or "can you imagine a customer saying this?"
Solution framed as opportunities -> An opportunity should have at least two different solutions. If it is just one solution, then most probably it is a solution disguised as opportunity. Only write opportunities and not solutions in the map. This way you have more options on how to exploit an opportunity.
Capturing feeling as opportunities -> we can't do much about feelings, but the opportunities which lead to these feelings. So, try to find the opportunity and write it rather than directly writing the feeling the opportunity is creating (anger, frustration, excitement etc.).
Avoid vertical 1:1 mapping opportunities, one opportunity having multiple parent opportunities, and opportunities not being too specific.
Chapter 7: Prioritizing opportunities, not solutions
Start from the top of the opportunities tree and compare between the different opportunities and pick one opportunity.
This way all other opportunities with their sub and sub-sub opportunities are excluded for now.
Keep doing this way of compare and prioritize across the whole vertical of the opportunity you selected till you reach the leaf level opportunity.
For assessing the opportunities, use the following criteria:
Opportunity sizing: how many customers are affected and how often? Find the answer approximately rather than investing a lot of time effort into calculating exact values.
Market factors: what seems to be the most attractive as per the market (competition, gap, regulations etc.)
Company factors: what seems to be the most attractive as per your company (or team's or group) uniqueness / strategy /politics / strengths / weaknesses at the moment.
Customer factors: As per the importance of the opportunities for a customer. We want to prioritize important opportunities where satisfaction with the current solution is low, over opportunities that are less important or where satisfaction with current opportunities is already high.
Embrace the messiness: You might be tempted to score each opportunity based on the different factors (e.g., 2 out of 3 for sizing, 1 out of 3 for market factors, and so on) and then stack-rank your opportunities, much like you might do with features. Don’t do this. This is a messy, subjective decision, and you want to keep it that way. The messiness will lead to healthy debates and lead to the best shared answers at that moment.
For one way door decisions (or irreversible, big impact decisions), be cautious, consider data, time and carefully decide, mistakes will be costly.
For two way door decisions (reversible, low impact decisions), just try it out and see what happens. Taking the decision, and experience will teach you way more than being cautious and slow here.
If we want to stay open to being wrong and avoid confirmation bias, it’s critical that we think of our prioritization decisions as reversible decisions.
So, as you assess and prioritize the opportunity space, relax. Make the best decision you can, given what you know today, and know that, if you got it wrong, we’ll simply revisit the decision when we need to
Avoid anti-patterns:
Delaying decision to gather more data -> as said, for two way door types decision, doing and failing is better than slowing or not taking actions. To avoid paralysis by analysis, time box your decision making. Trust that you can course correct later on if needed.
Over-relying on one criteria at cost of others -> All 4 criteria above (opportunity size, market, company and customer factor) are important to be considered. If we skip a few of these, we might create a solution which might not fit all the requirements (customer, company, viability, profitability etc.)
Working backwards from already decided conclusions -> Go with open mind and the process and outcomes might surprise you with new perspectives.
Part 2: Discovering solutions
Chapter 8: Supercharged Ideation
Many product teams jump into solution mode too quickly, leading to them settling on suboptimal solutions.
Quantity leads to quality in ideation: Generating a large number of ideas leads to more diverse and original ideas. The best ideas tend to emerge later in the ideation process.
Brainstorming is a well-known ideation technique, but it can be unproductive, especially in groups.
Individual ideation, followed by group sharing, followed by more individual ideation and so forth is the most effective way to generate high-quality ideas from a group.
To get best ideas:
Spread ideating across the day but in short duration per ideation session with frequent breaks in between various sessions.
E.g. in the few minutes between meetings, after lunch walks, short daydreams etc.
Ideate at different times and places
Taking advantage of incubation: Problem solving by unconscious part of our mind
Looking to analogous products for inspiration (competitors and beyond)
Think about the needs of specific user groups (power users, remote users, young, senior etc.)
Think about wild ideas (with a magic wand)
Anti-patterns to avoid:
Not including diverse perspectives in the ideation process. The ideation should be done with the entire team and not just in Trio.
Generating too many variations of the same idea -> try to select deliberately categorically different ideas.
Evaluating ideas during the ideation process
Limiting ideation to one session only -> take advantage of brain's innate ability to incubate & work on a problem.
Generating ideas that are outside the scope of the target opportunity
Chapter 9: 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 commitment46 is a bias in which the more we invest in an idea, the more committed we become to that idea.
Product teams often overcommit to ideas, leading to wasted time and effort when the ideas fail. This happens due to cognitive biases like confirmation bias and escalation of commitment.
Story map your ideas
It will force you to get specific about how exactly the idea will work and interaction with end users.
Think that the idea already exists and map how you think it is interacting with the end users.
Map all the key actors (including your solution, chatbot or whatever) and actions by every actor to get the value from the solution.
It is ok to generate as many assumptions as possible at every step of the idea. It helps us uncover the risky ones which may actually be false.
If our desired outcome is a product outcome (as it should be), we might also need to test the assumptions connecting our product outcome to our business outcome to uncover viability assumptions.
Importance of an assumption is based on how easy or difficult will it be to pivot in case the assumption is false. If this wrong assumption will kill the product, it is very important. If it is not a big deal to circumvent, it is a less important assumption.
The exercise doesn't have to be exactly correct, but can be relative and approximate to the other assumptions.
Rather than debating a lot, go through this fast (10 mins or so). In experience, the result is the same even if you take a lot of time doing it.
Anti-patterns to avoid:
Not generating enough assumptions, especially risky ones: Use the five assumption categories and the exercises in this chapter to help you generate as many assumptions as you can. The more the merrier because it helps identify the most risky ones.
Phrasing assumptions in a way that makes them hard to disprove -> When you are generating assumptions, always phrase your assumptions such that you need them to be true for your idea to work. Positive framing is easier to test.
Not being specific enough in assumptions -> Rather than saying "customers will have time", put the assumption as "customers will take time to go through help section to find their answers"
Forgetting to test certain categories of assumptions (e.g. desirability and ethical assumptions).
Chapter 10: Testing Assumptions, Not Ideas
Continuously test assumptions underlying a set of ideas instead of focusing on one idea at a time to avoid overcommitment and confirmation bias.
Focus on simulating experiences and evaluating behavior in your assumption tests.
None of the simulation can be perfect and that is fine. Try to be as close as possible in least investment possible.
While evaluating an assumption, be exact on the evaluation / success criteria, i.e. for how many people out of how many people should be the assumption true to label the assumption as true. By setting it up-front, we make the assumption test actionable and also guard against confirmation bias due to no specificity.
Also, try to keep the tests as simple and don't boil the ocean. We just want to reduce the danger of a wrong assumption. i.e. move the assumptions from left to right (low evidence to high evidence).
Small tests will still teach us a lot even with a higher risk of false negatives or positives. Our high frequency of tests, will point out the error in any of the upcoming tests most of the time.
Our goal as a product team is not to seek the absolute scientific truth but to mitigate risk. That is why we go for quick and dirty tests based on scientific principles, but don't go for rigorous scientific tests to check assumptions, it would be an overkill in terms of time, money and effort.
Types of assumption tests:
Unmoderated user testing (e.g. through Prototype): Evaluate user behavior by using a prototype (low-fidelity, high-fidelity, live prototype). Record their behavior with the prototype and ask them to answer already provided Q&As. It is unmoderated so you get a recording of what happened and their answers to the questions you wanted without investing interview people all the time.
One-question surveys: Gather quick data on user needs, preferences, and behaviors.
Anti-patterns to avoid:
Too complex simulations -> keep it low effort tests as much as possible.
Using percentages as evaluation success criteria -> when testing in low numbers, absolute numbers give more context (2 out of 5 is still very close to 3 out of 5 but has a 20% difference).
Not enough evaluation criteria -> define every aspect of the evaluation criteria and don't leave thinks to approximations and guessing afterwards.
Wrong sample -> always try to find the right audience to test the assumptions with and have enough variations representative of your actual population.
Design and test with less than ideal scenarios -> always first test with ideal scenarios. Even there many a times, your tests will fail and will save you the effort to test with less probably scenarios.
Chapter 11: Measuring Impact
Measuring the impact of your work goes beyond evaluating assumption tests; it involves understanding how those tests relate to your desired outcome.
Discovery and delivery are iterative and intertwined: Delivery work can inform and refine your discovery efforts and vice versa.
Instead of measuring everything, focus on:
Distinguish between:
Business outcomes: High-level goals that drive your business
Product outcomes: Measurable changes in user behavior that contribute to business outcomes
Traction metrics: Short-term indicators of progress towards product outcomes
In the example of a job search portal,
business outcome is to increase no. of students who founds jobs through the portal
Product outcome can be to improve no. of students who come to the portal or % of people who are satisfied with the portal
Remember that driving product outcomes is only valuable if it ultimately leads to achieving your desired business outcome.
Chapter 12: Managing the Cycles
Anti-patterns to avoid:
Overcommitting to an opportunity even when it becomes clear it's not viable at the moment: we want to run quick tests rather than overinvest in the best tests
Avoiding hard opportunities: Doing quick doesn't mean avoiding hard opportunities. It means maximizing Return on Investment at any time. Once the groundwork is there, or if RoI is big, hard opportunities should be taken on rather than avoided.
Drawing conclusions from shallow learnings
Giving up before small changes add up to big rewards
Chapter 13: Show Your Work
Stakeholder management is crucial for successful continuous discovery. HiPPo always wins (Highest paid person's opinion).
Instead of just sharing your conclusions, involve stakeholders by:
Sharing your process and rationale
Seeking their input on opportunities, solutions, and assumptions
Showing them how your work is driving towards the desired outcome
Adjust the level of detail based on your audience.
Anti-patterns to avoid:
Sharing too much or too little information with stakeholders: Don't have the bias because of the "Curse of knowledge". Walk in their shoes and take them through the journey you have taken and ask for their advice through the journey.
Dismissing stakeholder concerns or feedback due to ego or whatever.
PART 3 - DEVELOPING YOUR CONTINUOUS DISCOVERY HABITS
Chapter 14: Start Small, and Iterate
Even in organizations that don't fully embrace continuous discovery, you can start implementing these habits gradually.
If you don't have a formal product trio:
Identify individuals who can represent the three parts of the trio. If you are the PM, find design and engineering perspectives and build relationships with them.
Involve them in discovery activities as much as possible.
Your guiding principle is simple: How can I include all three disciplines in as many discovery decisions as I can?
Make next week look better than last week.
Keystone habit: comes from Charles Duhigg’s book The Power of Habit: Why We Do What We Do in Life and Business. Duhigg argues, “Keystone habits start a process that, over time, transforms everything.” They are habits that, once adopted, drive the adoption of other habits.
Start with the keystone habit: continuous weekly interviewing. Find a way to do that and other things will slowly improve already.
If you primarily work on delivery, work backward:
Use retrospectives to identify areas for improvement in your discovery process.
Anti-patterns to avoid:
Focusing on why continuous discovery won't work in your context instead of finding ways to make it work -> adapt it and it will work.
Being dogmatic about the "right way" to do discovery -> there is not just one right way. Create your own using the fundamental ideas in the book.
Waiting for permission instead of starting with what you can control. Go talk to customer or anyone who looks similar to your customer.
Don’t let perfect be the enemy of good. Continuous trying and slowly improving is the key
