working-backwards

name	working-backwards
description	Amazon Working Backwards — draft a PR/FAQ (press release + FAQ) for a product or feature by starting at launch day. Use when the user wants a PR/FAQ or PRFAQ, a press release for something unbuilt, to "work backwards" from the customer, or to pressure-test a product idea before building it.

Working Backwards (PR/FAQ)

Facilitate a PR/FAQ where THE OWNER supplies the product conviction and you supply structure, customer-side skepticism, and prose. Working backwards means the document is written from launch day: the product already exists, the customer is already using it, and every claim must survive that framing. Keep an empty chair in the room — the customer who isn't here to object.

1. Orient

Look for existing material before quizzing:

• Prior strategy artifacts (docs/strategy/, or ask) — if the project has a Future Reality Tree or similar cause-and-effect analysis, its injections and desired effects are the raw material for the PR, and its negative branches seed the internal FAQ. Read them; don't re-elicit what's already decided.
• Existing PR/FAQ drafts (docs/prfaq/, or ask). Resume, don't restart.

Done when: you know what's already decided and what's genuinely open.

2. Elicit — the five customer questions

Quiz the owner (numbered prose questions, max ~4 per round; AskUserQuestion chips only for closed decisions with a recommendation marked):

1. Who is the customer? One specific person, not a segment soup.
2. What is the customer's problem or opportunity?
3. What is the single most important benefit? One; the rest go in the FAQ.
4. How do you know customers want this? Evidence, not enthusiasm.
5. What does the customer's experience look like? Walk the first use.

If the owner is unsure or an answer is fuzzy, branch to a thinking tool. These are Theory of Constraints thinking processes (Dettmer); if a dedicated TOC skill is installed, use it — otherwise build the tree inline in chat:

• Problem is a fog of symptoms, root unclear → Current Reality Tree: map effect→cause chains from the symptoms down to a root cause. The root cause becomes question 2's answer.
• Torn between two product directions or customer segments → Evaporating Cloud: surface the conflict's underlying requirements and the assumption to break. The breaking injection becomes the product thesis.
• Has the idea but the benefits are asserted, not argued → Future Reality Tree: the product is the injection, the PR's benefit claims are its desired effects. Negative branches are mandatory — each surviving one becomes a hard internal FAQ, each trimmed one becomes its answer.

Done when: all five questions have answers the owner has confirmed in their own words — an answer you supplied and they merely accepted doesn't count.

3. Draft the press release

One page, written from launch day, using the template and writing rules in TEMPLATE.md. Customer language throughout — if the empty chair wouldn't understand a sentence, rewrite it. Present the draft in chat, not just the file.

Done when: the PR fits on one page and contains zero internal jargon, zero unverifiable superlatives, and exactly one headline benefit.

4. Draft the FAQ

External FAQs first (what a customer or journalist asks), then internal (what a skeptical exec asks). Question banks are in TEMPLATE.md. The FAQ's job is to hold the hard questions so the PR can stay clean — an easy FAQ is a wasted slot. Pull hard questions from: FRT negative branches (step 2), the question banks, and anything the owner flinched at during elicitation. Where the honest answer is "we don't know yet", write that, plus how you'd find out.

Done when: every question a hostile reader would ask in the first read is present with an honest answer — no softballs padding the list.

5. Read back and scrutinize

Read the PR's causal spine aloud as IF…THEN sentences ("IF [product feature] THEN [claimed benefit]") and let the owner flag what sounds wrong. Then apply the Categories of Legitimate Reservation — clarity, entity existence, causality existence, cause sufficiency, additional cause, predicted effect — only where flagged or genuinely doubtful; never manufacture reservations. Collect kill/keep/rewrite verdicts per claim and per FAQ.

Done when: the owner has ruled on every flagged claim and the document reflects the verdicts.

6. Persist

Write the final document to docs/prfaq/<slug>.md (create the folder; ask only if the project has a competing docs convention). Record open questions and "how we'd find out" items at the bottom — they are the follow-up work.

Hard rules

• The owner decides; you never invent customer evidence. Missing evidence is an FAQ entry, not a gap to paper over.
• The PR is one page. Overflow goes to the FAQ or dies.
• A PR/FAQ that concludes "don't build this" is a success, not a failure — say so plainly if the elicitation points there.