Be Prepared to Be Wrong
Daniel Kahneman, in Thinking, Fast and Slow, introduced us to the idea of cognitive biases—mental shortcuts that, while often helpful, sometimes get us into trouble. In the Portland affordable-housing story (and in many others like it), we are seeing an interplay of two cognitive biases—confirmation bias and the escalation of commitment. Confirmation bias45 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. Both the city and the developer were excited by the positive feedback they got on their project but overlooked the negative feedback. The escalation of commitment46 is a bias in which the more we invest in an idea, the more committed we become to that idea. The more the city explored this idea (and this idea alone), the more committed to the idea they became—despite its flaws.
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. You’ve already learned some techniques to help you adopt a “prepare to be wrong” mindset. In Chapter 7, you learned to compare and contrast opportunities, so that you aren’t overcommitting to one. In Chapter 8, you whittled your ideas down to three, again so that you don’t overcommit to one. In this and the next chapter, we’ll explore how working with a set of ideas (that all have the potential to solve the same target opportunity) will help us compare and contrast the ideas against each other, helping us to avoid confirmation bias and the escalation of commitment.
However, the way most teams test ideas isn’t feasible when working with a set of ideas. We can’t build three ideas for the same target opportunity and A/B test them to see which is the most effective. It would take too long. More often than not, designing and building a testable prototype of each idea will take more time than we have. Instead, we need to learn how to quickly test our ideas through fast iterations.
In the opening quote of this chapter, Marty Cagan, author of INSPIRED, highlights that 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 generally quicker than idea testing, and the faster pace helps us to guard against the escalation of commitment. The less time we invest in an idea, the less likely we are to fall in love with it.
The biggest barrier to testing assumptions is becoming aware of the assumptions we are making. This chapter will enumerate several strategies for helping you to identify the hidden assumptions behind your solution ideas.