BACKCAST

Fix a concrete success end state, then decompose it into the intermediate conditions that must hold at each descending interval, ending at a concrete next action.

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.

Validated in the Test Lab and added after the book. Test Lab TL-015 — validated 2026-09-16

What it actually does

BACKCAST fixes a success state at a stated time and works backward through the conditions that must hold at each earlier interval — what has to be true at month nine, at month six, at month three, next week.

The output shape is the difference. A forward plan produces activities to perform in sequence. Working backward produces conditions that must already be true at a point in time, in dependency order, with the earliest interval collapsing into something you can do now.

Its nearest relative is PREMORTEM, which also works backward — from failure to causes, producing a risk list. BACKCAST works backward from success to prerequisites, producing a plan. Testing confirmed the two produce different material rather than the same material reordered.

When to use it

Use BACKCAST when you name a concrete success you want by a date, and ask what has to be true between now and then.

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

PREMORTEM fires when you fix a point in the future, declare it a failure, and ask what caused it. Prefer it over BACKCAST if: the fixed future is a failure, not a success.
IMPACT PRIORITIZATION fires when you already have the list, and need to know which few items actually carry the outcome. Prefer it over BACKCAST if: the path is already known and the question is which steps matter most.
FIRST PRINCIPLES fires when you suspect the question itself assumes the current approach, and want the problem rebuilt from what is actually required. Prefer it over BACKCAST if: the goal itself may be the wrong goal.
SYSTEMS THINKING fires when you see the same problem recurring across parts that are managed separately, and suspect the parts are interacting. Prefer it over BACKCAST if: the obstacle is interactions and dependencies, not sequencing.
SECOND-ORDER THINKING fires when you accept what a change does immediately and want to know what it causes after that.

Use no mode at all

The deadline is already fixed and the plan is governed by it — the model anchors to the end state without being asked.
No concrete end state can be stated; there is nothing to decompose from.
The end state is a failure — that is PREMORTEM.
The path is already known and the real question is which steps matter most.

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

Slicing the goal into equal fractions instead of deriving conditions, or planning past a constraint that makes an early interval infeasible.

Starter instruction

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

I am at [CURRENT SITUATION]. By [DATE] I want [CONCRETE END STATE]. Start from that end state and work backward: what must already be true at each interval between now and then, and what is the single concrete action I take this week? Derive each condition from the previous one rather than dividing the goal into equal parts. Mark any quantitative condition as an estimate.

Why this one asks you for something first

This mode needs a concrete end state and a date, which is why its starter asks you to name both.

Without a fixed success state there is nothing to work backward from, and the output collapses into an ordinary forward plan — which is the case the engine’s own gate exists to keep this mode out of.

The same task, run both ways

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

The task: Current state: the Prompt Builder signup form is live with a working delivery automation and zero subscribers. Target: 1,000 subscribers in 12 months.

Baseline — "plan how to grow the list to 1,000 in 12 months"

12-month target

Month	New subscribers	Total
1	30	30
2	45	75
3	60	135
4	70	205
5	80	285
6	85	370
7	90	460
8	95	555
9	100	655
10	105	760
11	115	875
12	125	1,000

The increasing targets matter. Months 1–3 build the machinery; months 4–12 benefit from content, backlinks, referrals, and repeat exposure.

BACKCAST — "fix 1,000 subscribers at month 12 and work backward"

Checkpoint	Subscribers	What has to be true
Month 12	1,000	You have a repeatable acquisition system producing roughly 30–35 new subscribers/week.
Month 9	600	You know where subscribers come from, at least one channel reliably works, and you can add ~100–135/month.
Month 6	300	You have product/lead-magnet fit: strangers are finding Prompt Builder and voluntarily exchanging their email for the PDF. You're approaching ~20–25 signups/week.
Month 3	100	You've stopped guessing. You know your signup conversion rate, your best traffic source, and which message/CTA produces signups. You can generate ~10–15 signups/week.
Next week	5–10	Tracking is installed, the signup funnel works end-to-end, and you've deliberately put Prompt Builder in front of enough relevant people to get the first real signups.

The important part is that month 3 is not primarily about reaching 100. It's about discovering a repeatable mechanism.

Both tables cover the same twelve months. The baseline’s third column is a running total — it counts output. The BACKCAST column is headed “What has to be true”, and the rows descend from month 12 rather than climbing from month 1. The last row is next week, and it is a condition you can act on today.

The baseline is not a bad plan, and much of its advice also appears in the mode arm. What it never produces is a statement of what must already be true at an earlier date.

Extracts are verbatim from 06_Test_Lab/Experiments/TL-015_BACKCAST_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 →