Literary Insights

“If you liked the book, you can purchase it using the links in the description below. By buying through these links, you contribute to the blog without paying any extra, as we receive a small commission. This helps us bring more quality content to you!”

BOOK LINK:

CLICK HERE

Here is a summary of the key points about copyrighted material:

The passage is copyrighted by Teresa Torres in 2021. No part of it can be reproduced without permission from the publisher.
It provides publishing details like the publisher name (Product Talk LLC), author, editor, cover art designers, interior designer, Library of Congress control number, ISBN number, and place/year of printing.
It contains a table of contents listing the chapter titles in the book.
There are two forewords - one by Chris Mercuri and one by Marty Cagan, praising the Continuous Discovery Habits approach laid out in the book.
The introduction shares a brief anecdote by the author about leading a product team at a startup in 2013 and eventually quitting due to exhaustion from arguing with others who did not spend time with customers.
The passage provides an overview of the book’s structure with parts on what continuous discovery is, the continuous discovery habits, and developing those habits.

That covers the key highlights regarding the copyrighted material in the passage. Let me know if you need any clarification or have additional questions.

The passage discusses the evolution of modern product discovery approaches, from traditional approaches focused primarily on delivery to more modern approaches emphasizing continuous discovery.
Traditionally, discovery was not done by product teams and happened once a year through a budgeting process. Projects had fixed timelines and challenges often arose.
In 2001, the Agile manifesto advocated for shorter cycles with frequent customer feedback, continuously sustainable pace, flexibility to adapt, and simplicity. This influenced the rise of frameworks like Scrum and Kanban.
While these helped with more feedback and iterations, challenges remained as business owners clung to ideas and teams were still measured on delivery over discovery/impact.
Improvements like more instrumenting, testing, iterating helped but teams still built the wrong things at times.
Today, approaches emphasize involving customers throughout discovery, co-creating ideas, and shorter discovery cycles aligned with delivery. Teams are adopting, developing and improving continuous discovery approaches.

In summary, it traces the evolution from traditional delivery-focused approaches to more modern approaches emphasizing continuous customer discovery and alignment between discovery and delivery cycles.

The book is for product teams, specifically product managers, designers, and software engineers who want to build products customers love.
It outlines habits for a “product trio” (PM, designer, engineer) to continuously learn from customers and adapt products.
The mindsets needed to successfully adopt these habits are being outcome-oriented, customer-centric, collaborative, visual, experimental, and continuous.
Continuous discovery is defined as minimum weekly touchpoints with customers by the product team, conducting small research activities to pursue business/customer outcomes.
The goal is to infuse daily product decisions with as much customer input as possible through a structured and sustainable process of learning from customers week over week.
This will help teams avoid making decisions for months at a time without customer input, and build better products through continuous learning and adaptation.

So in summary, the book provides a framework and habits for product teams, especially the core “product trio”, to adopt a mindset and process of continuous discovery whereby they learn from customers on a weekly basis to constantly improve their products.

Wells Fargo was fined $185 million for opening fraudulent customer accounts without permission in an attempt to meet aggressive account-opening targets. This prioritized short-term business goals over ethical customer treatment.
While Wells Fargo’s actions were exceptional, focusing on outcomes at the expense of customers is common. Companies often prioritize revenue goals over customer experience through tactics like excessive ads, restricted streaming access, or hidden fees.
To achieve both business and customer goals, companies should view their purpose as serving customer needs, not just profit. If products meet real customer needs, profits will follow.
When given outcome goals, product teams must choose between prioritizing customers through research or taking shortcuts at their expense. Organizational culture influences this choice.
Driving outcomes is challenging as it requires framing open-ended “wicked problems” through customer research. How teams define opportunities impacts the solution space. Multiple problem frames should be explored.
Effective discovery has an underlying structure: define the outcome, discover and map opportunities, then find solutions addressing those opportunities to achieve the goal. This process provides guidance.

Here is a summary of the key points about opportunity solution trees (OSTs):

OSTs visually map out the path to achieving a desired business outcome. The root is the business need/outcome.
It includes the opportunity space of customer needs/pains that could drive the outcome.
The solution space depicts potential solutions to address the opportunities.
Assumption tests are how solutions will be evaluated to create customer and business value.
Benefits of OSTs include resolving tensions between business and customer needs, building shared understanding across teams, adopting a continuous mindset, unlocking better decision-making, faster learning cycles, and simpler stakeholder management.
They help compare solutions and avoid “whether or not” decisions that look at problems narrowly. They promote exploring multiple options.
Visualizing decisions on the tree allows revisiting past choices and course-correcting more easily.
OSTs integrate problem definition and solution generation, allowing these activities to evolve together through testing assumptions.

So in summary, OSTs provide a framework to strategically map out and test various paths to achieving business goals in an integrated, collaborative and learning-focused way.

The passage discusses the importance of focusing on outcomes rather than outputs when doing continuous discovery work. Outcomes refer to changes in customer behavior or metrics that drive business results, while outputs refer to specific features or deliverables.
It describes challenges Sonja Martin’s team faced when trying to improve customer retention at a pet food subscription company. They struggled to tie product changes to their 90-day retention metric and ended up adjusting shorter-term metrics, but weren’t sure if those drove the true business outcome.
Through customer interviews, they identified two product outcomes they could directly impact - increasing perceived value of tailored dog food and increasing the number of dogs that like the food. These outcomes were more actionable and they believed driving these would improve retention.
Shifting to an outcome mindset is difficult - teams have to identify connections between product outcomes they can influence and business outcomes. They may need to negotiate appropriate product outcomes with leadership.
The passage advocates for letting teams chart their own path to solving problems rather than dictating specific deliverables. An outcome mindset gives autonomy to continuously discover the best solutions.
Managing by outcomes rather than fixed roadmaps or outputs provides teams more flexibility to explore solutions and pivot if needed. It acknowledges uncertainty in problem-solving.
There are different types of outcomes - business outcomes measure overall business success, product outcomes measure how the product moves the business forward, traction metrics measure usage of specific features. Product teams are generally better suited to product outcomes than business outcomes.
When setting outcomes, it’s important to choose leading indicators that teams can directly influence rather than lagging business metrics. Product outcomes give teams more autonomy than assigning traction metrics like feature usage.
Setting outcomes is a two-way negotiation between product leaders who provide strategic context and product teams who estimate their impact. Leaders don’t dictate solutions but refine outcomes, while teams commit to moving metrics within a time period through discovery rather than predetermined solutions. It’s a balanced process.
Product trios should negotiate outcomes with their product leader, not have outcomes assigned unilaterally. This two-way negotiation helps ensure business context is captured and the team is invested in the outcome.
Research shows teams perform better when involved in setting their own outcomes. However, goals need to be achievable and teams need feedback on progress.
For new outcomes, teams should start with a learning goal to understand what drives the metric before committing to a specific performance goal. S.M.A.R.T. goals are best for experienced teams.
Anti-patterns to avoid include pursuing multiple outcomes at once, frequently changing outcomes without learning effects, and setting individual versus team outcomes. Teams should also avoid choosing outputs rather than outcomes.
In summary, negotiate outcomes as a team, start with learning goals for new metrics, focus on one outcome at a time, and make sure the goal represents a measurable change rather than an output.
The team’s goal was to increase the rate at which customers submit applications on their platform. Each member had their own perspective on what was preventing customers from completing applications.
It’s important for teams to map out what they collectively know about the customer experience from their different perspectives. This provides a shared understanding to guide discovery work.
The team started by each member individually mapping out their own perspective on the customer experience and barriers to submitting applications. This allowed them to avoid groupthink and capture diverse views.
They then shared their individual maps to explore each other’s perspectives. Combining views gave a richer picture than any one map alone, filling gaps and raising new insights.
From there, they merged their maps into a shared experience map reflecting what they collectively knew, areas of uncertainty, and questions for customer interviews. This guided structured discovery to identify opportunities.
Properly scoping the experience map is important - neither too broad nor narrow. The team’s goal/outcome helps define appropriate scope for the context.

The key aspects are individually mapping perspectives first, then combining views into a shared understanding to guide discovery of opportunities through a structured process using customer feedback. The experience map evolves as knowledge grows.

The passage recommends that each member of a product trio (team of 3) first develops their own individual perspective on the customer experience by creating an experience map on their own. This is counterintuitive as people usually divide work up.
Drawing maps visually, rather than verbally describing them, helps uncover gaps and gets people to think more concretely about customer touchpoints. Even rough drawings are fine.
Team members then share their individual maps to understand different perspectives. They ask questions but don’t critique, just try to understand each view.
Together they synthesize all the individual maps into a shared team map by grouping similar touchpoints, adding connections between them, and including context around each step.
Some pitfalls to avoid are getting bogged down in debate, relying too much on words instead of visuals, treating the map as definitive truth rather than a draft, and failing to update it as understanding improves. The goal is maintaining a shared understanding of customers as insights evolve.
Customers don’t always know what they want, and asking them direct questions about needs and preferences can lead to inaccurate answers due to cognitive biases.
Steve Jobs believed in showing customers things they didn’t know they needed yet. The original iPhone introduced visual voicemail, which solved a pain point people didn’t realize they had.
Regular customer interviewing is important not to ask what to build, but to discover opportunities by understanding customer stories and pain points. This allows companies to intervene positively in customers’ lives.
Interviewing one’s own behavior reveals inconsistencies between how we think we act and actual behavior. Our brains rationalize decisions even when the true reasons are unknown.
Continuous interviewing can uncover unmet needs that customers themselves may not be aware of. While customers shouldn’t dictate what is built, understanding them better through stories reveals opportunities for innovation.
Michael Gazzaniga’s studies on brain anatomy showed that people instinctively construct a coherent narrative to explain their decisions and behaviors, even if the real reasons were unconscious or unknown. People feel confident in the stories they tell, but are not always accurate.
When interviewing customers, asking direct questions about behaviors and criteria often leads to idealized responses rather than accurate descriptions of real behaviors. People describe what they aspire to do rather than what they actually do.
The author learned this through building a product targeting “passive candidates” according to what recruiters said they wanted, but recruiters actually continued using “active candidates” in practice due to performance metrics.
Successful products require understanding customers’ actual behaviors and realities, not just the stories they tell. Stories from specific past experiences are more reliable than generalizations.
Interview questions should focus on eliciting stories through open questions about past experiences rather than direct questions about general behaviors. The scope and context of story questions can be adjusted based on research needs.
As the interviewer, you must excavate the full story through follow up questions about timeline, characters, challenges, locations, and guiding the participant back to the specific experience rather than generalizations. This takes practice to uncover reliable insights into customer realities.
Keep interviews grounded in specific stories rather than generalizations to get accurate data on actual behavior. Collecting stories takes practice to get good at steering the conversation while letting participants talk freely.
You won’t always get the exact story you want, so let participants talk about what interests them most. Guide the conversation with open or specific story prompts, then probe parts of the story that relate to your research questions.
Some participants may not provide useful stories, so capture what value you can but don’t force it. Continuous interviewing means unsatisfying interviews are easily replaced.
Synthesize interviews as you go with “interview snapshots” - one-page summaries with a memorable quote, participant facts/context, identified opportunities/insights from their stories, and a visual drawing of their experience map to help remember key details.
Draw out participants’ stories to better understand and compare to your experience map. Taking time to capture stories visually helps the team stay aligned as research evolves.
Commit to weekly interviewing as foundational for an ongoing discovery practice. Needs and opportunities constantly change, so continuous interviewing is required to explore an ever-evolving landscape.
Continuous interviewing is valuable as it allows teams to pivot quickly from exploring one opportunity to another based on customer feedback. It’s better than having to restart the process from scratch.
Maintaining a weekly interviewing habit is important for sustainability. Automating the recruitment process can help ensure interviews are scheduled regularly.
Recruiting participants directly from the product/service, asking customer-facing teams to schedule interviews, and leveraging an advisory board are effective recruitment methods.
Interviewing together as a product trio is valuable as it allows everyone to gain different insights based on their roles. Having just one person be the “voice of the customer” limits perspective.
Common anti-patterns to avoid include relying on one person for recruitment and not documenting or sharing learnings from interviews. Regularly interviewing and incorporating feedback continuously improves products.
When conducting customer discovery interviews, it’s easy to get overwhelmed by all the opportunities and needs that are uncovered. Mapping the opportunity space helps structure and organize these opportunities.
Opportunity mapping involves collecting customer needs, pain points and desires from interviews and sorting them onto opportunity solution trees. These trees group similar opportunities and help patterns emerge.
The opportunity space is always evolving as more is learned from customers. Mapping needs to be done, undone and redone to reflect new insights.
The goal of mapping is to identify the highest impact opportunities to address first - those that will best help achieve the desired outcome. This involves systematically exploring and comparing opportunities.
Jumpong from opportunity to opportunity risks missing impactful ones. Mapping forces a deliberate approach to understanding the problem space before solving.
The chapter will provide guidance on how to inventory opportunities from interviews and structure them through mapping to select where to focus product efforts for maximum effect. Mapping is a core part of customer discovery and opportunity assessment.

Organizing opportunities into a tree structure, with parent-child and sibling relationships, helps make sense of a complex opportunity space. It allows big, intractable problems to be broken down into smaller, more solvable sub-opportunities. This ensures continuous delivery of value over time by addressing smaller opportunities iteratively, rather than waiting to solve the entire big problem at once. Well-structured trees with distinct, non-overlapping opportunities in each branch enable teams to prioritize and work on opportunities one at a time without them becoming enmeshed. Experience maps and customer story drawings can be used to uncover the underlying structure by identifying distinct moments in customers’ experiences to form the branches.

The opportunity mapping process involves collecting stories and insights from customer interviews and mapping them to a set of distinct moments in the customer journey/experience. This allows opportunities to be grouped under the relevant moments.
Distinct moments should not overlap and should allow focusing on one opportunity at a time.
Opportunities collected from interviews are evaluated against criteria like framing as a customer need/pain point, mentioned by multiple customers, potential to drive desired outcomes.
Opportunities are grouped under the relevant branches/moments. Similar opportunities are clustered together and parent opportunities are identified to provide structure.
Structure is added iteratively, focusing on capturing the main points without excessive detail. The tree will continue to evolve.
Common anti-patterns to avoid include opportunities framed from the company perspective rather than customers’, vertical hierarchies with single branches, opportunities applicable to multiple moments, non-specific or solution-focused opportunities, and capturing feelings rather than underlying opportunities.

The overall goal is to take a set of customer stories/insights and map them to a structured opportunity solution tree framed around distinct customer journey moments, with the opportunities focused on clear customer needs and pain points.

The passage discusses prioritizing opportunities over solutions when engaging with customers. It notes that when customers express feelings, like frustrations with password requirements or falling behind on a show, these should be seen as “signposts” directing companies to the underlying opportunities or problems, rather than the solutions themselves.

Proper opportunity mapping allows product teams to make strategic decisions about which customer needs, pain points or desires to address (opportunities) rather than immediately jumping to proposed solutions like new features. Prioritizing opportunities involves assessing them based on factors like impact on customers, position in the competitive market, and alignment with company strategy. Focusing work on a single priority opportunity at a time allows iterative delivery of value.

Opportunity assessment and prioritization should consider factors at three levels - company, business group/team, and individual team. Vision, mission and strategic objectives at each level can constrain what opportunities are chosen.
Strengths and weaknesses at each level (company, business group, team) should also be considered. Some may be better positioned for certain opportunities.
Customer factors help evaluate importance and satisfaction with current solutions. Prioritize opportunities that are important to customers and have low satisfaction with existing solutions.
It’s a subjective decision, so don’t try to score and rank opportunities quantitatively. Have an open debate considering different dimensions/factors as lenses.
Embrace the messiness - there may not be a clear winner. The goal is the best decision for now, not the perfect decision.
Treat it as a two-way door decision that can be reversed if needed. Explore the selected opportunity without committing to solve it.
Avoid analysis paralysis by time-boxing the decision. Also avoid over-relying on one factor or working backwards from a pre-determined conclusion.
Leigh Thompson says that quality is best predicted by y - suggesting past performance is the best indicator of future quality or success.
Ed Catmull cautions against sticking only to the familiar and says you’ll never stumble upon unexpected insights if you don’t explore beyond your comfort zone.
The article discusses the pros and cons of traditional brainstorming. While it can feel productive, research shows individuals generally outperform brainstorming groups in coming up with more diverse and novel ideas.
Some reasons brainstorming groups underperform include social loafing, groupthink, production blocking, and downward norm setting.
However, individuals can still benefit from exposure to others’ ideas. Alternating individual ideation with sharing ideas in a group can spark new individual insights.
When getting stuck individually generating ideas, it’s normal and the key is pushing through instead of giving up due to self-limiting beliefs about creativity. Exposure to new perspectives through others can help get unstuck.
Generating creative ideas is a universal human trait and product team members should strive to come up with solutions to customer problems.
It may be slow at first, but push through discomfort by spreading ideation throughout the day in short bursts, such as during meetings or walks. Different times and locations can spark new ideas.
Take advantage of incubation, where the brain continues working on a problem even after conscious thought. Breaks and sleep can lead to insightful solutions.
Look to competitors and analogous products in other industries for inspiration, as unrelated domains often spur innovative ideas.
Consider extreme users’ needs to generate more diverse ideas that could benefit all users.
Don’t be afraid of wild ideas, as they can improve more feasible concepts when combined creatively.
Evaluate ideas as a group through dot voting to select the top three ideas for further development, refining the selection through discussion and additional rounds of voting.
Avoid anti-patterns like not including diverse perspectives, focusing only on variations of the same idea, and limiting ideation to a single session. Spreading it across time is more effective.
Product teams often make assumptions when developing ideas that later turn out to be incorrect, leading them to build the wrong solution. This happened with a Portland affordable housing project.
Cognitive biases like confirmation bias and escalation of commitment cause teams to overcommit to their initial assumptions without properly testing them.
It’s important to adopt a “prepare to be wrong” mindset in order to avoid these biases. Teams should explicitly test their assumptions through fast iterations rather than testing whole ideas.
There are different types of assumptions to consider - desirability, viability, feasibility, usability, and ethical assumptions.
In order to test assumptions, teams need to make their ideas more specific by creating a “story map” that lays out the user journey and experiences in detail. This clarifies the underlying assumptions.
Testing assumptions through fast iterations is more feasible than building whole solutions. It allows teams to identify incorrect assumptions early before investing too much time and resources. This helps avoid building the wrong solution.
Story mapping forces teams to get specific about how an idea will work and what end-users will do to get value from it. This helps surface underlying assumptions.
To story map, outline the steps end-users take, starting with the assumption the solution exists. Identify key actors and map out sequential steps horizontally over time.
You can generate assumptions from each step - desirability assumptions about what users want, usability assumptions about what they can do, and feasibility assumptions about what can be built.
Story mapping an example idea uncovered over 20 assumptions across 5 steps. Generating many assumptions increases the chance of finding risky ones.
Conducting a pre-mortem, where you imagine the idea failed in 6 months, is another way to generate assumptions. Phrasing it as certain failure helps expose assumptions the idea depends on.
Both techniques help align teams on what an idea means and get assumptions out in the open to prioritize which need testing.
Psychologists Deborah Mitchell, Edward Russo, and Nancy Pennington from three universities (Penn, Cornell, Colorado) conducted a study on prospective hindsight.
Prospective hindsight is the technique of generating explanations for potential outcomes before the actual outcome is known.
The researchers found this technique was effective at generating better explanations only when used in conjunction with stating a certain outcome. Simply using prospective hindsight on its own did not improve explanations. The outcome had to be specified for the benefits to be realized.
In other words, for prospective hindsight to work well at explaining outcomes, it needs to be “paired with a certain outcome.” Just using the technique by itself without specifying an outcome was not as effective.

Here is a summary of the common anti-patterns to avoid when generating assumptions:

Not generating enough assumptions. The goal is to identify as many potential risks or “gotchas” as possible through divergent thinking. Teams often underestimate how many assumptions underlie their ideas and should aim to generate 20-30 assumptions even for simple ideas.
Phrasing assumptions such that you need them to be false. Assumptions should be phrased positively such that you need them to be true for the idea to work, rather than negatively stating why it might fail.
Not being specific enough. Assumptions like “customers will have time” are too vague - they need to specify clearly what customers will have time for.
Favoring one category (desirability, feasibility, etc.) at the cost of others. Teams often overlook categories like ethics. The categories help uncover blind spots.

The key things to avoid are not generating a sufficient number and variety of assumptions, being too vague, and phrasing assumptions in a way that sets them up for failure rather than success. The goal is to identify as many potential risks or weaknesses as possible to determine which assumptions require testing.

When simulating or testing assumptions, it’s important to clearly define evaluation criteria upfront, like “at least 3 out of 10 people choose sports”. This helps align the team on what success looks like and guards against confirmation bias.
The criteria should balance speed of testing with getting actionable results. Test with the smallest number of people that still provides useful information for the team to act on.
Early tests should be small and quick to fail fast if the assumption is wrong. Only invest more time and resources in larger experiments if early signals show the assumption merits further exploration.
Small sample sizes can result in false positives or false negatives. This is mitigated by selecting a varied sample. False negatives are also not a major issue since assumptions are tested across multiple ideas and additional experiments can be run.
When assumptions fail, the ideas should be redesigned around the new information rather than abandoning opportunities prematurely based on one failed test.

The key is starting small, learning quickly through failures, and only progressing to larger tests when early signals warrant further investigation of the assumption or opportunity.

Testing assumptions through small, iterative tests is preferable to making decisions based on a single large test. Small tests have a low cost even if they find a false negative or positive.
False negatives from small tests usually just require redesigning and retesting, while false positives typically get caught in follow-up testing. The main cost is time.
Tools like unmoderated user testing and one question surveys allow quick, low-effort assumption testing by eliminating need for scheduling and participating live.
Tests should focus on measurable behaviors rather than hypothetical future actions. Questions could ask about past behaviors, preferences, or simulate an experience to get measurable responses.
Additional data sources like platform usage can also provide indication to test assumptions without additional testing. Metrics must be defined upfront.
The goal is not scientific proof but mitigating risk to determine the best path forward quickly through iterative learning, as product teams operate on faster cycles than scientific research. Sound methods are balanced with a need for timely progress.

In summary, the passage advocates a approach of testing assumptions iteratively through low-cost methods to efficiently guide product development, rather than trying to scientifically prove or disprove assumptions in a single large test. This allows continuously learning from real user responses and data.

The company AfterCollege helps college graduates find jobs. The founder realized through interviews that asking students what type of job/location they want didn’t work, as most students didn’t know the answer.
They had data on what jobs students typically apply to and what employers want. So they developed a prototype that recommends jobs based on a student’s major, by creating “saved searches”.
Testing the prototype showed it dramatically increased the number of students starting a search (83% vs 36% previously). It also led to slightly more job views and applications.
While promising, they didn’t know if it would ultimately increase their key goal - the number of students getting jobs. So they debated whether to fully launch the prototype or test it more first to answer that question. The founder took a data-driven approach and wanted more evidence before a full product change.

In summary, the company tested a new job recommendation approach focused on major rather than pre-determined job/location preferences. Early tests showed an increase in searches but more validation was needed on their ultimate goal of job placements.

The story illustrates the importance of focusing on the desired outcome, not just assumption tests or metrics. Early prototypes showed promise but didn’t confirm impact on the goal of helping students find jobs.
Discovery and delivery are iterative and intertwined, not distinct phases. Testing prototypes with real users provided valuable data but also required collecting additional information to evaluate impact on the outcome.
It’s unrealistic and overwhelming to try measuring everything from the start. Instrumentation should focus first on what’s needed to evaluate assumptions and criteria. Over time, the goal is also to measure progress on the desired outcome directly.
Counting users (people) versus actions provided different insights. People metrics showed how many were successful, while action metrics revealed effort required.
The company evolved its approach to better track the ultimate goal of students getting jobs, like following up after applications to understand outcomes, rather than just measuring intermediate steps. Iteration and a focus on the desired result drove continuous improvement.

Here are the key points from the summary:

Simply Business, a UK insurance company, kept hearing from customers that late client payments were a major pain point and problem for small businesses.
They identified this as a target opportunity to address based on customer interviews and market research.
They generated and tested three potential solutions: articles on preventing late payments, discounts for early payments, and automated payment collection.
Tests of the solutions showed that while late payments were reported as a problem, the potential solutions did not seem to meaningfully help customers or directly address their needs.
This required the team to loop back and re-evaluate whether late payments was actually an opportunity worth pursuing solutions for. The reported pain point did not match what customers expressed would help through solution testing.
They had to challenge their initial assumptions and go back through the discovery process to understand the opportunity and customers’ needs more fully before further developing solutions. Simply identifying a pain point is not enough - the solutions also need to directly help customers.

The key lesson is that just because a pain point is commonly reported does not necessarily mean it represents a true opportunity worth pursuing. Teams need to fully understand customer needs and validate potential solutions through testing before committing significant resources to developing a solution. Being willing to loop back and challenge initial assumptions is important for continuous discovery.

Mina’s team conducted assumption tests on their proposed solution to help customers with late payments. The first test showed little customer engagement.
Videos from further tests revealed that most customers did not understand the solutions being proposed and were not interested in third-party help with payments, preferring to handle it themselves to maintain relationships.
This surprised the team, as late payments had come up frequently in prior research as a pain point. The assumption tests made it clear customers did not want Simply Business’s proposed solution.
Thankfully, the team had a practice of continuous customer interviews, so they did not have to start from scratch in identifying a new opportunity. They were able to quickly pivot to a new focus area.
This illustrates the importance of not getting bogged down in analysis and being able to course-correct when assumption tests reveal a proposed solution is not a good fit for customers. The team invested only a short time on the incorrect opportunity.

So in summary, assumption tests revealed the team’s proposed late payment solution did not match customer needs or interests, prompting them to quickly identify a new focus based on existing customer research. This highlights agile testing and pivoting when learnings necessitate a change in direction.

Carl’s team at a bank wanted to identify opportunities they could address digitally to help farmers and ranchers. They saw that customers often tried to figure out how much property they could afford to buy.
They created an online calculator for customers to input information and see what they could afford. However, they were concerned customers would want human interaction.
Through experiments with adding a live chat feature, they found customers did not want to chat and would close the browser instead.
This showed the human touch was not needed at the calculation stage. The opportunity of determining affordability was something they could solve digitally.
They built out the online calculator, which became their successful FarmLend loan application program. It allows customers to apply for financing online instead of just through branches.
Customers still interact with their financial officer for trusted advice, but do more of the application process digitally through the FarmLend website. By addressing a specific need digitally first, the team was able to teach customers to engage online while still providing human support.
Lisa Orr’s team at Airship was asked to build a customer journey builder tool to help win deals, as competitors offered this.
Through discovery with customers, they found existing journey builders were too complex. Building what competitors offered wouldn’t be good enough.
They saw an opportunity to create a better solution and prototyped alternatives. However, sales pushed back wanting what prospects requested.
Thankfully, Lisa convinced leadership to let them beta test their new feature with customers. The beta was successful, validating their discovery approach.
The key learning is that doing good discovery isn’t enough - stakeholders must be brought along the discovery journey through visual artifacts like opportunity trees. This helps set context for decision making rather than inviting opinions. Showing the work prevents the “HiPPO problem” where senior opinions override discovery findings.

Here are a few key points about starting to adopt continuous discovery habits in your organization:

Start small - Pick one small project or initiative to try applying discovery techniques like assumption mapping, stakeholder interviews, prototype testing, etc. Don’t try to change everything at once.
Lead by example - Personally model the behaviors you want to see by doing discovery work for your own projects and sharing the process and findings openly.
Build a coalition - Look for early adopters among your peers, managers, or stakeholders who are open to trying new approaches. Work with them to socialize discovery habits more broadly.
Focus on outcomes, not process - When talking to skeptics, emphasize how discovery helps achieve goals like better products/solutions rather than focusing on the methods themselves.
Adapt frameworks to your context - Don’t feel constrained by “textbook” discovery techniques. Modify frameworks based on what works best for your industry, constraints, culture, etc.
Iterate constantly - As you gain experience, continue refining your discovery habits and sharing lessons learned. Prove the value through impactful outcomes.
Secure early wins - Use initial success stories to gain broader buy-in for dedicated discovery efforts. Wins will attract more advocates for further change.

The key is to start small, prove the value, refine as you go, and build momentum over time through demonstration rather than mandates. Continuous improvement mindset applies to both products and processes.

The member recalls their first design assignment for their client AAAS, which had a long list of feature requests for a new online community. They spent 3 days designing site navigation to encompass all the features.
At the client meeting, one client said their design was “horrible” and didn’t meet what was asked for weeks prior. This was a shock and they realized they knew little about the client/end users.
However, their human-centered design education taught them to bounce back. They invited the unhappy client to partner on the next iteration. They began deeply involving themselves in the client’s needs from the start of projects.
Even without company support, they found ways to get close to customers through various means like attending client meetings, conferences, reading forums, and building feedback loops.
Their guiding principle was that if they wanted to do good design work, they needed to keep clients and end users close. This principle stayed with them throughout their career.
The key message is that even without companybuy-in, individuals can impact their own work through focus, initiative and perseverance in adopting user-centered best practices.
Work with stakeholders to identify the expected impact of new features and document those conversations. Measure the actual impact after release and compare to expectations.
If a feature falls short of expectations, use that as an opportunity to discuss alternative solutions that could better meet customer needs. Brainstorm with stakeholders to build out a “solution tree” of potential options.
Advocate for more discovery and upfront testing of assumptions when features underperform. Suggest ways the gaps could have been identified earlier through things like assumption testing.
Conduct regular retrospectives to reflect on discoveries made during sprints. Look for surprises and ways assumptions could have been tested sooner.
Be careful not to take an “I told you so” attitude when suggesting improvements. Approach it collaboratively and focus on continuous improvement.
Avoid common anti-patterns like claiming an idea “will never work” without considering adaptations, or insisting on a single “right way” of working rather than adapting methods. Start with small changes within your control.

The overall message is to continually work with stakeholders, measure results, identify gaps, advocate for more discovery, and focus on collaborative improvement rather than blame when refining processes.

The author thanks several people who contributed to the development and feedback on the ideas in the book, including Hope Gurion who provided client, partner, and friend perspectives, and Jeff Merrell for thought partnership.
Marty Cagan is thanked for his foreword, enthusiasm for the author’s work, referrals, and feedback. Martin Eriksson is thanked for support through speaking opportunities and feedback.
Petra Wille helped navigate the self-publishing process and supported the author. Melissa Suzuno provided editing support and encouraged the author to write the book as desired.
58 early readers provided feedback on chapters which helped understand what was working and needed improvement.
Rick Gaudette, the author’s partner, is thanked for learning about the topic and supporting the writing process.

So in summary, the author thanks multiple people who contributed ideas, feedback, editing support, and encouragement during the writing and development of the book.

Here is a summary of the key points from the chapter “The Attitude of Wisdom: Ambivalence as the Optimal Compromise” in the book Organizational Wisdom and Executive Courage:

The chapter argues that an attitude of ambivalence and acceptance of complexity/ambiguity is a mark of wisdom. Clear-cut decisions often ignore important nuances.
Wisdom involves holding seemingly contradictory ideas in creative tension without needing to resolve them. Ambivalence allows for deeper understanding of multifaceted issues.
Executives with wisdom recognize the limitations of human knowledge and ability to predict the future. They are comfortable with uncertainty and ambivalence rather than seeking definitive answers.
An ambivalent mindset acknowledges trade-offs and competing perspectives. It avoids simplistic solutions and polarized thinking. Wise leaders make decisions but also realize other paths could have merit.
Organizations benefit from leaders who can live with unresolved tensions and complex realities. Ambivalence fosters adaptability, flexibility and considers unintended consequences of actions.
In summary, the chapter promotes an attitude of ambivalence, complexity acceptance and tension holding as a hallmark of wisdom that serves organizations and leaders well when facing complicated issues.

#book-summary

Continuous Discovery Habits Discover Products that Create Customer Value and Business Value - Teresa Torres