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

by Teresa Torres

Product teams are particularly susceptible to confirmation bias and the escalation of commitment. We tend to fall in love with our ideas. We often have to defend our ideas to stakeholders, further entrenching our commitment to our ideas. We tend to seek out why our ideas will work and forget to explore why they might not work. As a result, we are often overconfident about the success of our ideas.

Chip and Dan Heath, authors of Decisive (introduced in Chapter 2), advise that, if we want to avoid overconfidence and make better decisions, we need to be prepared to be wrong.

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 taking the time to generate many assumptions, we’ll increase the likelihood that we’ll uncover the risky ones.

Pre-mortems, on the other hand, happen at the start of the project and are designed to suss out what could go wrong in the future.

Rather than starting with a large-scale experiment (e.g., surveying hundreds of customers, launching a production-quality A/B test, worrying about representative samples), we want to start small. You’ll be pleasantly surprised by how much you can learn from getting feedback from a handful of customers.

There are two tools that should be in every product team’s toolbox—unmoderated user testing and one-question surveys. Unmoderated user-testing services allow you to post a stimulus (e.g., a prototype) and define tasks to complete and questions to answer. Participants then complete the tasks and answer the questions on their own time. You get a video of their work. These types of tools are game changers. Instead of having to recruit 10 participants and run the sessions yourself, you can post your task, go home for the night, and come back the next day to a set of videos ready for you to watch.

course-corrections should be celebrated. The fruit of discovery work is often the time we save when we decide not to build something.

One of the hardest challenges with opportunity selection is identifying the right opportunity for right now. However, a round of assumption tests should help you assess fit quickly. These stories are a good reminder of why we want to run quick tests rather than overinvest in the best tests.

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 about what to build.

When meeting with stakeholders, start at the top of your tree. Remind your stakeholders what your desired outcome is. Ask them if anything has changed since you last agreed to this outcome. This sets the scope for the conversation.

Your stakeholder needs to fully understand the opportunity you are pursuing before you share solutions with them. This is what sets the context for how to evaluate solutions and moves the conversation away from opinions and preferences.

When we show our work, we are inviting our stakeholders to co-create with us. Instead of sharing our conclusions and inviting them to share their preferences, we are sharing our work and inviting them to assess our thinking and to add their own. We are leveraging their expertise and improving our process.

When we take the time to show our work, using visual artifacts like experience maps, opportunity solution trees, and story maps, we are inviting our stakeholders along for the journey with us. Instead of presenting our conclusion—this is the roadmap, release plan, and backlog that will help us reach our desired outcome—we are presenting the potential paths we might take to get there. We are inviting our stakeholders to help us choose the right path. Instead of presenting a conclusion, we are generating and evaluating options. This allows our stakeholders to be a part of the process. We are inviting them to co-create with us, which leads to much more buy-in and long-term success.

I encourage my teams to ask, “What did we learn during this sprint that surprised us?” This could be anything from a feature release didn’t have the expected impact, we learned a new insight in a customer interview, or we ran into a feasibility hurdle that required us to redesign a solution. Make a list. Then, for each item on the list, ask, “How could we have learned that sooner?” The answers to these questions will help you improve your discovery process.