What does it mean to design by thinking about failure first, and what does that produce that requirement-driven design does not?

The practice

Start from what will go wrong rather than from what should happen. For each component and each interaction, ask: what does this do when its dependency is slow, unavailable, or returns something unexpected? What happens if this runs twice? What happens if this message arrives out of order, or twice, or a day late?

What it produces that requirement-driven design does not

• The ambiguous states. Requirement-driven design produces success and failure; failure thinking produces the third state — unknown — which is what a timeout on a write actually means. A system with only two states will guess, and guessing about money produces duplicates or losses, silently.
• The degraded modes. What the product does when a dependency is down is a product decision, and it is made by whatever the timeout handler happens to do unless someone asks the question deliberately.
• The idempotency requirements, which follow from "what if this runs twice" and which are far cheaper to build in than to retrofit.
• The reconciliation. Every asynchronous or external interaction will diverge eventually, and the backstop that detects it is the control that only failure thinking suggests.
• The terminal states. A workflow with no defined outcome for "compensation failed" accumulates stuck instances that nobody notices.

The technique that surfaces it efficiently

A premortem: assume the system has failed badly six months from now, and write the story of how. It produces different answers from asking what could go wrong, because it starts from the failure and works backwards — which bypasses the optimism that forward reasoning carries.

Where it applies most

Anything irreversible or financial. A display error is recoverable; a duplicate payout is not. The design attention should be proportional to the irreversibility, and failure thinking is what identifies which steps those are.

The balance to keep

Failure thinking applied uniformly produces paralysis and over-engineering. Not every path needs a compensating action, a reconciliation and a degraded mode.

Apply it in proportion to consequence: exhaustively on the money path and the irreversible actions, lightly on the display path. Which requires knowing which is which — and that classification is itself the first output of the exercise.