The dashboard said the system was behaving as expected.

The people closest to the operation were not convinced.

They had years of experience.

They knew the local conditions.

They could recognise patterns before those patterns appeared neatly in a report.

So when a new system generated an alert and an experienced operator’s instinct said otherwise, the disagreement was not theoretical.

Someone had to decide what to trust.

The obvious answer in a modern product organisation is:

Trust the data.

That sounds disciplined.

Sometimes it is.

But it is incomplete.

Because data can be accurate and still be incomplete.

Intuition can be experienced and still be wrong.

And when the two disagree, forcing one to defeat the other too quickly can destroy the most valuable thing in the situation:

the disagreement itself.

That disagreement is information.

It is telling us that two different models of reality are producing different conclusions.

The real question is not:

“Which one should win?”

It is:

“Why do they disagree?”

The False Choice: Data or Intuition

Product teams are often taught to move from opinions toward evidence.

That is good discipline.

But somewhere along the way, the idea can become oversimplified:

Data = objective.
Intuition = subjective.

Reality is more complicated.

Data is a representation of reality created through:

• what we decided to measure;
• how we defined it;
• where the data came from;
• what was excluded;
• how quickly it becomes available;
• how we aggregated it;
• and how we interpreted the result.

Intuition is also a representation of reality.

It is built from:

• prior experience;
• pattern recognition;
• memory;
• assumptions;
• context;
• incentives;
• emotional reactions;
• and sometimes bias.

Neither is reality itself.

Both are models.

That leads to a more useful principle:

When data and intuition disagree, the conflict is often not between evidence and instinct. It is between two different models of reality.

The work is to understand what each model can see — and what each may be missing.

Data Is Evidence, Not Reality

Numbers create confidence because they are specific.

32%.

4.7 days.

18,421 users.

7.3% conversion.

A number feels more concrete than:

“Something seems different.”

And usually that concreteness is valuable.

But precision in measurement should not be confused with certainty in meaning.

Imagine retention rises by 8%.

That is evidence.

But what exactly does it prove?

Perhaps customers are receiving more value.

Perhaps the product now creates stronger habits.

Perhaps a different customer segment entered the cohort.

Perhaps an unwanted cancellation flow became harder to complete.

Perhaps pricing changed.

Perhaps the measurement window changed.

The number can be correct while the explanation remains uncertain.

Measurement can be precise while meaning remains uncertain.

This is one of the most important distinctions in data-informed product work.

Data constrains speculation.

It does not eliminate interpretation.

The Question Behind the Metric

Every metric is downstream of a choice.

Someone decided:

this is worth measuring.

Someone defined what counts.

Someone created the event.

Someone chose the aggregation.

Someone selected the reporting period.

Someone decided which comparison mattered.

That does not make the data untrustworthy.

It makes it contextual.

When teams say:

“The data says…”

I often think the more accurate sentence is:

“Given what we chose to measure, under these definitions, across this population, during this period, this is what we can observe.”

That sentence is less convenient.

It is also much closer to the truth.

Intuition Is Compressed Experience — Sometimes

Intuition deserves the same scrutiny.

There is a reason experienced people can sometimes detect problems before dashboards do.

A terminal operator who has worked in the same environment for years may recognise:

• an unusual sound;
• an unexpected sequence;
• a combination of small deviations;
• behaviour that technically remains within thresholds but feels operationally abnormal.

A salesperson may sense that customer objections are changing before the CRM taxonomy reflects it.

A product manager may notice that conversations with users feel different months before retention moves.

This is not magic.

Much of what we call intuition is compressed pattern recognition.

The person cannot always articulate every signal.

But their experience has taught them that certain combinations tend to precede certain outcomes.

That can be incredibly valuable.

But it comes with an important condition.

Experience produces useful intuition only when the environment has provided enough repetition and honest feedback to train it.

If someone has repeatedly made decisions but never learned whether those decisions were actually correct, experience may simply reinforce confidence.

Ten years of experience is not automatically ten years of learning.

Sometimes it is one year of assumptions repeated ten times.

Not All Intuition Is Expertise

This distinction matters because intuition can come from several places.

Pattern recognition

“I have seen this sequence before.”

Potentially useful.

Habit

“This is how we normally do it.”

Useful until the environment changes.

Preference

“This approach feels cleaner.”

Possibly relevant, but not evidence.

Fear

“The last failure was painful. I do not want that again.”

Understandable, but easily overweighted.

Identity

“This challenges something I have built or believed for years.”

Very powerful and often invisible.

Status

“My experience tells me…”

Sometimes true expertise.

Sometimes authority wearing the language of expertise.

So when intuition conflicts with data, the goal should not be to defer automatically to experience.

It should be to ask:

What is this intuition actually based on?

The Data–Intuition Conflict Model™

When data and intuition disagree, I find it useful to investigate four layers before trying to resolve the decision:

Evidence → Interpretation → Context → Mental Model

The disagreement can originate in any of them.

1. Evidence — Is the Data Trustworthy?

Start with the simplest question:

Can we trust the measurement itself?

That means checking things such as:

• Are we measuring the right phenomenon?
• Is the instrumentation reliable?
• Are definitions consistent?
• Is the sample representative?
• Is the data delayed?
• Are certain sites, users, behaviours, or states missing?
• Did anything change in collection recently?
• Are we looking at a proxy several steps removed from the actual outcome?

This step sounds obvious.

In practice, teams often skip it because the dashboard looks authoritative.

A clean visual can hide a messy data-generating process.

And a metric with three decimal places can still be based on a weak definition.

2. Interpretation — Are We Reading the Data Correctly?

Now assume the data itself is accurate.

The conclusion may still be wrong.

Usage went up.

Does that mean users value the product more?

Maybe.

Or perhaps they now need more steps to accomplish the same task.

Support tickets decreased.

Did quality improve?

Possibly.

Or perhaps contacting support became harder.

Time in product increased.

Is engagement better?

Or did the workflow become less efficient?

The metric tells us something.

The interpretation turns that observation into meaning.

Those are not the same thing.

A useful discipline here is to separate three sentences:

What did we observe?

What do we think it means?

What decision are we considering because of that interpretation?

Teams often compress all three into one.

That is where false certainty enters.

3. Context — Has the Environment Changed?

Historical data is powerful because it captures repeated behaviour.

But it is always historical.

Sometimes the environment changes faster than the measurement system can adapt.

A competitor changes pricing.

A regulation changes customer behaviour.

A new operating process is introduced.

A distribution channel changes.

A major customer segment enters or exits.

Something culturally shifts.

The historical model may still be internally accurate while becoming externally less relevant.

This is one reason experienced intuition can sometimes detect change first.

People close to the environment may see emerging signals before enough observations accumulate for the pattern to appear statistically.

That does not mean intuition is right.

It means the data may be lagging a changing context.

4. Mental Model — What Assumption Is the Intuition Using?

Finally, investigate the human side.

Why does the result feel wrong?

What did we expect instead?

What past experience created that expectation?

What conditions were present when that experience was learned?

Are those conditions still true?

This is where intuition becomes inspectable.

Instead of:

“My gut says the data is wrong.”

we can move toward:

“I expected a different outcome because historically these three signals tend to appear together. I can see two of them here, but the dashboard is not showing the third.”

Now the disagreement has become testable.

That is a much stronger place to make a decision.

A Real Case: When the Alert and the Operator Disagreed

I encountered this challenge while working on a signal-driven operational system in a global energy environment.

The target landscape covered terminal operations across Europe and Asia, including South Africa, with significant variation in operational and digital maturity.

Raw terminal data was not clean or uniform: field definitions varied, units were applied inconsistently, and timestamps, thresholds, and operational-state definitions could mean different things across sites.

So the technical challenge was not simply:

Build the pipeline.

It was also:

Build something that operators would trust enough to act on.

Those operators had spent years working through manual processes and local knowledge.

If a new sensor-generated alert said one thing and an operator’s instinct said another, the alert could simply be ignored — regardless of how technically accurate the system appeared to be.

That is a data-versus-intuition conflict in its most practical form.

The immature response would have been:

“The system has the data. Follow the system.”

The opposite immature response would have been:

“The operators know the environment. Trust them instead.”

Neither was sufficient.

The system therefore had to earn trust incrementally: begin with states and sites where data quality was most reliable, make the system’s reasoning visible rather than opaque, demonstrate accuracy, and expand from there. Trust was treated as a design requirement, not a communications problem to solve after deployment.

That distinction matters.

The objective was not to prove the operator wrong.

Nor was it to prove the system right.

It was to create enough visibility that the disagreement could be understood.

Sometimes the Data Is Wrong

“Wrong” does not always mean numerically incorrect.

Data can fail product decisions in several ways.

The instrumentation is wrong

The event fires twice.

The state is captured incorrectly.

The pipeline drops records.

The denominator changes.

Basic, but real.

The proxy is wrong

Teams measure what is available rather than what truly matters.

Clicks stand in for value.

Time spent stands in for engagement.

Tickets stand in for dissatisfaction.

Adoption stands in for success.

A proxy may correlate with the outcome until the product, market, or behaviour changes.

Then it can become misleading while remaining perfectly measurable.

The aggregation is wrong

An overall metric looks healthy.

One customer segment is deteriorating.

The average hides it.

This is particularly dangerous in complex enterprise products where geographies, workflows, user roles, and maturity levels differ substantially.

A global number can be statistically accurate and operationally meaningless.

The data is late

Lagging indicators are excellent at confirming what already happened.

They are less useful when the decision is about what is beginning to happen.

Churn is obvious after customers leave.

Dissatisfaction may have been visible months earlier in qualitative signals.

The system created the behaviour

This connects directly with systemic bias.

A default affects behaviour.

Ranking affects visibility.

Availability shapes usage.

Process rules determine which cases enter the dataset.

Then the behaviour is treated as independent evidence.

Sometimes the data is not observing the system.

It is observing the consequences of how the system was designed.

Sometimes the Intuition Is Wrong

Intuition deserves equal challenge.

There are several conditions where it becomes especially unreliable.

The environment has changed

Experience is strongest when the world continues to resemble the world in which the experience was developed.

When technology, customers, regulation, operating models, or competition change substantially, old patterns may become poor guides.

Feedback was historically weak

Reliable intuition requires reliable learning.

If decisions were never evaluated honestly, confidence may have grown without accuracy.

This is common in senior roles.

The more authority someone has, the less likely others may be to tell them that their judgment was wrong.

That weakens the feedback loop that expertise depends on.

The decision is emotionally loaded

Sunk cost.

Reputation.

Ownership.

Fear of failure.

A painful previous incident.

Intuition can feel especially strong when identity or emotion is involved.

That does not make the intuition useless.

It makes it worth examining more carefully.

The situation is genuinely novel

Pattern recognition requires patterns.

If the product, market, technology, or customer behaviour is genuinely new, analogy can create false confidence.

Sometimes:

“I have seen this before”

really means:

“This reminds me of something that may or may not be relevant.”

Sometimes Both Are Right

This is one of the most overlooked possibilities.

Data and intuition can disagree because they are describing different layers of the same system.

The dashboard says conversion is improving.

Customer-facing teams say trust is deteriorating.

Both may be true.

Short-term optimisation improved conversion.

The mechanism that produced it may be creating longer-term dissatisfaction.

Or:

The overall product metric is improving.

Regional operators report serious problems.

Both may be true.

The average improved while one operating context deteriorated.

Or:

An operator says the equipment is behaving unusually.

The system says all thresholds are normal.

Both may be right.

The current readings are within defined limits, while the operator is detecting an unusual combination of otherwise valid states.

This is why resolving disagreement too quickly can be dangerous.

The conflict may not mean one side is wrong.

It may reveal that the organisation is looking at different timescales, segments, layers, or definitions of success.

Treat the Disagreement as a Signal

Most organisations experience disagreement as friction.

The instinct is to resolve it.

Data says X.

Experience says Y.

Who has more authority?

Who has the stronger slide?

Which position can be defended faster?

But disagreement can be more valuable than agreement.

If an experienced operator repeatedly sees something that the dashboard does not, investigate.

If data repeatedly contradicts what leadership expects, investigate.

If customers describe a problem that usage metrics do not reflect, investigate.

If one team’s local reality conflicts with the global report, investigate.

The disagreement itself may be telling you:

• the measurement is incomplete;
• the intuition is outdated;
• the metric is a proxy;
• aggregation is hiding variation;
• the environment is changing;
• or two different outcomes are being discussed as if they were one.

The conflict between data and intuition is not something to resolve quickly. It is something to investigate carefully.

Trust Is Not the Same as Obedience

There is another lesson from operational systems that applies directly to product work.

A system is not trusted because it is technically correct.

People trust systems when they can understand enough about how the system behaves to calibrate their own judgment around it.

That is why explainability matters.

Not because every user needs to understand every calculation.

But because people need enough visibility to answer:

Why is the system telling me this?

What evidence is behind it?

When is it reliable?

Where are its limitations?

What should I do when my experience disagrees?

In the operational case, trust had to be built incrementally through reliable states, visible reasoning, and demonstrated accuracy rather than assumed at deployment.

That is a product lesson, not only an operational one.

The goal of data is not to eliminate judgment.

It is to improve it.

Strong Product Teams Do Not Ask “Who Wins?”

When data and intuition conflict, strong teams change the question.

Instead of:

Data or intuition?

they ask:

What exactly does the data prove?

Not what we think it implies.

What does it actually establish?

What exactly is the intuition reacting to?

Can the experienced person name the pattern, anomaly, or expectation underneath the feeling?

What could the measurement be missing?

Segment?

Context?

Qualitative behaviour?

Leading signal?

Operational state?

What could the intuition be importing from the past?

Old assumptions?

Different environment?

One memorable failure?

Personal ownership?

What evidence would change either side’s view?

This question matters enormously.

If neither side can describe what would change its position, the discussion is no longer primarily about evidence.

What small test could discriminate between the explanations?

Do not debate indefinitely if reality can answer cheaply.

Segment the data.

Inspect raw events.

Talk to affected users.

Run the operational check.

Compare locations.

Instrument the missing state.

Test the competing explanations.

Good decision-making turns disagreement into investigation.

The Decision Is Not Always “Wait for More Data”

There is a danger here.

Once teams become aware of uncertainty, they can delay decisions indefinitely.

That is not the objective.

You rarely get perfect evidence.

The real discipline is to distinguish between:

uncertainty we can reduce cheaply

and

uncertainty we have to decide through.

If an instrumentation issue can be checked tomorrow, check it.

If a critical segment is hidden in the aggregate, separate it.

If an assumption can be tested through five customer conversations, do them.

But if the decision involves a genuinely uncertain future, more historical analysis may not solve it.

At some point, judgment is required.

The goal is not certainty.

It is a decision made with a clearer understanding of what is known, what is assumed, and what would cause the organisation to revisit the choice.

Data-Informed Does Not Mean Data-Obedient

This distinction is worth making explicit.

Being data-informed does not mean every decision must follow the most visible metric.

It means evidence disciplines judgment.

The PM Pathfinder playbook frames it similarly: use data as a lens rather than a leash, balance quantitative and qualitative signals, and use data to challenge assumptions rather than replace judgment.

That is a more demanding standard than simply “being data-driven.”

Because it requires the PM to understand:

• what the metric actually measures;
• what it misses;
• what qualitative evidence adds;
• where judgment is entering;
• and when the evidence should change the mental model.

Data literacy is therefore not primarily the ability to build dashboards.

It is the ability to ask better questions of evidence.

Intuition-Informed Does Not Mean Experience-Obedient Either

The same applies in reverse.

Experienced people deserve to be heard.

They do not deserve automatic correctness.

Good organisations create mechanisms where intuition can enter the decision without becoming authority by default.

Instead of:

“I have been doing this for twenty years.”

the conversation becomes:

“Here is the pattern I am seeing, here is why I think it matters, and here is what I would expect to observe next if I am right.”

That converts intuition into something the system can learn from.

And if the intuition repeatedly proves valuable, perhaps the organisation should ask:

What is this person detecting that our formal measurement system is not?

That is how tacit knowledge can become organisational capability.

The Deeper Product Leadership Question

There is a larger issue underneath all of this.

What kind of organisation are you building?

One where:

numbers silence experience?

Or one where:

experience can ignore inconvenient evidence?

Neither scales well.

The stronger organisation creates a productive relationship between the two.

Data challenges intuition.

Intuition challenges measurement.

Both challenge assumptions.

And reality remains the final authority.

That requires a culture where changing your mind is not seen as inconsistency.

It is seen as evidence that the learning system is working.

Final Reflection

Product organisations often want a simple hierarchy.

Facts over feelings.

Data over opinion.

Evidence over intuition.

The intent is good.

But the hierarchy is too simple for complex systems.

Data can be precise and incomplete.

Intuition can be experienced and outdated.

Metrics can reveal what humans miss.

Humans can notice what metrics have not yet learned to see.

The real skill is not choosing one permanently over the other.

It is understanding what each knows — and what each cannot see.

When the numbers and your judgment disagree, do not ask which one to trust first. Ask what the disagreement is trying to teach you.

Because sometimes the dashboard is wrong.

Sometimes your instinct is wrong.

Sometimes both are right about different parts of the system.

And sometimes the most valuable signal is the fact that they disagree at all.

Continue Exploring This Perspective

Biases in Product Decisions

How attention, interpretation, preference and system design can shape the evidence product teams later use to validate decisions.

Signal-Led Product Thinking — From Signal to Insight

Why product work begins with learning to distinguish meaningful change from noise before moving toward action.

Trade-offs & Constraints

Why good decisions require clarity not only about what we choose, but what we protect, sacrifice, and make harder to.

If any of this feels familiar — in your product, your team, or your organization — I’m always open to a thoughtful conversation.

Thanks for Reading 🙏

🧭 Strong product judgment does not come from replacing experience with dashboards.

It comes from building a better relationship between evidence, interpretation, context, and judgment.

Explore all articles at www.thepmpathfinder.com.