When something goes wrong, the human brain does one of two things almost immediately. It looks for someone to blame — including itself — or it looks for external circumstances to explain what happened. Both responses are understandable. Neither one is useful if you actually want to learn something.
The self-blame spiral is the more familiar one. You replay the decision. You find every point where you could have chosen differently. You conclude that you are bad at this — at business, at parenting, at managing people, at whatever domain the failure touched. The feeling is convincing. The conclusion is almost always wrong.
The circumstance-blaming version is quieter and more socially acceptable. The market shifted. The timing was off. The other party didn't do what they said they would. All of that may be true — and it still tells you nothing you can actually use next time.
The Third Option: Treat It Like a Scientist
A scientist who runs an experiment and gets an unexpected result doesn't conclude that they are a bad scientist. They don't blame the equipment and move on. They update their hypothesis. They ask: given this result, what do I now know about the system that I didn't know before? What does this tell me about the variables I was controlling, and the ones I wasn't?
This is the reframe that changes everything. Your failure is not a judgment on your worth. It is a result — and every result contains information. The question is whether you slow down enough to extract it.
Separating the Decision from the Outcome
One of the most important distinctions in any failure post-mortem is separating the quality of the decision from the quality of the outcome. These are not the same thing, and conflating them leads to two different kinds of expensive errors.
A good decision can produce a bad outcome. You had good information, you reasoned well, you accounted for the risks you could see — and then something you couldn't have anticipated happened anyway. Concluding from this that your decision-making is broken would be wrong. The process was sound. The result was unlucky.
A bad decision can produce a good outcome. You cut corners on due diligence. You ignored a warning sign. You acted on incomplete information and happened to get away with it. Concluding from this that your process is fine would be even more dangerous — because the luck won't always be there.
The only useful post-mortem evaluates the process, not the result. Would a reasonable version of you, with the information available at the time, make the same call again? If yes — and the outcome was still bad — the lesson is about what information you need to seek out earlier, not about your judgment. If no — even if the outcome was fine — there is still something to fix.
How to Run a Failure Post-Mortem
Write it down. This sounds obvious and almost no one does it. The act of writing forces precision — you have to name exactly what happened rather than carrying around a vague, emotionally charged sense of it. It also creates a record you can return to, which is useful when similar situations arise.
The structure matters less than the honesty, but here is one that works: What did I expect to happen? What actually happened? What were the key decision points? What information did I have, and what was I missing? What would I do differently, and why? What did this failure reveal about an assumption I was making?
That last question is the most valuable. Every failure has at least one false assumption underneath it. Finding that assumption is the lesson — not "try harder next time" or "don't trust that person," but a specific update to your model of how something works.
Keep a Failure Log
The most useful habit I've developed is a simple document — call it whatever you want — where I log failures alongside the assumption they corrected. Not the story of what happened. Just the assumption update: "I assumed customers would accept a price increase if the product quality justified it. Evidence suggests the relationship history matters as much as the quality argument."
Over time, this document becomes something remarkable: a map of your actual beliefs about how the world works, updated by evidence rather than by hope. The failures that used to just be painful become genuinely useful. And the next time you're in a situation that rhymes with one you've logged, you're bringing better data than you had before.
That is what it means to treat failure as data. Not to feel good about failing. Not to celebrate it. Just to refuse to let it go to waste.