A good business school case has no answer key. The professor carries with her what happened to the company in question, but the goal of the class is not guess it. Forty people read the same set of facts and arrive at different, defensible conclusions about what the protagonist should have done. The professor plays up the various conclusions and the disagreement between them is where the actual learning happens. The answer that eventually gets revealed as correct becomes trivial in the larger scheme of things.
A standard corporate retrospective is built the opposite way. It moves toward a single account of what went wrong, often written by whoever owns the writing of it, signed off in a meeting, and filed away.
I want to make the case for running at least one internal postmortem the other way, deliberately without a single answer, and for a specific reason: that it would surface a version of events that a standard retrospective quietly leaves out.
Two Honest Readings of the Same Failure
Consider a familiar composite scenario: An AI-assisted lead-scoring pilot performs well in its first quarter. It has promising conversion numbers, strong executive interest and a clear path to expand. But before it reaches the wider sales organisation, the initiative is quietly shelved.
The standard retrospective might explain this as a data problem: The model was trained on a clean pilot sample. Once it encountered the messier data from the broader organisation, its inputs degraded. The scoring became less reliable. The conclusion is straightforward: improve data engineering before trying again.
That explanation may be entirely true.
But write the same failure as a case study and ask people to examine it from different seats in the organisation. A second, equally credible explanation begins to emerge. From the sales operations perspective, the definition of a “qualified” signal had been set by marketing and data science. Sales had not meaningfully participated in creating it. By the time the model reached the broader sales floor, many sellers did not recognise its criteria as relevant to how they assessed opportunity quality. The model was not necessarily wrong about the data. It may simply have been answering a question that sales had never agreed was important.
Both accounts can be true. On its own neither account is complete.
A standard retrospective often settles on the technical version because it is easier to measure, easier to document and usually owned by the people writing the retrospective. It may also be the explanation that asks least of the organisation beyond a better build next time.
The value of the case method is that it resists convergence for longer. It keeps both perspectives in view long enough for the room to recognise that another chair was occupied all along.
A criticism you can expect: Isn’t this just academic navel-gazing? In a fast-moving org, leaders want decisions, not Socratic seminars.
You’ll need to show when the extra time buys real value (e.g., high-stakes, cross-functional transformations) and when it’s overkill (small, contained experiments).
What a Standard Retrospective Can Miss
The account missing from a retrospective is rarely the technical one. More often, it belongs to the people whose support the programme required but never secured. These may be stakeholders who were absent when success criteria were defined, then asked to endorse the finished pilot when it was time to scale.
Their view rarely disappears because anyone is being dishonest. It disappears because a document is usually written by the team that built the initiative, under time pressure, with a practical need to identify actions and move on. That process does not naturally prompt someone to seek out the people who declined to adopt the solution, distrusted its logic or quietly worked around it.
A well-run case discussion does.
It requires genuinely different vantage points to be present, not merely listed as “stakeholder feedback” and reconciled into a single narrative. That distinction matters.
A perspective that is reduced too quickly into a bullet point is no longer a perspective;
it becomes an input to someone else’s conclusion.
The Cost of Slower Closure
This approach is not free.
A case discussion takes longer than writing a report. It also produces less immediate closure. There may be no single conclusion that lets everyone say the issue is resolved and move on. For a pilot that failed for a simple, uncontested reason, that is a poor trade. If a vendor integration failed, a critical system was unavailable or a defined process was not followed, a conventional retrospective may be exactly what is needed.
Not every failure deserves a seminar. The case method earns its cost when the failure is expensive, recurring and resistant to tidy explanations. It is especially useful when retrospectives keep producing a clean technical diagnosis, but the same pattern continues: a strong pilot, weak adoption and a stalled scale-up.
That repetition is often a signal. It suggests the missing account belongs to someone who was never properly in the room to give it.
If you’re honest about the costs, some leaders will say, “We don’t have time for this.”
Your counter: you don’t have time not to do this when the same failure pattern keeps repeating at scale.
Running One Retrospective as a Case
The format does not need to be elaborate.
Pre-work:
- Start by writing the facts without an editorial conclusion. Describe what happened, the decisions that were made, the evidence available at the time and the outcome.
- Then identify two or three stakeholder positions with genuinely different claims on the failure. Avoid token perspectives added simply for balance. The point is to include people who can credibly argue that a different decision, definition of success or operating condition might have changed the outcome.
In-room structure:
- Bring people who held those positions into the room. Let them speak from where they sat rather than having someone else summarise their views.
- Something changes when that happens.
Output:
- The conversation shifts away from defending a preferred account of events. It becomes an effort to understand why sensible people, working with partial information and different incentives, reached different conclusions.
That is also what happens in a strong classroom discussion once nobody is waiting for the professor to reveal the right answer.
Won’t this feel contrived in a corporate setting? Yes, if you import the full HBS ritual.
Keep it lightweight: one-page brief, 60-minute session,
one facilitator who refuses to let the room collapse into consensus too early.
The goal is not to turn every failed pilot into an academic exercise. It is to recognise when the organisation needs a fuller diagnosis than a report can provide — and to make room for the chair that was missing from the first conversation.
How would your organisation’s most recent “technical failure” look if the people expected to adopt it were asked to tell the story first?