EvergreenA project dies.
Not dramatically. No Viking funeral. No orchestral soundtrack. Just a slow quiet death inside a Tuesday meeting called “Retrospective Final Final v2”.
Someone shares a Notion doc.
Someone else says: “Maybe we should wait two more weeks before shutting it down.”
Which is startup language for: “I still haven’t emotionally processed this disaster.”
Then comes the post mortem.
In theory, a post mortem is where intelligent adults gather to learn from failure.
In practice, it’s usually a corporate crime scene investigation where everyone is trying to leave without fingerprints.
The PM suddenly develops the memory of a goldfish.
Engineering starts speaking like lawyers.
Marketing explains that the campaign actually performed “above benchmark expectations” which apparently means absolutely nothing happened, but in a premium way.
And somewhere in the room sits one poor soul who can already feel the group unconsciously preparing to sacrifice them to the ancient gods of Shareholder Confidence.
Most teams think they are analyzing systems.
What they are actually doing is emotionally speedrunning blame.
That distinction matters.
Because blame feels productive. It gives the brain closure.
“John didn’t do customer interviews.”
Beautiful. Simple. Clean. Case closed.
Except now John hates the meeting, everyone gets defensive, and the company learns absolutely nothing useful.
A real post mortem sounds different.
“We launched without talking to customers.”
Now that is interesting.
Because systems create behaviour.
If your process allows an entire team to build something nobody validated, that wasn’t John. That was culture wearing a fake moustache pretending to be John.
Good post mortems force you to walk back through reality as it actually happened.
Not the polished mythology people reconstruct afterwards.
Because after failure, every company suddenly develops prophets.
“Oh yes, I had concerns early on.”
No you didn’t, Daniel. You named the Slack channel “rocketship-growth”.
Go back to the timeline.
The real one.
The confusing one.
The one where half the team thought the feature was already validated because someone mentioned it once in a customer call six months ago while screen sharing with no audio.
That version matters.
Then comes the painful part: listing every assumption that turned out to be nonsense.
We thought users wanted X.
We assumed the integration would take two weeks instead of spiritually aging the engineering team by seven years.
We believed paid ads would scale.
We thought “adding AI” would somehow compensate for the absence of a business model.
Write all of them down.
Then ask the uncomfortable question: Why did we believe this?
Was there no data?
Was there data that got ignored because it was ugly?
Or my personal favourite: the data changed months ago but nobody noticed because everyone was too busy presenting metrics with upward arrows in keynote slides.
This is where good teams separate themselves from theatre clubs.
Bad teams end the meeting with motivational quotes.
Good teams end with process changes.
Specific ones.
Not: “We should communicate better.”
That sentence should honestly be classified as corporate littering.
Instead:
Weekly customer interviews. Recorded. Shared with the team.
One success metric. Reviewed every standup.
Kill switch for features nobody uses after 90 days.
Decision logs for major assumptions.
Real systems.
Because personal resolutions are useless.
Every failed project is full of sincere people who promised to “do better next time.”
Then next time arrives and the exact same circus rolls back into town wearing slightly different Jira tickets.
The sign of a good post mortem is strange.
Nobody leaves angry.
Nobody leaves victorious either.
There’s usually just a quiet sadness.
Not because the project failed.
But because everyone finally sees how the machine actually behaves under pressure.
And once you see the machine clearly, you can improve it.
That’s the real value.
Not avoiding failure.
Understanding how you manufacture it.
