Biases in Product Decisions

The meeting looked evidence-based.

There were charts.

Customer feedback.

Usage data.

A competitor comparison.

A few slides from research.

Everyone was discussing the same question:

Should we continue investing in the current direction, or reconsider it?

The team had already spent months building toward one answer.

Leadership had seen the roadmap.

Engineering had committed architecture around it.

Commercial teams had started talking about it.

The initiative had momentum.

So when new evidence arrived, something subtle happened.

Nobody ignored the data.

Nobody distorted the numbers.

Nobody said, “I don’t want to hear this.”

Instead, the evidence was interpreted through a direction the organisation had already begun to prefer.

Positive signals were treated as confirmation.

Contradictory signals were described as incomplete.

Customer concerns became edge cases.

The original assumptions remained mostly intact.

The discussion was still rational.

The process still looked analytical.

But the direction of reasoning had quietly changed.

The question was no longer:

“What does the evidence suggest we should do?”

It had become:

“How does this evidence fit the decision we already want to make?”

That distinction matters.

Because bias in product decisions rarely looks irrational.

It usually looks like reasonable judgment.

And that is exactly why it is difficult to detect.

Bias Is Not the Opposite of Intelligence

Product teams are full of intelligent people.

They use research.

Analytics.

Experiments.

Market data.

Customer interviews.

Commercial insight.

Technical judgment.

Yet none of those automatically removes bias from the decision.

Because bias does not only affect the answer we choose.

It can influence much earlier parts of the process:

Which signal catches our attention.

Which customer we listen to.

How we frame the problem.

Which evidence we consider credible.

Which options we explore seriously.

What result we describe as success.

And whether contradictory evidence is allowed to reopen the decision later.

That leads to an important distinction:

Bias does not always enter after the evidence.
It often determines which evidence becomes visible in the first place.

That is why simply telling teams to “be data-driven” is not enough.

A team can be highly analytical and still reason from a biased frame.

Data Does Not Automatically Neutralise Bias

There is a comforting belief in product organisations:

When opinions become subjective, bring in data.

That is usually good advice.

But data is not independent of the question we ask it.

Imagine a team believes an onboarding problem is primarily a usability issue.

They investigate:

screen abandonment;
clicks;
form completion;
completion time;
error rates;
field-level drop-off.

The analysis is rigorous.

The dashboards are accurate.

The findings may genuinely improve the interface.

But perhaps the real reason customers abandon onboarding is not that the interface is difficult.

Perhaps they do not understand why the process matters.

Perhaps they distrust what will happen after submitting the information.

Perhaps the value proposition was unclear before they ever reached the form.

The team can produce excellent data about the wrong problem.

Data can make a biased question look extraordinarily precise.

So the discipline is not only:

“What does the data say?”

It is also:

“Why are we looking at this data in the first place?”

The Bias Pathway™

Bias in product decisions is rarely one isolated mental error.

It often develops through a sequence.

I think of that sequence as The Bias Pathway™:

Notice → Interpret → Prefer → Justify → Reinforce

Each stage creates an opportunity for judgment to narrow before anyone realises it has happened.

1. Notice — What Gets Our Attention?

Product environments produce more signals than any team can process.

Customer conversations.

Support cases.

Usage patterns.

Sales requests.

Market movement.

Competitor launches.

Operational incidents.

Research findings.

Engineering constraints.

Leadership feedback.

Something has to determine which of those signals become important enough to discuss.

And attention is not neutral.

The loudest customer can appear more representative than the quiet majority.

A recent outage can dominate planning even when its long-term impact is limited.

One executive escalation can feel more important than a gradual pattern visible across thousands of users.

Successful customers are easier to interview than customers who silently abandoned the product.

What becomes visible shapes what becomes discussable.

Before asking:

“What does this signal mean?”

ask:

“Why did this signal receive our attention while others did not?”

2. Interpret — What Story Do We Attach to the Signal?

Signals do not arrive with meaning attached.

A drop in usage can mean:

the feature is no longer useful,

customers completed the task faster,

seasonality changed,

another workflow became easier,

measurement broke,

or behaviour moved somewhere else.

Interpretation converts observation into explanation.

This is where existing beliefs become powerful.

If we already believe the feature is confusing, lower adoption looks like usability evidence.

If we already believe the feature lacks value, the same behaviour becomes product-market evidence.

If we believe the problem is commercial, we may interpret it as positioning.

None of these interpretations has to be dishonest.

Bias is often not:

“I will ignore the evidence.”

It is:

“This explanation makes sense to me.”

That is much harder to challenge.

3. Prefer — Which Answer Already Feels Better?

Preference often forms before the formal decision.

A solution may already have an executive sponsor.

A team may have invested months in a particular architecture.

A customer may have been promised something informally.

A strategic narrative may already have been presented publicly.

A solution may fit the organisation’s current capabilities better than a more appropriate alternative.

Once one direction begins to feel more attractive, the decision space changes.

Alternatives are no longer evaluated from the same starting point.

One becomes:

the plan

while the others become:

reasons not to follow the plan.

That distinction is subtle.

But it changes everything that follows.

4. Justify — Does Evidence Still Produce the Decision?

Ideally:

Evidence → Interpretation → Decision

But once preference forms, the process can reverse:

Preference → Evidence selection → Justification

The team still uses research.

Still builds models.

Still reviews metrics.

Still discusses customer feedback.

But the purpose of the evidence has changed.

It is no longer primarily helping the organisation choose.

It is helping the organisation explain why the preferred choice is reasonable.

This is where confirmation bias becomes especially dangerous.

Not because people refuse contradictory evidence.

But because contradictory evidence has to clear a higher bar.

Evidence supporting the preferred direction is often described as:

signal.

Evidence challenging it becomes:

noise, edge case, insufficient sample, temporary anomaly, unusual customer behaviour.

Sometimes those descriptions are correct.

The danger is when the standard changes depending on which conclusion the evidence supports.

5. Reinforce — Does the Product Begin Creating Its Own Evidence?

This is where bias stops being only psychological and becomes systemic.

Imagine a recommendation system promotes one category more frequently.

Users see it more often.

They click it more often.

The organisation observes the higher engagement and concludes:

“Customers clearly prefer this category.”

So the system promotes it even more.

The original decision has now shaped the behaviour being used to validate the decision.

The same pattern can happen without algorithms.

A sales team focuses heavily on one segment.

That segment generates more customer conversations.

More feedback arrives from that segment.

Product teams see the volume of requests and conclude that the segment represents the strongest market demand.

Or a roadmap invests heavily in one workflow.

That workflow becomes easier to use.

Usage increases.

The usage becomes evidence that the original prioritisation was correct.

Sometimes it was.

But the system helped create the signal.

This is why product teams should be cautious about treating behaviour as neutral proof.

Never treat a signal as completely independent of the system that produced it.

Bias Exists at More Than One Level

Most discussions about cognitive bias focus on individuals.

That is useful.

But product decisions operate inside organisations.

Bias therefore appears at at least three levels:

Person → Group → System

Individual Bias

This is the familiar territory.

Anchoring.

Confirmation bias.

Overconfidence.

Loss aversion.

Sunk-cost effects.

Availability bias.

Recency effects.

These shape personal judgment.

But even perfectly self-aware individuals operate inside groups and systems that influence what they can see and say.

Group Bias

A team can become biased even when no individual is deliberately pushing the outcome.

A senior leader expresses an early preference.

Everyone continues discussing alternatives.

But now each alternative is evaluated relative to the leader’s view.

Nobody has been ordered to agree.

Authority has still changed the decision environment.

Or a team has worked together for years.

They share the same language, assumptions, customer relationships, and mental models.

That creates speed.

It can also create blind spots.

The organisation begins confusing:

shared interpretation

with

objective reality.

Agreement feels like evidence.

It is not.

Systemic Bias

This is the least visible layer.

The product itself.

The metrics.

The incentive structure.

The roadmap.

The customer-selection process.

The research system.

The operating model.

All can systematically make some evidence easier to see than other evidence.

For example:

If customer-success teams only escalate high-value accounts, product discovery may gradually become enterprise discovery.

If experimentation optimises only short-term conversion, long-term trust effects may remain invisible.

If reporting focuses on adoption but not abandonment, successful behaviour receives more analytical attention than failed behaviour.

Nobody needs to consciously prefer one outcome.

The system itself has begun filtering reality.

That is structural bias.

And structural bias is difficult to solve with individual awareness alone.

A Real Example: When “We Have the Data” Was Only Partly True

I encountered a version of this while working inside a large global logistics environment.

Operational data existed across regions and facilities.

Teams were capable.

Processes had been working for years.

There was even a central system already serving an important purpose.

So when the limitations of the data landscape began to surface, the natural responses were understandable:

“We have the data; it just needs some cleaning.”

“The central system covers most of what we need.”

“The regions manage this quite well locally.”

None of those statements was completely wrong.

That was what made the situation difficult.

Locally, many parts of the system did work.

Regional teams understood their own data.

Existing processes had supported the organisation successfully.

The problem became visible only when those local realities had to support enterprise-level decisions across regions.

The same metric could mean different things.

Data arrived through different processes.

Definitions varied.

Consolidation took time.

Leadership had information, but not always a single trusted interpretation of that information.

The challenge was not convincing people that everything they knew was wrong.

It was helping the organisation see that something could be locally valid and systemically insufficient at the same time.

That experience stayed with me because it illustrates how bias often works in organisations.

Existing systems develop credibility because they have produced value before.

That credibility becomes part of how new evidence is interpreted.

The question subtly becomes:

“How can we preserve what already works?”

before the organisation has fully asked:

“Is what already works still sufficient for the decision environment we now operate in?”

Bias in that situation was not irrationality.

It was continuity.

And continuity can be a powerful filter.

Confirmation Bias Becomes More Dangerous After Commitment

Confirmation bias is often described as seeking evidence that supports what we already believe.

In product organisations, there is an additional layer:

Once a belief becomes a decision, changing it becomes more expensive.

A roadmap has been communicated.

A budget allocated.

An architecture selected.

A team mobilised.

Leadership credibility attached.

Customers briefed.

The decision acquires organisational weight.

Now contradictory evidence is not challenging only an idea.

It is challenging commitments built around the idea.

This is why teams sometimes become more certain after investing — not because the evidence improved, but because reconsideration became more costly.

That creates an important product leadership question:

What evidence would cause us to reopen this decision?

Ask that before commitment becomes heavy.

If the answer is never explicit, the practical revisit threshold may quietly become:

Only overwhelming failure.

By then the organisation has usually paid much more than necessary to learn that the original assumption was wrong.

Sunk Cost Is Not Only About Money

Product teams rarely say:

“We have spent too much money to stop.”

The language is usually more sophisticated.

“We’re nearly there.”

“We should at least finish the current phase.”

“We’ve already solved the hardest technical problems.”

“We need to give adoption more time.”

“We told stakeholders this was coming.”

“Changing now would create confusion.”

Any of those may be valid.

But sunk cost in product work can take several forms:

Financial sunk cost
Money already spent.

Technical sunk cost
Architecture already built.

Roadmap sunk cost
Plans already communicated.

Political sunk cost
Leadership credibility attached to a direction.

Identity sunk cost
The organisation has begun seeing the initiative as part of its strategy or identity.

The more forms of sunk cost accumulate, the harder it becomes to distinguish:

“This is still the right decision.”

from:

“Changing the decision has become uncomfortable.”

Authority Can Bias a Decision Without Anyone Giving an Order

Senior leaders need opinions.

The solution is not to make leadership silent.

But timing matters.

Imagine a discovery discussion where the most senior person speaks first:

“My sense is that the real problem is pricing.”

The team may still debate freely.

But pricing now becomes the anchor.

Customer research gets interpreted relative to pricing.

Commercial evidence feels particularly relevant.

Alternative explanations must overcome an established frame.

No explicit command occurred.

Yet the decision environment changed.

One simple leadership discipline can help:

Ask for independent interpretations before revealing the preferred one.

For material decisions, have people answer first:

What do you think is happening?

What evidence matters most?

What option would you favour?

What would change your mind?

Then compare.

The goal is not to remove authority.

It is to prevent authority from becoming evidence accidentally.

Judgment Is Not the Enemy

At this point, it would be easy to conclude that strong product decisions require removing human judgment.

They do not.

Product management exists partly because the evidence is incomplete.

Markets change.

Customers contradict one another.

Experiments have limits.

Metrics lag reality.

Data has gaps.

Strategy requires choices about futures that cannot yet be measured.

Judgment is unavoidable.

The goal is therefore not:

Bias-free decision-making.

That is unrealistic.

The goal is:

Reasoning that remains visible enough to challenge and open enough to change.

A PM saying:

“I think this is the right direction.”

is not a problem.

A PM saying:

“I think this is the right direction because of A, B, and C. I may be overweighting the recent enterprise escalation. Evidence X would make me reconsider.”

is operating at a different level.

The judgment still exists.

But the reasoning around it has become inspectable.

That is the discipline.

The Counter-Bias Check™

Bias awareness becomes useful only when it changes how decisions are made.

Before a material product decision, six questions can help.

1. What Evidence Would Make Us Change Our Mind?

This is the strongest question in the set.

If nobody can answer it, the organisation may not be evaluating a hypothesis anymore.

It may be defending a position.

Define the disconfirming evidence before you encounter it.

2. What Are We Not Seeing Because of How We Framed the Problem?

Every framing creates a boundary.

If we call something an “activation problem,” we naturally study onboarding.

If we call it a “value-recognition problem,” we may investigate something much earlier.

Ask:

What explanation becomes harder to see because of the language we are currently using?

3. Who or What Is Overrepresented in the Evidence?

Enterprise customers?

Power users?

Recent incidents?

Sales feedback?

Successful customers?

One market?

One region?

One stakeholder?

Representation shapes interpretation.

Volume does not automatically equal importance.

And silence does not automatically equal satisfaction.

4. What Would We Choose If We Had Not Already Invested in the Current Direction?

This is particularly useful when teams feel:

“We’re too far in to reconsider.”

Imagine the existing investment disappeared overnight.

With everything you know today, would you still choose the same path?

If yes, continue with more confidence.

If no, the decision deserves another look.

5. What Is the Strongest Case Against Our Preferred Option?

Do not ask for token objections.

Ask someone to build the best possible argument against the current direction.

What evidence would they use?

Which assumption would they attack?

What consequence would they say the team is underestimating?

A decision that survives serious opposition is stronger than one that survives polite agreement.

6. Could the Product Be Creating the Behaviour We Are Using as Evidence?

This is the systemic check.

Did ranking influence the clicks?

Did defaults influence adoption?

Did availability influence preference?

Did sales targeting influence which customers provided feedback?

Did the previous roadmap make one behaviour easier and another less visible?

Before concluding:

“Customers prefer this.”

ask:

“What did the product make easier for customers to prefer?”

Better Decisions Need Designed Friction

Product teams spend enormous effort removing friction from delivery.

But some friction is valuable in decision-making.

A dissenting review.

An explicit assumption log.

Independent estimates before discussion.

A pre-mortem.

A revisit trigger.

A requirement to state what evidence would disprove the current belief.

These mechanisms slow a decision slightly.

That is sometimes the point.

The goal is not to make every decision difficult.

It is to introduce enough resistance that important decisions cannot move from:

preference

commitment

without exposing the assumptions underneath them.

The more consequential and difficult to reverse the decision, the more valuable this friction becomes.

Do Not Turn Bias Awareness Into Another Checklist Theatre

There is one danger in articles like this.

Teams learn the names of biases.

Then every disagreement becomes:

“That’s confirmation bias.”

“You’re anchoring.”

“This is sunk-cost fallacy.”

That is not better decision-making.

It is psychological vocabulary used as argument.

Bias labels should not become weapons against other people.

Use them first as questions about the decision process:

What evidence received attention?

What evidence did not?

When did preference form?

How did the standard of proof change?

Which commitments make reconsideration difficult?

What behaviour may the system itself be creating?

The goal is not to diagnose biased people.

It is to design decisions that make bias easier to detect.

The Real Product Leadership Work

Bias becomes especially important as product responsibility grows.

A single PM’s bias can affect one decision.

A leadership team’s bias can affect a portfolio.

A systemic bias can influence thousands or millions of customer interactions while continuously generating evidence that appears to validate itself.

That means product leaders have a responsibility beyond making good personal judgments.

They need to shape environments where:

dissent can surface;
assumptions are explicit;
authority does not become proof;
contradictory evidence can reopen decisions;
metrics do not become detached from how they are produced;
and teams can change their minds without treating reconsideration as failure.

This connects directly to product culture.

An organisation that rewards certainty will produce confident stories.

An organisation that rewards learning can produce better decisions.

Final Reflection

The most dangerous product bias is not having an opinion.

Product work requires opinions.

Hypotheses.

Judgment.

Conviction.

The danger begins when we forget that our beliefs influence what we notice next.

A preferred solution changes which questions feel relevant.

A committed roadmap changes which evidence feels credible.

A product decision changes customer behaviour.

And that behaviour can eventually return as evidence supporting the original decision.

That is how bias compounds.

So good product judgment is not about reaching some perfectly objective state.

It is about preserving the possibility that reality can still prove us wrong.

Good product judgment is not bias-free.
It is reasoning that remains open to being disproved.

The strongest teams do not ask only:

“Do we have enough evidence to make this decision?”

They also ask:

“Have we designed the decision well enough to recognise the evidence that might tell us not to?”

That is a harder question.

And often a much more valuable one.

Thanks for Reading 🙏

🧭 Bias is not removed by adding more dashboards, research, or analysis.

It becomes manageable when teams make their reasoning visible enough to question — and keep decisions open enough for evidence to change them.

Explore all articles at www.thepmpathfinder.com.