SECOND-ORDER THINKING

Examine what happens after the immediate effect and which plausible downstream consequences could change the decision. Stop when later effects become too speculative rather than extending the chain indefinitely.

A Power Mode is an instruction pattern, not a feature of the AI. Nothing recognises the name — the wording underneath it does the work, and you can copy it from this page.

From the book. Chapter 13 / Part VII — SECOND-ORDER THINKING

What it actually does

Most decisions get judged on their first consequence. Cut two weeks of testing, gain two weeks.

SECOND-ORDER THINKING asks what happens after that: what new dependencies and incentives the change creates, who absorbs the effect, and which downstream consequence could matter more than the immediate gain.

It is close to SYSTEMS THINKING and asks a different question. Systems thinking asks how the parts interact. Second-order thinking asks what happens next. The instruction tells the model to stop when later effects become too speculative, because the chain can always be extended one more step.

When to use it

Use SECOND-ORDER THINKING when you accept what a change does immediately and want to know what it causes after that.

It is the primary mode for this job: change how the problem is framed.

When not to use it

This is the section worth reading. Using only what the work requires is the point; a mode applied to the wrong shape of problem costs you a worse answer than plain language would have given.

Use a different mode instead

FIRST PRINCIPLES fires when you suspect the question itself assumes the current approach, and want the problem rebuilt from what is actually required.
SYSTEMS THINKING fires when you see the same problem recurring across parts that are managed separately, and suspect the parts are interacting.
IMPACT PRIORITIZATION fires when you already have the list, and need to know which few items actually carry the outcome.
BACKCAST fires when you name a concrete success you want by a date, and ask what has to be true between now and then.

Use no mode at all

Later effects have no credible connection to the decision.
The immediate effect is sufficient for the task.

There is no bonus for naming a mode when plain language is clearer. If you can already state the exact question, ask it.

Its failure mode

Endless consequence chains or speculative future storytelling.

Starter instruction

Paste this above your task. It is the whole mode — there is nothing else to switch on.

Examine the consequences beyond the immediate effect. Identify what happens next, who is affected, what new incentives or dependencies are created, and which plausible downstream effects could materially change the choice. Stop when later effects become too speculative.

The same task, run both ways

Blind run. Separate sessions per arm, Temporary Chat, no memory, no tools attached. Neither prompt named a mode. No arm searched.

The task: We are considering putting our support response-time target on our public website: "we reply to every ticket within 4 hours." Today our median first response is 2.5 hours and our 90th percentile is 9 hours. The team is six people covering 12 hours a day, five days a week. Ticket volume has grown about 6% a month for the last year. Should we do it?

Baseline — "Should we do it?"

I would not publish “we reply to every ticket within 4 hours” yet. Your current data says you cannot reliably keep that promise, and the wording “every ticket” makes a single miss a breach.
The key issue is the tail, not the median. A 2.5-hour median sounds compatible with a four-hour target, but a 9-hour 90th percentile means a meaningful share of customers are already waiting far longer than four hours. On top of that, 6% monthly volume growth compounds to roughly 2× the ticket volume in a year if the trend continues, while your stated staffing and coverage remain fixed.

[…]

The distinction I'd make is: a four-hour internal target could be useful today; a four-hour public guarantee is not supported by your current performance.

SECOND-ORDER THINKING — "Identify what happens next, who is affected, what new incentives or dependencies are created"

I would **not publish “we reply to every ticket within 4 hours” in your current state**. The issue is less the median than the word **“every.”** Your present distribution, coverage model, and growth rate make that promise structurally fragile.

[…]

The consequence chain looks like this:

Stage	What happens	Who is affected	Why it matters
Immediate	Customers see a strong, simple service promise.	Customers, sales, marketing	It can increase confidence and reduce uncertainty.
Next	Tickets exceeding four hours become visible failures rather than merely slow tickets.	Support, managers, customers	Expectations change faster than operations do. A 5-hour reply now feels like a broken promise.
Next	The support team starts optimizing specifically for first-response time.	Support agents	Agents have an incentive to send quick acknowledgements before doing substantive work. The metric can improve while customer experience does not.
Next	Older tickets approaching four hours jump ahead of newer or more important work.	Customers with complex/urgent cases	Queue ordering can become driven by SLA age rather than impact or efficient batching.
Next	Off-hours, vacations, sick leave, spikes, and difficult tickets require explicit exceptions or additional coverage.	Team leads, HR/finance, support staff	The website sentence quietly creates staffing and scheduling requirements.
Next	Sales and customer-success teams begin repeating the four-hour figure.	Sales, CS, larger customers	A marketing statement can evolve into an assumed service level and may start appearing in procurement discussions or contracts.
Material downstream effect	Capacity pressure gets substantially worse if growth continues.	Entire support organization	At 6% monthly growth, ticket volume is about 2× after 12 months (`1.06^12 ≈ 2.0`). With six people and unchanged productivity, workload per person roughly doubles.
Material downstream effect	Response times may deteriorate nonlinearly as utilization rises.	Customers and agents	Queues often behave badly near capacity: a relatively small increase in load can produce a large increase in the tail. Your 90th-percentile response time is therefore more vulnerable than the median.
Material downstream effect	Maintaining the promise forces a choice: hire, automate, extend coverage, reduce demand, or weaken the promise.	Finance, product, operations	You have converted a marketing claim into an ongoing capacity commitment.
Material downstream effect	Repeated misses can damage trust more than publishing no precise promise.	Customers, brand	A numerical promise gives customers an objective standard against which to judge failures.

I would stop the causal chain there. Claims such as “this will materially increase churn,” “agents will burn out,” or “competitors will exploit the failures” are plausible, but your data does not establish them strongly enough to base the decision on.

[…]

The key decision criterion is therefore not **“Is 2.5 hours below four?”** It is **“Are we willing to engineer staffing, prioritization, measurement, and future capacity around making four hours a dependable ceiling?”** With a 9-hour 90th percentile, limited weekly coverage, and volume currently compounding at roughly 6% per month, the evidence you have points to **not making the absolute public promise yet**.

Both arms say no, so nothing here turns on one of them being right. The baseline asks whether the number can be hit and answers on the tail, the coverage and the growth rate. The mode arm asks what publishing it makes people do, and the chain is specific: agents acknowledging early because first response is now what is measured, queue order driven by SLA age rather than impact, sales repeating the figure until it reaches procurement. Then it quotes the baseline’s own question back — "Is 2.5 hours below four?" — and says it is the wrong one.

The two arms agree on the verdict and on all four supporting facts: the tail rather than the median, the 12-hours-by-5-days coverage mismatch, "every ticket" making one miss a breach, and 6% monthly growth compounding to about 2x in a year. Everything the mode arm adds is downstream of a decision both had already reached the same way. It also stops itself rather than running the chain as far as it will go, discarding churn and burnout as claims the data does not support — which is the starter’s last sentence, about speculation, doing visible work.

Extracts are verbatim from 06_Test_Lab/Experiments/TL-026_SECOND_ORDER_THINKING_Raw_Outputs.md.

Related modes

Try it on your own work

Describe what you are actually doing and the Builder writes the full prompt — mode, context, output shape, and the verification step. It picks the mode from your description, which is why this link does not carry one.

Open the Prompt Builder →