Biases and Jedi mind tricks for Product people

Cognitive biases are well known. We have Daniel Kahneman and Amos Tversky largely to thank for that, after their blockbuster “Thinking Fast, Thinking Slow” shone a penetrating light on this area of research.

I believe there are many deep lessons for product oriented people to learn from cognitive biases, the arena of neuroscience, behavioural economics and research in this space. But for this article I am going to focus on just two biases, the understanding of which I believe is critical to success in product roles.

Confirmation bias

We’ve all done it, we all do it. Seeking out information which confirms your existing beliefs. That’s all this really is. But it manifests in fascinating and complex ways in the world of product. Let’s look at those ways by perspective:

You as the product owner/manager etc:

Your own confirmation bias is a dangerous adversary. You wed yourself too hard to a belief, and bump into resistance. Resistance in the data, resistance in your colleagues, resistance in… the market? Then you arm yourself with an arsenal of facts, data, opinions, anecdotes, which support your pre-existing belief.

For a Product Owner/Manager etc, this is a very precarious thing, because you are surely skilled at making an argument, perhaps better than most around you. The risk is greater for you than for many — you may win through because of argument, not because of proximity to objective truth. A ‘victim of your own skill’ is another way to put it.

Imagine you have determined that the cause of falloff in users in the preceding month is a bug that someone complained about, which is a big/complex bug to fix. You’ve leapt to a conclusion on the basis of one piece of data, we’ve all done it. You then hear from your UX designer they feel the same, it’s owing to the bug. Then someone casually says in a call that number users are dropping across all apps not just yours, but you only half take it in and don’t research further, then you commit the prioritisation of the bug, after all, what’s happening to the rest of the platform is just noise isn’t it? the real focus has to be killing the bug?

So you need to know when to ease off the argument, to listen intently, to not ignore contradictory information and insights but to go deeper into them. Use tools and knowledge like 5 Whys, Theory of Constraints, embrace contra-data points, find challengers to your view, and absorb inputs until they are validated or vanquished. That is the defense.

Your stakeholders:

Spin the coin, and it has another side. You will encounter confirmation bias in the world of your stakeholder community, just as you find it in yourself. They will see the world through a tint of lens, and only colours that resonate at that frequency will be pronounced. What tactic works to disarm someone who only seeks to confirm a view already held?

At first listen, then play the view back in a non-contradictory way — show understanding, because the first assumption of someone that sees disagreement, is that the disagreement is based in misunderstanding. Once you have done that, then play back alternative paths or viewpoints, again in a non-confrontational way. A great way of doing this is to begin a sentence with “Yes”, or “And”, or “I agree with”, and to avoid using the word “But” at all costs. Some of these tips and more are found in Crucial Conversations by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler: a book I recommend to any budding PM/PO.

Language matters in combating preconceived beliefs. Opening those beliefs up to a wider world of possibility requires tact, and careful choices in tone and pitch.

I also believe product specialists need to appreciate that others are unlikely to have negative intentions, even if what they are saying is demonstrably wrong. Those are two separate things. In general, whilst I don’t advocate being a sucker/naive, I do think it’s generally better to assume positive intent.

The key to helping people to understand, is to not attack them but to make it comfortable for them to take a different position to the one they started with. If your main method of debate and challenge is to bring facts or logic to the table, then the original proponent of an idea or priority for the product will do their utmost to defend their proposal, by bringing different logic and different facts to the table. Why? because nobody likes to lose an argument, to lose face, or to feel directly, publicly outwitted; do you?

Effort justification

This bias has similarities with Confirmation Bias but is of a particular variety and nuance. It has related ideas in behavioural economics like the Ikea Effect.

In a nutshell, it posits that we assign greater value to outcomes we defined, crafted or contributed to, than something we did not contribute to or define. For instance, let’s say you create a new widget or feature for messaging, and that this messaging feature is getting lots of use and positive feedback, but comparatively little versus other features designed by perhaps a predecessor Product Owner, or in another part of the platform by a different PO/PM. The science behind the studies in this space says that you will assign greater value to the feedback and positive news you receive about the feature you designed/ideated, than you will to the comparators; all things being equal, i.e. if those comparators are the same or better, you will see more value in your own craft outputs.

Again you can spin this to your stakeholders.

If a stakeholder comes to you with an idea, they will prefer their idea versus others which are presented to them; indeed, an experienced PM may have seen this manifest in meetings as defensiveness, argumentative positioning, or plain obstructiveness. And this is important, because let’s face it; often ideas presented to us…. suck. Not always in the same way. Sometimes they suck because of usability, sometimes feasibility. Sometimes sheer size and complexity make something sucketh, or the problem being solved itself maybe unimportant.

Veteran PMs/POs know this game — and will navigate this space sensitively. The ideal manoeuvre is a kind of reverse-Kimura or Jedi mind-trick. You do not reject an idea, never do that as you will affront the idea-giver (because of the Bias), but instead stealthily adapt or build onto it in such a way as to be seen to accept the idea. That then gives you three routes depending on the flavour of idea they’re transmitting:

1. If the problem is valid + the idea not awful: take the idea and make it good through stealthy adaptation. “Hmmm — yes, nice idea, could we also….”.
2. If the problem is valid + idea is awful: take that idea from the current session — rework it entirely to solve the business problem, then play back the newer solve at a different time, when the excitement of the original idea from the idea-creator has lessened, and they are more likely to accept alterations; “Let me come to you on that” + “We did a bit more thinking about this problem and discovered….”
3. If the problem is invalid/low priority: do not tackle the idea itself, tackle the problem only, i.e. “I think the idea is good, but would you agree this problem is not as important to solve as X?”

I’ve used all the above and more in many conversations, and they do really work. All they are really geared at is great collaboration, removing unecessary battles and getting people on the same hymn sheet.

I hope these resonate with people — but let me know if not, or any comments, thoughts, builds or questions!