Outside the Box
Working against cognitive bias
As a product manager, one of the most difficult challenges I’ve had to deal with is understanding and preventing cognitive bias, both within myself and while presenting to or processing information from my team mates.
Great Product Managers are often generalists: their job scope requires them to have a broad but largely unspecialised understanding of most disciplines, from design and art to tech and business. PMs often have to process and distribute conflicting information from several departments at once, all while making key decisions which affect the future of a product or the business at large. In situations like these, being able to think clearly and prevent assumptions can be the difference between shipping and 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. Close your eyes and try to picture a scene of a lake in October. Now imagine two swans resting on the lake. Lastly, try to imagine how the lake would change visually as it cycles through the seasons, heading 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?
Cognitive bias can be defined as a systemic error in the way we perceive and use information. We are often unaware of how many simple and small factors can influence the way we parse and process information. Some of these factors include emotional predisposition, memory, cultural background, and social pressures. Many development teams are diverse in these areas and thus can have difficulty agreeing or aligning on something that seems easy on paper.
There are a few ways to reduce such biases from influencing development and hampering communication.
Two Wrongs Might Sometimes Make a Right
Confirmation bias is likely the most common mental trap encountered by development teams. Many of us share a tendency to search for or interpret information in a way that shores up one’s own pre-existing arguments or assumptions. While constructing feedback or explaining design specifications, it is easy to take shortcuts while explaining or assume that someone has fully understood the work that is required. It is easy to only consider the “Yeses” and disregard the “No’s”.
While agreeing on or delegating a task, it is critical to make a point of digging out 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 cues, and help to extract information on a given issue that allows us get to the core truths quicker.
The Read Back
It can be easy to pin the blame on a teammate for simply not interpreting a basic task, but sometimes even the most straightforward processes have elements that can be completely misinterpreted.
An easy (but sometimes awkward) way to prevent miscommunication when delegating tasks is to request your report to read back a task or explain back to you how they’ll be approaching the assignment in question. This allows you to make sure that all team members have correctly identified the problems and are tackling their solutions accordingly.
An additional benefit of doing this regularly is that it ensures team members are prepared to work out for themselves 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 reinforces a sense of personal 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 altogether unaware they are making decisions just to keep everyone happy. Most teams try avoid conflict and maintain peace and a status quo, but can often be an obstacle to interpreting and applying feedback correctly. The end result often ends up being decisions that are self-reinforcing but poorly researched or weakly justified. Ideas that are not necessarily the best rise to the top and products are developed in a bubble.
To prevent such scenarios, Product Managers need to ask the right questions, and often. On top of the questions designed to consider the “No’s” associated with a given task, I have found the following useful to 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 as a whole — be willing to change them?
Constantly challenging your own assumptions and forcing yourself to readjust your perspective can help build a more constructive view of problems and a practical basis for 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 unconscious biases, so it’s important to ask the right questions to build more critical thinking and make sure your decisions are rooted in (largely) unfiltered facts.
- The more people in a team, the harder it is to align and ensure all parties are headed in the same direction. Instead of hogging the driver’s 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 chances 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 yours and your teammates’ decisions, you prevent complacency of thought and set yourself up to produce work that takes the necessary risks and tests the limits of what’s possible.
