What are the most common cognitive biases in product management?

Confirmation bias, anchoring, the sunk cost fallacy, the planning fallacy and outcome bias show up most often, one at each stage of a product decision. Confirmation bias distorts discovery, anchoring distorts prioritisation, sunk cost keeps failing projects alive, the planning fallacy breaks delivery dates, and outcome bias teaches the wrong lesson in the retro.

How do product managers reduce bias in decision making?

Not by trying to feel the bias, because biases are invisible from the inside. The practical method is to know which stage of the decision you're in and ask the question that disarms that stage's biases: what evidence would change my mind, is this the best option or just the first, would we still start this today, what usually happens on projects like this, and would I make the same call again with the same information.

What is the sunk cost fallacy in product development?

It's continuing to invest in a feature or project because of what you've already spent, rather than what it will return from here. The fix is to treat past spend as gone and ask one question: if we were starting fresh today, would we build this? Setting kill criteria before work starts makes that question much easier to answer.

What is the difference between outcome bias and hindsight bias?

Outcome bias judges a decision by its result, so a lucky call looks smart and a sound call looks foolish. Hindsight bias rewrites memory so the result feels like it was obvious all along. Both corrupt a retro. Writing predictions down before the outcome, and judging the decision on the information available at the time, guards against both.

How do you avoid confirmation bias in user research?

Design the research so it could prove you wrong. Before you start, write down what you expect to hear and what evidence would change your mind. Recruit representative users rather than convenient ones, and ask the question that could kill your hypothesis instead of the one that confirms it.

25 Cognitive Biases That Destroy Product Decisions (And the 5 Questions That Stop Them)

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

Your worst decisions come from a bias you can't feel.

Every product manager makes the same five calls on every product: what's true, which bet to make, whether to commit, how to deliver, and what to learn afterwards. At each one, a bias nudges you the wrong way. It doesn't feel like bias. It feels like a gut decision. You find out later it wasn't, and then it happens again on the next product.

You can't beat a bias by trying harder to notice it. The whole problem with a cognitive bias is that it's invisible from the inside. What works is knowing where each one shows up, so you can ask the one question that disarms it at the moment it matters. Below are 25 biases mapped to the five stages of a product decision, a counter-move for each, and the single question to ask at every stage.

Stage 1: Discover, where you go looking for proof you're right

Discovery is meant to show you reality. It's also where you're most tempted to see the reality you already believe. These are the five biases that bend it, used in user research and discovery work.

False consensus effect is assuming users think the way you do. The counter-move: watch users work. You are not your user. Curse of knowledge is forgetting what it's like not to know what you know, so you design for people who already understand. Explain the product to a first-timer and cut whatever they can't follow.

Availability bias gives too much weight to whatever is easiest to recall, usually the loudest customer or the most recent complaint. Ignore the loudest voice and the last complaint until you've seen the pattern. Sampling bias is learning from the users who were easiest to reach. Recruit representative users, not convenient ones. Confirmation bias is the big one: you collect the evidence that agrees with you and skim past the rest. Ask the question that could kill your hypothesis, not the one that flatters it.

The question for this stage: what evidence would change my mind? If you can't name it, you're not doing discovery. You're collecting quotes.

Stage 2: Decide, where the first option becomes the only option

Prioritisation and roadmap reviews are where the bet gets chosen. The biases here make a choice look obvious long before it has earned it.

Anchoring locks you onto the first number or idea anyone puts on the table. Generate three options before you debate any one of them. The framing effect means the way a problem is described decides the answer. Restate the problem two other ways before you pick. Loss aversion makes losing what you have feel worse than missing what you could gain, so the safe option always looks safer than it is. Put a price on the cost of doing nothing.

Status quo bias treats the current roadmap as the default that everything else must beat. Put the current roadmap on trial too. Choice overload is the opposite trap: so many options that the team stalls or grabs whatever is nearest. Cut serious contenders to three.

The question for this stage: is this the best option, or just the first one?

Stage 3: Build, where you back it because you've already started

Spec reviews and go or no-go calls are where you commit or kill. This is the stage where good teams lose the most money, because every week of work makes stopping feel more expensive.

The IKEA effect makes you value what you built yourself more than it deserves. Test desirability, not pride. The sunk cost fallacy keeps a project alive because of what has already been spent. Past spend is gone. The only question is whether you'd start this today. Escalation of commitment is sunk cost with a reputation attached: the more publicly you backed it, the harder it is to stop. Set kill criteria before you start, while you can still be objective.

Pro-innovation bias assumes that because something is new, people will adopt it. Assume adoption has to be earned, never expected. Not-invented-here is the reflex to build what you could buy or reuse. Buy or reuse before you build.

The question for this stage: would we still build this today, knowing what we know now?

Stage 4: Ship, where you swear it lands on time this time

Sprint planning and delivery are where optimism meets the calendar. These biases make every plan look better on paper than it will in practice.

The planning fallacy is underestimating how long your own work will take, even when you know similar work always ran late. Check the estimate against your last three deliveries. Optimism bias makes the good scenario feel like the likely one. Commit to ranges, never a single date.

Action bias is the urge to do something, anything, when things feel uncertain. Motion is not progress. Some weeks the right move is to cut scope, not add activity. The illusion of control makes you overrate how much of the outcome you can steer. Split the risks you own from the risks you can only watch. Overconfidence bias treats your estimate of success as more certain than it is. Pilot with one team before the organisation-wide rollout.

The question for this stage: what usually happens on projects like this? Your plan is a forecast. The track record is data.

Stage 5: Learn, where a good result hides a bad call

The retro and the post-mortem are meant to improve your judgement. They often do the opposite, because the biases at this stage rewrite what you thought at the time.

Hindsight bias convinces you that you knew it all along. Write your predictions down before the outcome, so you have a real record to check against. Outcome bias judges a decision by how it turned out rather than how it was made. Judge the decision, not the result. A good call can have a bad outcome, and a lucky one can look like genius.

Survivorship bias studies only what made it. Study what died, not just what shipped. Self-serving bias credits your skill for the wins and bad luck for the misses. Own the misses as fast as you own the wins. The fundamental attribution error blames a person when the system set them up to fail. Look for the system cause before you blame anyone.

The question for this stage: with the same information, would I make the same call again?

Five stages, 25 biases, one habit

Whiteboard of a stick figure walking a winding road past signposts reading 'Discover', 'Decide', 'Build', 'Ship' and 'Learn', each topped with a question mark, ending in a bubble asking 'the best option, or the first one?'

Here are the five questions on one line each, in the order you'll need them:

Discover: what evidence would change my mind? Decide: the best option, or the first one? Build: would we still build this today? Ship: what usually happens on projects like this? Learn: same call again, with the same information?

None of these need more intelligence. They need the question asked before the bias makes the call for you. You won't feel a bias coming, and that's fine. You only need to know which stage you're in.

Ask the five on your next big decision and see what changes. The PDF puts all 25 biases, their counter-moves and the five questions on one page, so you can keep it next to wherever you make the call.

Questions people ask

What are the most common cognitive biases in product management?: Confirmation bias, anchoring, the sunk cost fallacy, the planning fallacy and outcome bias show up most often, one at each stage of a product decision. Confirmation bias distorts discovery, anchoring distorts prioritisation, sunk cost keeps failing projects alive, the planning fallacy breaks delivery dates, and outcome bias teaches the wrong lesson in the retro.
How do product managers reduce bias in decision making?: Not by trying to feel the bias, because biases are invisible from the inside. The practical method is to know which stage of the decision you're in and ask the question that disarms that stage's biases: what evidence would change my mind, is this the best option or just the first, would we still start this today, what usually happens on projects like this, and would I make the same call again with the same information.
What is the sunk cost fallacy in product development?: It's continuing to invest in a feature or project because of what you've already spent, rather than what it will return from here. The fix is to treat past spend as gone and ask one question: if we were starting fresh today, would we build this? Setting kill criteria before work starts makes that question much easier to answer.
What is the difference between outcome bias and hindsight bias?: Outcome bias judges a decision by its result, so a lucky call looks smart and a sound call looks foolish. Hindsight bias rewrites memory so the result feels like it was obvious all along. Both corrupt a retro. Writing predictions down before the outcome, and judging the decision on the information available at the time, guards against both.
How do you avoid confirmation bias in user research?: Design the research so it could prove you wrong. Before you start, write down what you expect to hear and what evidence would change your mind. Recruit representative users rather than convenient ones, and ask the question that could kill your hypothesis instead of the one that confirms it.