IMPACT PRIORITIZATION

Identify the small number of factors most likely to drive most of the practical impact. Treat 80/20 as a prioritization heuristic, not a mathematical guarantee, and never omit mandatory requirements merely because they appear lower-impact.

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 — IMPACT PRIORITIZATION

What it actually does

Sometimes nothing about the framing is wrong except that everything in it is being treated as equally important. A risk register with 37 entries, analysed evenly, produces 37 mini-analyses and no decision.

IMPACT PRIORITIZATION asks the model to find the few items most likely to drive most of the practical impact, and to say why those deserve attention first. You may recognise the shorthand as 80/20.

It is a heuristic for concentration, not a mathematical claim — nothing here promises that 20 percent of the items produce 80 percent of the effect. The instruction also protects mandatory requirements and items that are individually small but combine into something material, which is the failure mode a naive ranking produces.

When to use it

Use IMPACT PRIORITIZATION when you already have the list, and need to know which few items actually carry the outcome.

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

BACKCAST fires when you name a concrete success you want by a date, and ask what has to be true between now and then.
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.
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

Broad coverage is mandatory.
Lower-ranked requirements cannot legally or operationally be omitted.

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

Oversimplification or treating 80/20 as a mathematical guarantee.

Starter instruction

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

Identify the small number of risks, causes, actions, or factors most likely to drive most of the practical impact. Explain why they deserve attention first, but do not omit mandatory requirements or lower-ranked items that could combine into material risk.

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: Here is everything on our backlog for next quarter. We can realistically do about a third of it. 1. Rebuild the search index; search is slow above 50k records 2. SSO for enterprise accounts; three deals are blocked on it 3. Dark mode 4. Migrate billing off the deprecated payments SDK, which reaches end of life in March 5. Bulk CSV import, asked for by more than 40 customers 6. Redesign the settings page 7. Mobile push notifications 8. Reduce cold-start latency on the API; p95 is 2.1s 9. Audit logging, required by two enterprise prospects' security reviews 10. Replace the charting library, which is unmaintained What should we do first?

Baseline — "What should we do first?"

So the quarter I’d actually plan is:

**Commit:** billing SDK migration, SSO, audit logging.
**Stretch:** bulk CSV import.
**Investigate cheaply:** quantify affected users/revenue for search and cold starts, and check whether the charting library poses an active security or compatibility risk.

IMPACT PRIORITIZATION — "risks, causes, actions, or factors"

The main thing I would **not** do is simply take the four most requested or visible features. The backlog points to three root causes that dominate practical impact: **enterprise readiness (#2, #9), dependency lifecycle risk (#4, potentially #10), and scaling/performance (#1, #8).** Addressing those reduces multiple downstream risks at once.

Both arms rank the same ten items and largely agree on the order, and both keep the March end-of-life migration near the top rather than ranking it away. The baseline stops at a list of items. The mode arm names what generates them — enterprise readiness, dependency lifecycle risk, scaling — and points out that three causes account for the whole backlog. That is the starter’s own wording doing the work: it asks for risks, causes, actions, or factors, and only one arm went past actions.

This is the narrowest difference of any pair on this site, and it would be dishonest to present it as more. Six of seven points checked appear in both arms: the mandatory item survives in both, both defer dark mode and the settings redesign, both flag that an unmaintained dependency could become mandatory, both treat SSO and audit logging as one enterprise gap, both name the anti-pattern of taking the loudest requests, and both give the same deciding metric for the last slot. One move separates them. Whether that move is worth a mode is a judgement the extract lets you make for yourself.

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