For persistent problems, study the exceptions — when did it NOT happen?
When a problem persists across multiple attempts, identify exceptions where the problem was absent or reduced rather than analyzing why the problem occurs, as exception conditions are more directly actionable than problem mechanisms.
Why This Is a Rule
Solution-focused brief therapy discovered that studying exceptions to a problem is more actionable than studying the problem itself. "Why do I procrastinate?" produces theories about fear, perfectionism, and executive function — interesting but hard to act on. "When have I NOT procrastinated on similar tasks?" produces specific conditions: "When I had a clear first step, when someone was waiting for the output, when I started before 10 AM." Those conditions are directly engineerable.
The exception contains the solution. If the problem is absent or reduced under specific conditions, those conditions are the intervention. You don't need to understand the problem's mechanism — you need to replicate the exception's conditions.
This reversal of analytic direction is counterintuitive because problem analysis feels productive: understanding why something goes wrong feels like it should lead to solutions. But understanding why a car breaks down doesn't tell you how to drive well. Studying the drives that went well does.
When This Fires
- A problem recurs despite multiple attempts to fix it
- You've analyzed a problem thoroughly but can't find an actionable intervention
- Negative analysis ("why does this happen?") has produced insight but not change
- Any persistent difficulty where you can identify at least one exception
Common Failure Mode
Dismissing exceptions as irrelevant: "That time didn't count because I was on vacation" or "The conditions were unusual." The unusual conditions are the data. If the problem disappears under specific conditions, those conditions are your intervention target — even if (especially if) they seem unrelated to the problem as you understand it.
The Protocol
When a problem persists across multiple attempts: (1) Stop analyzing the problem. (2) Ask: "When was this problem absent or significantly reduced?" List 3-5 specific instances. (3) For each exception, document the conditions: what was different about the environment, your state, the task framing, the people involved? (4) Identify conditions shared across multiple exceptions. (5) Engineer those conditions into your next attempt. The exception conditions are your intervention — they're more actionable and more likely to work than any theory about the problem's cause.