The Room Where Everyone Agreed
The meeting lasted forty minutes. Eight people around a conference table. The founder presented the plan: pivot the product from B2B to B2C, double the engineering team, launch in four months. Slides with upward-curving graphs. A compelling narrative about market timing.
One by one, the heads nodded. The VP of Engineering said it was ambitious but doable. The Head of Marketing said the brand could stretch. The CFO said the runway was tight but workable. By the end, every person in the room had agreed. The founder walked out feeling validated.
Six months later, the company ran out of money.
Not because the idea was bad. Because nobody in that room had a reason to disagree. The VP of Engineering did not want to seem negative. The Head of Marketing had just been promoted and was not going to challenge the person who promoted her. The CFO had flagged the risk in private but softened it in public. They were not lying. They were being human.
This is the most dangerous moment in any decision: when everyone agrees and nobody pushes back. Not because disagreement is always right. Because the absence of disagreement means the decision was never tested.
There is a name for the person whose job it is to argue the other side. In the Catholic Church, when evaluating candidates for sainthood, they appoint an Advocatus Diaboli -- a Devil's Advocate. This person's sole duty is to find every reason the candidate should not be canonized. Not because they believe the candidate is unworthy. Because the decision is too important to make without opposition.
You probably do not have a Devil's Advocate on your team. Most people do not. But you have a terminal.
What You Are Building
A reusable decision stress-test workflow. You will describe a decision you are about to make. The AI will systematically argue against it from five different perspectives -- financial, technical, market, team, and timing. Each counter-argument comes with evidence and a severity rating.
The output is a structured document: your decision, five categories of opposition, specific objections within each category, severity levels, and a summary of which blind spots you need to address before proceeding.
This is not about the AI being right. It probably will not be right about everything. The value is in forcing you to articulate why each objection does not apply -- or admitting that it does. That process, the act of defending your decision against structured opposition, is what separates conviction from wishful thinking.
Prerequisites:
- Claude Code installed and authenticated. If you have never used it, the First Hour with Claude Code tutorial gets you from zero to working in 60 minutes.
- A Claude Pro subscription ($20/month) or an Anthropic API key.
- A decision you are about to make. Real or hypothetical. The bigger the stakes, the more useful this exercise becomes.
Step 1: Write Your Decision Document (10 Minutes)
Before you open the terminal, write down your decision. Not a vague intention. A specific, committal statement that includes what you are doing, why, and what you are betting on.
Open a text editor. Create a file called decision.md. Write it like this:
# Decision: [One-sentence summary]
## What I Am Doing
[Describe the specific action. "Hiring two senior engineers" not
"growing the team." "Launching on Product Hunt in March" not
"doing some marketing soon."]
## Why
[The reasoning. What evidence or intuition led you here.]
## What I Am Betting On
[The assumptions that must be true for this to work. Be honest.
"I am betting that our current users will convert to paid at 5%"
is useful. "I think it will work out" is not.]
## What Success Looks Like
[Measurable outcome. Timeline. How you will know this was the
right call 6 months from now.]
## What I Am Giving Up
[Every decision is a trade-off. What are you not doing because
you chose this? What resources are being redirected?]
Here is a concrete example:
# Decision: Pivot from B2B SaaS to B2C mobile app
## What I Am Doing
Stopping all B2B sales efforts. Reassigning the 3-person sales team
to customer support for the new B2C product. Hiring 2 mobile
engineers. Targeting public launch in 4 months.
## Why
Our B2B pipeline has 6-month sales cycles and we are burning $80K/month.
Consumer interest in our free tier is 10x what we expected. Three
competitors just raised Series A rounds in the B2C space, which
validates market demand.
## What I Am Betting On
- Consumer willingness to pay $9.99/month after a free trial
- Our web technology can be adapted to mobile in 4 months
- The 3 B2B sales people can transition to B2C customer support
- We have enough runway (8 months) to reach profitability
## What Success Looks Like
10,000 paying subscribers within 6 months of launch. Monthly
revenue exceeding $80K burn rate by month 8.
## What I Am Giving Up
- 3 enterprise contracts in late-stage negotiation (combined
potential value: $180K ARR)
- The sales team's B2B expertise and relationships
- Predictable per-contract revenue in exchange for volume uncertainty
The more specific you are, the sharper the stress test becomes. Vague decisions get vague objections. Specific decisions get objections you can actually evaluate.
Step 2: Run the Stress Test (5 Minutes)
Open your terminal. Navigate to the folder where you saved decision.md.
cd ~/my-decisions
claude
Now give Claude Code the stress-test prompt. This is the core workflow -- paste this entire block:
Read the file decision.md. This is a decision I am about to make.
Your job is to act as a Devil's Advocate. Argue AGAINST this decision
from 5 different perspectives. Be specific, not generic. Use the
details I provided to construct targeted objections.
For each perspective, provide 2-3 specific objections. Each objection
must include:
- The objection itself (1-2 sentences)
- Why it matters (the specific risk or consequence)
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- What evidence would prove this objection wrong
## The 5 Perspectives
1. FINANCIAL — Cash flow, unit economics, hidden costs, opportunity
cost of capital, what the spreadsheet does not show.
2. TECHNICAL — Feasibility, timeline realism, hidden complexity,
dependencies, what engineers know but do not say in meetings.
3. MARKET — Customer behavior assumptions, competitive response,
timing, whether the market evidence actually supports the
conclusion.
4. TEAM — Capability gaps, morale impact, key-person risk,
whether the people involved can actually execute this plan.
5. TIMING — Why now vs. 3 months from now vs. never. External
factors, seasonal effects, dependencies on things outside
your control.
Write the output to a file called stress-test-results.md with
clear sections. At the end, add a SUMMARY section that lists:
- Total number of CRITICAL objections
- Total number of HIGH objections
- The single biggest blind spot you identified
- One question I should be able to answer confidently before
proceeding (and currently cannot based on what I wrote)
Press enter. Let it run.
Claude Code will read your decision document, analyze the specifics, and produce a structured opposition document. This typically takes 1-2 minutes.
Step 3: Read the Results and Respond (15 Minutes)
Open the results file:
open stress-test-results.md
You will see something structured like this:
# Stress Test Results: Pivot from B2B SaaS to B2C Mobile App
## 1. FINANCIAL
### Objection 1.1: You are abandoning $180K ARR for unvalidated revenue
**Severity: CRITICAL**
The 3 enterprise contracts in late-stage negotiation represent real,
near-term revenue. Consumer willingness to pay $9.99/month is an
assumption. You are trading confirmed demand for hoped-for demand.
**Why it matters:** If consumer conversion rates come in at 2% instead
of 5%, you need 2.5x more users to hit the same revenue — while
burning the same $80K/month.
**Evidence that would disprove this:** A completed pricing survey or
beta test showing >4% conversion from free to paid among your
existing consumer users.
### Objection 1.2: Your 8-month runway assumes zero cost increase
**Severity: HIGH**
Hiring 2 mobile engineers adds approximately $30-40K/month to burn
rate. Your actual runway after hiring is closer to 5-6 months, not 8.
**Why it matters:** 5 months is not enough to launch, acquire 10K
paying users, and reach profitability. You may need to fundraise
mid-pivot — the worst possible time to raise.
**Evidence that would disprove this:** A revised financial model
showing exact burn rate post-hiring and a realistic user acquisition
timeline.
[...continues for all 5 perspectives...]
## SUMMARY
- CRITICAL objections: 3
- HIGH objections: 5
- Biggest blind spot: Your mobile timeline assumes your web codebase
ports cleanly to mobile. You have not validated this with your
engineering team. If the port requires a rewrite, your 4-month
timeline doubles.
- Question you must answer before proceeding: "Have your engineers
done a technical spike to estimate actual mobile porting effort,
and do you have a plan B if it takes 7+ months instead of 4?"
Now comes the part that matters most. This is not a read-it-and-file-it exercise. For every objection, write your response. Go back to Claude Code:
Read stress-test-results.md. Now I want to respond to each objection.
For each one, I will provide my counter-argument. Help me evaluate
whether my response actually addresses the objection or if I am
rationalizing.
Here are my responses:
Objection 1.1 (abandoning $180K ARR): Those contracts have been
"late-stage" for 3 months. The probability of closing is maybe 40%.
And even if they close, $180K ARR does not change our trajectory —
we need 10x that to be viable as a B2B company.
Objection 1.2 (runway miscalculation): Fair point. I had not
recalculated after factoring in new hires. Let me redo the numbers.
[...continue for each objection...]
For each response, tell me:
- ADDRESSED: My response genuinely resolves the concern
- PARTIALLY ADDRESSED: Valid point but still has gaps
- NOT ADDRESSED: I am rationalizing or dodging
Write the evaluation to counter-arguments.md.
This second pass is where the real thinking happens. You will find that some objections dissolve when you engage with them. The $180K ARR objection might be less scary when you realize those contracts were never going to close. Others will survive your best arguments. The runway math does not care about your optimism.
Step 4: Make It Reusable (5 Minutes)
The stress-test workflow works for any decision. Save the prompt as a reusable template so you do not have to retype it each time.
Create a file called stress-test-template.md:
Read the file decision.md. This is a decision I am about to make.
Your job is to act as a Devil's Advocate. Argue AGAINST this decision
from 5 different perspectives. Be specific, not generic. Use the
details I provided to construct targeted objections.
For each perspective, provide 2-3 specific objections. Each objection
must include:
- The objection itself (1-2 sentences)
- Why it matters (the specific risk or consequence)
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- What evidence would prove this objection wrong
## The 5 Perspectives
1. FINANCIAL — Cash flow, unit economics, hidden costs, opportunity
cost of capital, what the spreadsheet does not show.
2. TECHNICAL — Feasibility, timeline realism, hidden complexity,
dependencies, what engineers know but do not say in meetings.
3. MARKET — Customer behavior assumptions, competitive response,
timing, whether the market evidence actually supports the
conclusion.
4. TEAM — Capability gaps, morale impact, key-person risk, whether
the people involved can actually execute this plan.
5. TIMING — Why now vs. 3 months from now vs. never. External
factors, seasonal effects, dependencies on things outside
your control.
Write the output to stress-test-results.md with clear sections.
At the end, add a SUMMARY section listing total CRITICAL and HIGH
objections, the single biggest blind spot, and one question I
should answer confidently before proceeding.
Now every future decision follows the same process:
- Write
decision.mdwith your specific decision. - Open Claude Code and paste
stress-test-template.mdor tell it to read the template. - Read the results. Respond to each objection.
- Decide with eyes open.
When to Use This (and When Not To)
This workflow shines for decisions with these characteristics:
- High stakes. The cost of being wrong is significant. A product pivot. A major hire. A technology migration. An investment.
- Consensus. Everyone around you agrees. That is exactly when you need structured disagreement.
- Irreversibility. Decisions that are hard to undo deserve more scrutiny than decisions you can reverse next week.
- Time pressure. When you feel rushed, you skip the thinking. A 30-minute stress test is faster than a 6-month mistake.
Do not use it for low-stakes decisions. Whether to use React or Vue for a side project does not need five perspectives of adversarial analysis. Save the tool for decisions that keep you up at night.
Why a Terminal, Not a Chat Window
You might wonder why this needs a CLI tool instead of a browser chatbot. Three reasons.
First, files. The stress test reads from decision.md and writes to stress-test-results.md. Those files live on your machine. You can version-control them. You can compare your stress test from January to the one from March and see how your thinking evolved. A chat window gives you a conversation that disappears.
Second, iteration. The counter-argument step -- where you respond to each objection and the AI evaluates your responses -- works because the AI can read the previous file and build on it. Each round creates a new document. You end up with a decision trail: the original decision, the objections, your counter-arguments, and the final assessment.
Third, reusability. The template file means you run the same rigorous process every time. No remembering what prompts worked. No re-inventing the framework. One command, consistent output.
What You Learned
- Unanimous agreement is a warning sign, not a green light. If nobody disagrees, the decision has not been tested.
- Structured opposition is more useful than general doubt. Five specific perspectives with severity ratings beat "I have a bad feeling about this."
- The value is in your response, not the AI's objections. The AI surfaces possibilities. You determine which ones are real. That act of evaluation is the thinking that was missing.
- Decisions are files, not feelings. Writing your reasoning down, getting it challenged, and responding in writing produces clearer thinking than any meeting.
The Catholic Church has used Devil's Advocates for centuries because they understood something most organizations still get wrong: important decisions deserve formal opposition. Not hostility. Not pessimism. Structured, specific, evidence-based pushback.
You do not need to hire a Devil's Advocate. You need a terminal, a decision document, and thirty minutes of honest thinking.
The next time everyone in the room agrees, that is your cue to open a terminal and ask: what am I not seeing?