Why Outcome Bias and Hindsight Bias Quietly Undermine Your Impact Story
The Memory Trap No One Warns You About
One of the most common mistakes I see people make during change projects is assuming they will remember the starting point clearly enough to judge their progress later. But here's an absolutely blunt reality check for you this week… Your memory isn't that good!
Now… I don't say this because you are careless or forgetful; rather, it's because once change is underway the present and current reality starts to rewrite the past. The results you see in the first few weeks or months of a change project begin to shape how you remember your early concerns, the initial level of confidence of the people involved, the resistance, the uncertainty and the expectations people were carrying. What might have felt tricky or messy in the decision making period starts to smooth over as you experience early wins and progress. You start to remember it differently. What feels clear or even obvious in hindsight was rarely that way at the time.
Your Memory Rewrites the Past — Without Telling You
This isn't a flaw in your character, it's a quirk of being human. Once a change project begins the present quietly starts editing the past. Early wins begin to smooth over early struggles. The uncertainty and messiness that existed in the beginning slowly fades and what once felt genuinely difficult starts to feel like it was always manageable, always predictable, always heading somewhere clear. That shift happens without you noticing it and that is exactly what makes it so dangerous when you are trying to evaluate what actually changed and why.
Tracking Adoption Metrics Alone Isn't Enough
That is exactly why actively and deliberately collecting perceptions data at the start of a change project matters more than you might think. Take for example if you are introducing a new software product to improve data access and use in your business it is not enough to track adoption metrics each quarter or to only ask people about how the change went six months later. That is not a robust evaluation.
Measuring adoption rates tells you what people did. It does not tell you what actually shifted in them their confidence, their concerns, their experience of the work before and after. If you did not gather the views of the people affected prior to the change, including leaders, employees, clients or whoever the change was meant to support, then you have no reliable way of understanding what actually moved. You will only have a story told from the vantage point of the outcome or in hindsight.
"And that story is usually distorted."
Bias #1 — Outcome Bias: When Success or Failure Rewrites the Decision
Part of the distortion comes from outcome bias. Once a project appears successful people start judging the decisions that led to it more favourably. They look back and assume the decision making process was stronger than it really was or that the risks were smaller than they actually felt at the time. If the rollout struggles the opposite happens — suddenly people look back and speak as though the flaws were obvious from day one.
Whichever way it goes the result or outcomes start doing too much of the interpretive work and we see the starting point through the lens of where we are now.
Key Insight: The outcome doesn't just tell you how the project ended, it quietly rewrites how you remember its beginning.
Bias #2 — Hindsight Bias: "I Knew It All Along" Except You Didn't
The second distortion we face after a change has been made is hindsight bias. Once we know how something turned out we become remarkably bad at remembering what we believed before it happened. We convince ourselves we "knew all along" or at least should have known. That makes it much harder to look back objectively at the early conditions of a project and therefore objectively be able to report on progress, change or impact.
Again we interpret the past through the lens of the present which isn't where we were when we made the change.
Key Insight: Hindsight bias doesn't just cloud your memory it quietly destroys your ability to report on change objectively.
The One Thing That Protects You From Both Biases
When you skip the process of deliberately collecting baseline perceptions data from impacted individuals, you are not just missing a nice-to-have layer of context, you are giving up one of the only protections you have against faulty memory. Change is not only about what happened. It is also about what shifted in how people experienced the change and the work. So you need to actively collect information about where people were before you lead the change, otherwise your post-change data will be drenched in outcome bias and hindsight bias and you won't be able to see the wood for the trees.
Remember: Baseline perceptions data isn't a research luxury. It is your evidence that the change actually moved something real.
Questions to Ask Before Your Change Project Begins
(I'm going to continue with the software example but obviously feel free to adapt the following questions for your context.)
At the start of a software change project it would be important to know things like:
How easy do people currently think it is to access the data they need?
How confident are they in using it?
Do leaders believe the current systems are working?
Do employees see the change as useful or just another layer of administration?
Do clients experience delays, inconsistency or confusion that internal teams have normalised?
Without knowing these perceptions prior to the change in software later judgments will become dangerously vague. People might say things like "it's much better now" or "staff were really resistant at first" or "everyone knew the old system wasn't working" but those statements are not specific enough and to be honest they are more of a memory reconstruction than fact.
You Don't Need a Research Team—Just Rigour
This is why early baseline data collection matters. You can gather this through tools like short pulse surveys, interviews, focus groups, stakeholder mapping or simple reflection prompts. Use whatever tool suits your context and your needs best but rigorously pursue that baseline.
I do recognise that none of these methods or questions are perfect, and perceptions are a very subjective type of data. But collecting this information at the start is a far better option than trying to collect it after you have already begun, where you are relying entirely on memory.
| Method | Best Used For |
|---|---|
| Pulse Surveys | Quick, scalable perception snapshots |
| Interviews | Deep individual insight and nuance |
| Focus Groups | Shared team experience and group dynamics |
| Stakeholder Mapping | Understanding influence and readiness |
| Reflection Prompts | Low-effort honest self-assessment |
You're Not Collecting Data Because First Impressions Are Always Right
Ultimately you are not collecting perceptions data because people's first impressions and perceptions are always correct. You are collecting it because they are really influential and incredibly malleable once the project starts. From the beginning you need evidence of what people believed, feared, expected and experienced before success, failure or partial progress started distorting their view. Then you park the data and come back to it down the track.
FAQ
Q1. What is outcome bias in change management? It is when people judge past decisions based on how the project turned out, rather than on the conditions that existed at the time. A successful rollout makes the planning look smarter than it was and vice versa.
Q2. How is hindsight bias different from outcome bias? Outcome bias is about judging decisions through results. Hindsight bias is about memory — convincing yourself you "knew all along" how things would turn out, even when you didn't.
Q3. Why does baseline perception data matter? Without it, you have no honest before-and-after comparison. Metrics tell you what people did, baseline data tells you what actually shifted in how they thought, felt, and experienced the work.
Q4. When should baseline data be collected? Before the change begins as early as possible in the planning phase, before results start influencing how people remember the starting point.
Q5. What if I forgot to collect baseline data before starting? Collect what you can now and acknowledge the limitations when reporting. Then make it a non-negotiable habit for every future project.
Stop Comparing the Present to a Past That's Already Been Edited
Otherwise, when you are looking to report on the progress or the impact of your project, you will not be comparing the present to the past. You will be comparing the present to a past that has already been edited. Remove that extra subjectivity and collect great baseline data from the start because that is what honest data storytelling for business looks like in practice.
Here are the three things to take away from this:
1. Your memory is not a reliable evaluation tool. Once change is underway, the past is already being rewritten by the present.
2. Outcome bias and hindsight bias are not personality flaws. They are predictable, human distortions that every change project is vulnerable to unless you deliberately protect against them.
3. Baseline perceptions data is that protection. Collect it before the change begins, park it, and come back to it when you are ready to report with confidence and credibility.
Before your next change project kicks off what baseline data will you collect? What do you need to know about where people are right now, before you move them?
