Cognitive biases in product management
Cognitive biases can kill features. Cognitive biases don’t just plague internet forums like Reddit or Hacker News, but they also impact the daily product management. And it’s not just others – yourself, the product manager, will be a victim of these biases.
I’m deliberately merging two concepts– cognitive biases and cognitive distortions. The distinction is not helpful applied to Product Management.
Dealing with cognitive biases is very difficult; pointing out the cognitive bias in a conversation will not make it go away in the mind of the people. Worse, pointing it out can have the reverse effect and entrench people in their opinions even further! Like defusing a bomb, you must go through a sequence in the form of processes, questioning and more to dispel them.
There is no exhaustive list of cognitive biases (or distortions). I’ll list the ones I’ve encountered and will expand the list over time.
What’s a cognitive bias? What’s special about Product Management?
From Wikipedia, under Cognitive Bias
“An individual's construction of reality, not the objective input, may dictate their behavior in the world. Thus, cognitive biases may sometimes lead to perceptual distortion, inaccurate judgment, illogical interpretation, or what is broadly called irrationality.
Although it may seem like such misperceptions would be aberrations, biases can help humans find commonalities and shortcuts to assist in the navigation of common situations in life.”
In a previous article, I wrote about lazy leadership, cognitive biases are lazy thinking. They are mental shortcuts to understand the world that end up warping objective reality. On the flip they side, cognitive biases save us from having to work from first principles for every decision.
Product Management, by its very nature, is fertile ground for cognitive biases to grow.
Product Management deals with uncertainty. Uncertainty in how the product or feature is going to look like, uncertainty in the likelihood of success, and more. People will default to cognitive biases to deal with the discomfort of uncertainty.
Product Management involves negotiating with multiple stakeholders, themselves subject to their own biases. “We’ve always done things this way” is something you’ll hear often and a sure sign of a cognitive bias. Dealing with people is dealing with cognitive biases.
Blaming distortion
How to detect it
Confronted with a difficulty – product has an issue, product performance is not as good as expected, people will start looking for a culprit. They will blame another team, customers, a specific person. They will focus their attention on finding something or someone to blame.
How to deal with it
The best product teams run blameless postmortem processes and are trained in its practice. At Truework, we explicitly state that we do not care about finding someone to blame. This blameless process applies to everything, from product launch failures, bugs to customer support issues.
Law of Triviality – Parkinson’s Law
How to detect it
The team will spend most of their time arguing on unimportant details of a product/feature instead of tackling difficult and important questions first.
How to deal with it
As the product manager it’s important that you identify it, make note of it, and don’t succumb to it. It’s critical to keep people on topic and deal with what’s most important first.
Status Quo Bias
How to detect it
If you hear “we’ve always done things this way” or its thousands of other forms, you’re dealing with it.
How to deal with it
Status Quo Bias is everywhere. For Product Managers they are difficult when dealing with stakeholders or people higher in the organization. Mentioning the bias explicitly is not helpful; in fact, it’s likely that the person will become defensive and will double down on their bias.
It’s best to approach the bias in phases. Phase 1, reaching out – listen carefully to the concerns raised and do a best effort to understand their point of view. Phase 2, rationalization – your stakeholder will have given cues to what they are worried about, present how your proposal addresses some of the concerns and how the concerns themselves may not be relevant. Phase 3, presenting alternatives – go beyond phase 2 by not going around the problems but explicitly state the risks of the product. If you’ve built report with the person, they will trust you enough to consider your proposal.
0 Comment