Solve problems backwards by identifying what would guarantee failure — use when direct optimization feels stuck or failure modes are unclear
<output_format>
[What success looks like]
| Failure Mode | Avoidance Strategy |
|---|---|
| [Mode 1] |
| [Strategy] |
[Synthesized plan that avoids all major failure modes]
[What failure modes might we be missing?] </output_format>
Launch an internal developer platform adopted by 80% of engineering teams within 6 months.
| Failure Mode | Avoidance Strategy |
|---|---|
| Build without input | Interview 5 teams before writing code; co-design with 2 pilot teams |
| Forced migration | Run alongside existing tools; migrate incrementally when platform proves faster |
| No docs | Onboarding guide ships with v1; pilot teams write the first tutorials |
| Slow bug response | Dedicated on-call rotation; SLA of 1 business day for blocking issues |
| Top-down mandate | Demo wins from pilot teams; let adoption spread organically before any mandates |
| Over-engineering | Ship MVP for the top 3 pain points only; add capabilities based on demand |
Start with pilot teams, solve their top 3 pain points, ship fast bug fixes, let results drive adoption. Documentation and incremental migration from day one.
We haven't considered what happens if pilot teams' pain points diverge significantly — the platform might fragment into team-specific solutions rather than a shared one. </example>
Receives: A goal or desired outcome the user wants to achieve
Produces: A ranked failure-mode inventory with avoidance strategies and a synthesized positive plan
Chainable to: second-order (to trace consequences of each failure mode), first-principles (to challenge whether the goal's assumptions are sound)