How to Fail Well: Turning Setbacks Into Data

The pitch didn't land. The launch underperformed. The plan you were so sure about fell apart in week two. The common advice — "learn from it," "fail forward," "every failure is a lesson" — sounds right and does almost nothing practically, because it never says what "learning from it" actually involves. Most people replay the failure, feel bad about it, and call that reflection.

Failing well isn't a mindset. It's a specific extraction process — turning a setback into structured data you can actually use next time, rather than a vague feeling of "well, that didn't work." Here's the difference between the two, and the protocol that makes the second one happen reliably.

What "failing well" actually means, mechanically

Failing well means running a structured post-mortem that separates what was within your control from what wasn't, and extracts a specific, testable change for next time — rather than a general resolution to "do better." Amy Edmondson, a Harvard Business School professor known for her research on organisational learning, distinguishes between "good" and "bad" failures: a good failure comes from a reasonable action taken under uncertainty, analysed honestly afterward; a bad failure comes from carelessness or repeating a known mistake without ever extracting the lesson.

The distinction matters because most people conflate all failure into one undifferentiated bad feeling. Two failures that look identical on the surface — a missed deadline, say — can have completely different causes, and only one of them yields something useful if you actually separate signal from noise.

Why "just learn from it" doesn't produce learning

Telling yourself to learn from a failure without a structured method to do so usually produces rumination, not analysis. Psychologist Susan Nolen-Hoeksema's research on rumination found that repetitively dwelling on a negative event, without a structured process for resolving it, was associated with worse mood and slower recovery — not more insight. Replaying a failure in your head is not the same activity as analysing it, even though it feels similar from the inside.

This is why two people can experience the same setback and walk away with completely different outcomes. One replays it emotionally for days and extracts nothing specific. The other spends twenty focused minutes with a structured method and walks away with one concrete change. The difference isn't resilience — it's whether a method was actually used.

The layer most advice misses: separate the decision from the outcome

Poker professional and decision-science writer Annie Duke's concept of "resulting" — judging the quality of a decision purely by its outcome — is the layer most failure advice skips entirely. A good decision can produce a bad outcome purely through factors you couldn't control or predict, and a bad decision can occasionally produce a good outcome through luck. Treating every bad outcome as proof of a bad decision means you can end up "learning" the wrong lesson entirely — abandoning a sound approach because it happened not to work this one time.

Think of it like judging a driver purely by whether they crashed, rather than by whether pulling out to overtake was sensible given what they could actually see at the time. A driver can check both mirrors, signal, and pull into a gap that then closes because another car accelerates unexpectedly. That's a reasonable decision with a bad outcome. Judging every crash as proof of bad driving, and every safe overtake as proof of good driving, teaches you the wrong thing about the road just as often as the right one.

The fix is separating two questions clearly: was the decision reasonable given what you knew at the time, and separately, what actually happened. Only the first question tells you anything about whether to repeat the approach.

The protocol: turning a setback into usable data

Picture a desk with every paper from a bad week piled into one heap — what actually happened, how you feel about it, and what you assume it means, all mixed together with no line between them. That heap is what an unprocessed failure looks like in your head. Failing well means sorting it into separate piles before you decide what to keep. Here's the five-step version.

1. Write down what happened factually, before you interpret it

Separate the raw sequence of events from your feelings about them. "The proposal was rejected after the second meeting" is a fact. "I'm clearly not good at this" is an interpretation, and interpretations made immediately after a setback are rarely accurate.

2. Ask whether the decision was reasonable given what you knew then

Not with hindsight — with the information genuinely available at the time. This is where Duke's resulting concept does its work: a reasonable decision with a bad outcome needs a different lesson than an unreasonable decision, even if the outcome looked identical.

3. Separate what was in your control from what wasn't

List the factors you could have changed and the factors you couldn't. Extracting a lesson only makes sense for the first category — you can't learn a useful lesson from bad luck except that it exists.

4. Name one specific, testable change

Not "communicate better" — something like "confirm budget authority before the second meeting, not after." A structured decision log, like a dedicated section in the Priority Pad, gives this a fixed place to live rather than a vague resolution that fades within days.

5. Set a date to check whether the change actually helped

A lesson that's never tested isn't really learned yet — it's just a hopeful note. Revisit it at the next relevant decision point and check whether the specific change made a measurable difference.

What not to do

Don't judge a decision purely by its outcome. That's resulting, and it teaches you the wrong lesson as often as the right one.

Don't skip straight to "lessons learned" without the factual sequence first. Interpretation before facts usually just restates how bad the moment felt.

Don't extract a lesson from something entirely outside your control. There's nothing actionable there except accepting that outcomes involve luck.

Don't leave the lesson vague. "Do better" isn't testable. A specific, named change is.

Designed for minds that don't switch off. Explore the Priority Pad →

Related Reading

• How to Assess Risk Before Making a Big Decision
• What Decision Fatigue Is Actually Doing to Your Working Day
• Expectations vs Reality: Why the Gap Causes Burnout

When to Take It More Seriously

If setbacks consistently trigger a level of distress that doesn't ease with time or reflection, or if you find yourself unable to try again after a failure due to persistent fear rather than reasoned caution, that's worth discussing with a professional. Difficulty recovering from failure can be connected to perfectionism, anxiety, or low self-esteem patterns that respond well to proper support.

In the UK, you can self-refer for CBT and other evidence-based therapies via your local NHS Talking Therapies service (formerly known as IAPT) at nhs.uk.

This article is a starting point, not a diagnosis. If you are concerned about your mental health, please speak to a professional.

Frequently Asked Questions

How do you actually fail well?

Run a structured process: write down what happened factually before interpreting it, assess whether the decision was reasonable given what you knew at the time, separate what was in your control from what wasn't, and name one specific, testable change rather than a vague resolution to do better.

What's the difference between a good failure and a bad failure?

A good failure comes from a reasonable decision made under genuine uncertainty and is analysed honestly afterward. A bad failure comes from carelessness, or from repeating a mistake that was already identified and never actually addressed. The outcome can look identical from the outside - the distinction is in the decision quality and the follow-up.

Why doesn't "just learn from your mistakes" actually work?

Because without a structured method, most people ruminate rather than analyse - replaying the event emotionally without extracting anything specific. Research on rumination has found this pattern is associated with worse mood and slower recovery, not more insight, which is why a defined process matters more than simply resolving to reflect.

Should I judge my decisions by their outcomes?

Not entirely. A reasonable decision can produce a bad outcome through factors outside your control, and a poor decision can occasionally produce a good outcome through luck. Judging decision quality purely by outcome - sometimes called "resulting" - can lead you to abandon sound approaches or repeat flawed ones based on a single result.