The NASA ABORT Method: How to Make Claude Kill Your Bad Ideas Before You Launch Them

Why "is this a good idea?" always fails

The article opens on a failure mode most builders already feel: ask Claude whether your idea is good and you get "it has potential", so you ship it anyway. The author's line is that this isn't analysis, it's politeness wearing a lab coat.

The reason is the one that makes risk assessment fail inside a real company. Nobody wants to be the person who kills the room's energy, so dissent gets softened into a "could go either way". Even the classic fix — appointing a devil's advocate, one person told to argue against — doesn't work, because everyone knows the criticism is assigned rather than real and quietly discounts it. The dissent gets outsourced to one voice and everybody else stops looking.

That diagnosis is the whole setup. The problem isn't that the model is too nice. It's that you asked a question with a polite default answer.

The grammar shift that does most of the work

The fix is a single change of tense. Instead of "what could go wrong?", you write: it is one year from now, this plan failed completely — not could fail, it already happened — now write the post-incident report. This is the premortem: assume the plan has already died, then work backwards to why.

The claim is that "maybe" invites a hedge while "already happened" forces a confession — the root cause, the early warning signs that got rationalised away, and the one assumption that was treated as fact. The author backs it with a 1989 Wharton/Colorado/Cornell finding that imagining an event has already occurred raises your ability to name real causes by roughly 30% versus standard risk assessment, reconfirmed by Klein in 2010.

Whether the exact number holds is another question (see the pushback), but the mechanism is sound, and it's the piece's best single idea. It's the one prompt worth keeping even if you ignore the other three.

Structure beats a single critic

Prompt two turns the lone sceptic into a panel. You ask the model to run a red team — a deliberate attack on the plan from several fixed angles — using four roles: the competitor (your most exploitable weakness), the worst-case customer (the assumption about them that's wrong), the resource auditor (where the plan quietly bleeds time, money or energy nobody budgeted), and your own exhausted future self six months in (the part you called "easy" that turns out hardest).

The point of naming distinct roles is diversity of failure modes, not redundancy: four different fault lines instead of one vague paragraph of caution. Each role has to give one sharp attack plus the evidence in the plan that supports it, which is what stops the model inventing generic risks.

Rank it, then force a verdict

Prompts three and four are where this becomes a decision tool rather than a worry list. Prompt three is the Failure Review Board: take everything found, rank each failure by severity and likelihood, cluster the points that trace to the same underlying cause, name the ONE fix that removes the most risk, and separate survivable risks ("monitor, don't block") from any outright dealbreaker. The author's line is sharp: a list of ten risks with no ranking is not a decision tool, it is anxiety with bullet points.

Prompt four is the Go/No-Go poll: force a confidence number from 1 to 10 with no hedging, name the single issue holding the score down, the one change that would move it most, and a final verdict — GO, NO-GO, or GO-WITH-CONDITIONS with the exact condition stated.

What you're after isn't a summary of pros and cons. It's a number, a verdict, and the one change that matters.

Five minutes, and where to point it

The chain is staged as a five-minute workflow: one minute per prompt, run in sequence in the same thread so each step feeds the next. The honest framing in the close is that none of this is new. Klein published the premortem in the 1980s and NASA has run Failure Review Boards for decades; what changed is that a process which used to need a room of engineers and a few days now needs one person and five minutes.

The author names seven places to point it: before a launch, before publishing something big, before signing a contract, a pricing call, a hire, a quit-or-start decision, a high-stakes meeting.

The realistic read is that this is not a magic oracle. It's a forcing structure that makes you look at the thing your excitement was hiding. The value is committing to a verdict you can defend, not the model's cleverness.

Vocabulary

• premortem — Assume the plan already failed, then explain why — before you build
• red team — A group told to attack a plan from set angles to find how it breaks
• forcing function — A step whose structure makes you do the uncomfortable thing you'd skip
• Go/No-Go poll — Each station gives a binary launch verdict on record — no "probably" allowed
• Failure Review Board — A body that ranks the ways a plan could fail before it runs

If you're building — what to watch for

• If you already have a pre-build checklist, this is the engine that goes under it: a checklist proves you thought about the risks, a four-step decision pass forces you to rank them and commit to a verdict.
• Any pipeline with plan/build/audit/verify gates is running the same shape on a schedule. The premortem is that shape run by hand on a decision you're about to make, which is where it's usually missing.
• Assigned-attacker structures beat a single "find problems" prompt. Naming distinct roles gives you distinct fault lines; one open-ended critique flattens into a paragraph of caution.
• Pair it with a different-lab model for the red team. Four adversarial roles inside one thread is diversity of costume, not diversity of mind.
• Prompt two doubles as a pre-publish red team: ask where readers will push back before a post goes out, not after.

Reading it critically

• Single-author promo piece with a newsletter CTA and a paid sponsor up top — treat the framing as marketing. The "30% / 1989 Wharton-Colorado-Cornell" stat is cited but not linked; verify it before quoting it anywhere public.
• Running all four prompts on one model in one thread is an echo chamber. It red-teams inside its own context and biases, so the four adversaries are four costumes on one mind. Real diversity needs a fresh thread or a different model.
• A confidence "number" from a language model is theatre. It anchors on how you framed the plan and isn't a calibrated probability. Its only value is forcing you to commit to a verdict — not the digit itself.
• Gating every small build through a five-minute ritual adds friction and can stall momentum. Reserve it for genuinely expensive or hard-to-reverse calls — a launch, a contract, a public post — not a throwaway script.