While the human mind has an amazing capacity for creative thought and sheer computational power, it has some annoying misfires that can get in the way of building really great products. These misfires, sometimes referred to as cognitive biases, were first identified by Daniel Kanheman and Amos Tversky in the 1970’s. In their work, Kanheman and Tversky identified cognitive biases as common psychological tendencies that cause people to draw incorrect conclusions. While their work was about economics, their insights into human behavior have spread well beyond their original discussions.
To help you recognize cognitive biases in your own work, here are some common cognitive biases found in product management based on our experience working with clients. This list is not meant to be definitive (here is a diagram showing over 140 cognitive bias!!), but to illustrate biases you are likely to have within yourself or encounter within other people (managers, customers and developers) as you develop products.
- Anchoring: the tendency to rely too heavily, or “anchor”, on one trait or piece of information when making decisions, usually the first piece of information acquired on that subject. For instance, a Scrum Team might experience anchoring when evaluating the quality of their current user experience based upon earlier, more primitive versions of the product.
- Bandwagon effect: the tendency to do (or believe) things because many other people do (or believe) the same. An example of the bandwagon effect is when product designers rush to implement a specific technology in their product after a competitor was reported successfully using that same technology at annual trade show.
- Bizarreness effect: bizarre material is better remembered than common material. For example, a Product Owner with this bias might prioritize unusual user stories in the Product Backlog based on the unorthodox use of the product by a specific customer type instead of prioritizing user stories that represent more common behaviors by a wider range of customers and end users.
- Confirmation bias: aka “experience bias”, this is a tendency to search for, interpret, focus on and remember information in a way that confirms one’s preconceptions. For instance, a Scrum Team with this bias might select a third-party tool based on their past (positive) experiences with the vendor rather than it being the best tool for the customers’s needs.
- Curse of knowledge: when better-informed people find it extremely difficult to think about problems from the perspective of lesser-informed people. Organizations and product managers with this bias might make statements like, “We know what our customers want.” or “We know our markets better than our users.”
- Experimenter’s bias: the tendency for experimenters to believe, certify and publish data that agree with their expectations for the outcome of an experiment, and to disbelieve, discard or downgrade the corresponding weightings for data that appear to conflict with those expectations. Product Owners and product managers with this bias may stop an experiment as soon as it produces data that proves their hypothesis rather letting the experiment run to completion.
- Fundamental attribution error: a tendency to reach conclusions about the cause of somebody’s behavior being due to internal factors, such as personality, and to discount external factors that may actually play the greater role. For instance, when a Scrum Team complains, “The Product Owner cannot write good user stories.” they are blaming the Product Owner for a situation that is very likely caused by one (or more) organizational impediments.
- Hyperbolic discounting: aka “current moment bias”, discounting is the tendency for people to have a stronger preference for more immediate payoffs relative to later payoffs. Product Owners with this bias often times prioritize building new features in the product over reducing the product’s technical debt.
- Information bias: the tendency to seek information even when it cannot affect action. When product managers express the desire to run “just one more test” or “do just one more demo” instead of launching the product, this bias could be at work.
- Irrational escalation: aka “sunk cost fallacy”, the phenomenon where people justify increased investment in a decision, based on the cumulative prior investment, despite new evidence suggesting that the decision was probably wrong. This bias might be present when product managers continue to add features and capabilities to products that are at end-of-life (contain out-dated technology, poor market performance, etc.) instead of retiring them.
- Negativity bias: psychological phenomenon by which humans have a greater recall of unpleasant memories as compared with positive memories. Product Owners and product managers might be experiencing this bias when they tell the Scrum Team the product is “doomed” after receiving one round of unpleasant feedback during a customer visit.
- Not invented here: aversion to contact with, or use of, products, research, standards or knowledge developed outside the group. This bias may be present when Product Owners and product managers question the value and need of additional product management techniques and tools that were not created by their own organization.
- Status quo bias: the tendency to like things to stay relatively the same. Product managers with this bias will focus on extracting maximum value from their current product offerings instead of working to identify new market opportunities and\or additional ways to provide customers value with the adage, “If it ain’t broke, don’t fix it.”
- Survivorship bias: concentrating on the people (or things) that “survived” some process and inadvertently overlooking those that did not because of their lack of visibility. For Product Owners with this bias, this might mean an over reliance on the needs and priorities of current customers rather than considering the needs of the total addressable market.