Outside the Box
Working against cognitive bias
As a product manager, one of the most difficult challenges I’ve had to deal with is how to understand and prevent cognitive bias, within myself and while presenting or processing information from my team mates.
Great Product Managers are often generalists, and need to have a broad but somewhat shallow understanding of most disciplines like design, art, tech and business. PMs often have to process and distribute conflicting information, while making key decisions which affect the future of a product and the business. Being able to think clearly and prevent assumptions can be the difference between shipping or sinking.
To illustrate the impact of cognitive bias and how that influences day to day decision making, I’d like to present a hypothetical scene. Visualise and try to picture a scene of a lake in October. Now imagine 2 swans resting on the lake. Lastly, try to imagine how the lake would change visually as it changes seasons and heads past December, and into the next year.
Did it look somewhat like the picture above? Would you have considered that the swans were not of the same colour, or that the lake was not in the northern hemisphere but instead in Australia, where the seasons would be opposite to the rest of the world?
A cognitive bias can be defined as a systemic error in the way we perceive and use information. We are often not aware of how many simple and small factors can influence the way we perceive information. Some of these factors include emotions, memory, culture and background, and social pressures. Many development teams are diverse and thus can have difficulty agreeing on or aligning on something that seems easy on paper.
There are a few ways to reduce such biases from influencing development and distorting communication.
Two wrongs might sometimes make it right
Confirmation bias is likely the most common mental trap that most teams fall prey to. It is common for people to have the tendency to search for, or interpret information in a way that confirm or supports an argument. While constructing feedback or explaining design specifications, it is easy to take shortcuts while explaining or assume that someone has understood the work that is required completely. It is easy to only consider the “Yes”, and disregard the “No’s”.
While agreeing on or delegating a task, it is critical to ask the “No’s”.
- What shouldn’t you be working on?
- Which part of this task should you not tackle first?
- What is the wrong colour to use for this element?
- Where is the wrong placement for this object?
These questions are much more valuable than simple confirmation questions, and help to provide more information that allow us get to the core truths of the matter quicker.
The Read Back
It can be easy to pin the blame on a teammate or colleague for simply not intepreting a basic or simple task, but sometimes even the most basic of features have elements that can be completely misinterpreted.
An easy (but sometimes awkward) way to prevent miscommunication when delegating tasks is to request for the person to read back a task or explain how they would tackle a feature back to you. This allows you to make sure that all team members interpret the problem and are tackling the solution in the same way.
An additional benefit of doing this regularly is that it ensures that team members are prepared to break down and truly understand how a task or feature should be tackled, rather than relying on a designer or feature owner to explain how a task should be done. This improves the sense of ownership around the task at hand.
Prevent Mob Mentality
Groupthink is real and can be a dangerous bias if left unchecked, or if teams are unaware that they are making decisions just to keep everyone happy. Most teams try avoid conflict and maintain peace and status quo, but that is often an obstacle that prevents the team from interpreting and applying feedback correctly. The end result often ends up being decisions that are poorly researched and self-reinforcing. Ideas that are not necessarily the best rise to the top and products are developed in a bubble.
To prevent such a scenario from happening, Product Managers need to ask the right questions, and often. Similar to the first point of considering the “No’s”, I found that is is also useful to often ask:
- What assumptions am I making at this point in time?
- What is on the opposite side of those assumptions?
- How might I or my team be willing to change them?
Constantly challenging your own assumptions and forcing yourself to change your own perspective on things can help build a more constructive view on problems and can help deliver stronger solutions.
Key Takeaways
- It’s often easier to accept the first solution than to consider all options. Information can be distorted and easily manipulated by biases, so its important to ask the right questions to build more critical thinking in teams and to root decisions in facts.
- The more people in a team, the harder it is to align and ensure all parties are driving in the same direction. Instead of being in the drivers seat and explaining how a task should be tackled, get team members to read back and tell you how they will be tackling a feature or task. Doing so lowers the chance of misunderstanding and helps to uncover potential problems that might have otherwise been missed.
- Don’t buy your own BS. Challenge your own answers and assumptions to give yourself the best chance of success. By constantly challenging you and your team mates decisions, you prevent mob mentality and stop self-reinforcing viewpoints.
Outside the Box was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
