Working Backwards
Start from the customer and the desired end-state, write it down, and iterate on
the document until the thinking is clear — long before any engineering. The
artifact is a PR-FAQ: a one-page mock press release + an FAQ of the hard
questions. Most PR-FAQs are never built — killing a weak idea cheaply on paper
is the point, not a failure.
Why writing: prose forces clarity that slides and good intentions can't. If you
can't write a compelling, honest press release for it, you don't understand it
yet — and neither will the customer.
References:
references/pr-faq-template.md — the press-release + FAQ structure, section by section.references/six-page-narrative.md — the prose-memo / silent-read discipline (for proposals & reviews beyond a launch).references/input-metrics.md — input-vs-output metrics, DMAIC, the WBR (how you'd measure it once live).
When to use this vs. its neighbors
- product-thinker decided should we? → use Working Backwards to force the customer end-state into focus.
- Idea is fuzzy / stakeholders disagree on what it even is → write the PR-FAQ; the draft surfaces the disagreement.
- The risk is "will this technically/behaviorally work?" → that's product-discovery (experiments), not this.
- The PR-FAQ is approved and clear → hand to shaping-work to define the work.
The method
- Write the press release first (customer-benefit-first, < 1 page). Use the
template. Write it as if it already launched. The customer's problem and the
benefit lead — not the technology.
- Write the FAQ (≤ 5 pages). Put the hard questions in, the ones that
could kill it: market size, per-unit economics, dependencies & third-party
risk, feasibility, what has to be true. The FAQ is a pre-mortem on your own
idea — if you skip the uncomfortable questions, the document is dishonest.
- Iterate as a document. Circulate; open the meeting with a silent read;
take general feedback first, then line-by-line; seniors speak last (no
anchoring). Expect 10+ drafts. Revise from the criticism, not around it.
- Decide: build / kill / keep iterating. A PR-FAQ that can't be made
compelling and honest is a cheap save — kill it here, not after a quarter of
engineering.
Output
A PR-FAQ (press release + FAQ, from the template) and a clear verdict.
Close with the signature block:
`★ Working Backwards View ────────────────────────`
- Customer + benefit: [who, and the one-line win]
- Verdict: [build / kill / iterate] — [why in one line]
- Biggest hole: [the FAQ question most likely to kill it]
`─────────────────────────────────────────────────`
Handoffs
- Verdict = build, but a key assumption is unproven →
product-discovery (test it cheaply first).
- Verdict = build, and it's clear →
shaping-work (define the work), then implementation-planning.
- Verdict = build, and this is a direction rather than a one-off → offer to record it as a bet in
.tap/product.md via /tap-skills:curate-product-context. The press release already states the customer end-state; the FAQ's most dangerous question is usually the kill condition.
- Need to re-litigate whether to build at all →
product-thinker.
- Offer to publish the PR-FAQ for team review:
/tap-skills:render-doc then /tap-skills:dossier-publish (md stays source of truth; republish after edits).
1---2name: working-backwards3description: Write a PR-FAQ to pressure-test a product idea customer-first — before committing engineering. Use when someone says "write a PR-FAQ", "press release", "working backwards", "PRFAQ", "start from the customer", "what's the press release for this", "before we build this", "is this idea clear enough to build", "draft the launch announcement", or has a fuzzy product idea and wants to force clarity on what to build and why. Amazon's Working Backwards method: define the desired customer experience as a mock press release + FAQ, iterate on the document until the thinking is clear, and kill weak ideas cheaply on paper. Sits between product-thinker (should we?) and shaping-work (what exactly?), alongside product-discovery (will it work?) — this skill answers "what is the customer-facing end-state, stated so plainly that the holes show?" NOT for validating risky assumptions with experiments (use product-discovery), NOT for breaking shaped work into a build plan (use shaping-work / implementation-planning).4---56# Working Backwards78Start from the customer and the desired end-state, write it down, and iterate on9the *document* until the thinking is clear — long before any engineering. The10artifact is a **PR-FAQ**: a one-page mock press release + an FAQ of the hard11questions. Most PR-FAQs are never built — **killing a weak idea cheaply on paper12is the point, not a failure.**1314Why writing: prose forces clarity that slides and good intentions can't. If you15can't write a compelling, honest press release for it, you don't understand it16yet — and neither will the customer.1718References:19- `references/pr-faq-template.md` — the press-release + FAQ structure, section by section.20- `references/six-page-narrative.md` — the prose-memo / silent-read discipline (for proposals & reviews beyond a launch).21- `references/input-metrics.md` — input-vs-output metrics, DMAIC, the WBR (how you'd *measure* it once live).2223## When to use this vs. its neighbors2425- **product-thinker** decided *should we?* → use Working Backwards to force the *customer end-state* into focus.26- Idea is fuzzy / stakeholders disagree on what it even is → write the PR-FAQ; the draft surfaces the disagreement.27- The risk is "will this technically/behaviorally work?" → that's **product-discovery** (experiments), not this.28- The PR-FAQ is approved and clear → hand to **shaping-work** to define the work.2930## The method31321. **Write the press release first** (customer-benefit-first, < 1 page). Use the33 template. Write it as if it already launched. The customer's *problem* and the34 *benefit* lead — not the technology.352. **Write the FAQ** (≤ 5 pages). Put the *hard* questions in, the ones that36 could kill it: market size, per-unit economics, dependencies & third-party37 risk, feasibility, what has to be true. The FAQ is a **pre-mortem on your own38 idea** — if you skip the uncomfortable questions, the document is dishonest.393. **Iterate as a document.** Circulate; open the meeting with a **silent read**;40 take general feedback first, then line-by-line; **seniors speak last** (no41 anchoring). Expect 10+ drafts. Revise from the criticism, not around it.424. **Decide: build / kill / keep iterating.** A PR-FAQ that can't be made43 compelling and honest is a *cheap save* — kill it here, not after a quarter of44 engineering.4546## Output4748A **PR-FAQ** (press release + FAQ, from the template) and a clear **verdict**.49Close with the signature block:5051```52`★ Working Backwards View ────────────────────────`53- Customer + benefit: [who, and the one-line win]54- Verdict: [build / kill / iterate] — [why in one line]55- Biggest hole: [the FAQ question most likely to kill it]56`─────────────────────────────────────────────────`57```5859## Handoffs6061- Verdict = build, but a key assumption is unproven → `product-discovery` (test it cheaply first).62- Verdict = build, and it's clear → `shaping-work` (define the work), then `implementation-planning`.63- Verdict = build, and this is a direction rather than a one-off → offer to record it as a bet in `.tap/product.md` via `/tap-skills:curate-product-context`. The press release already states the customer end-state; the FAQ's most dangerous question is usually the kill condition.64- Need to re-litigate *whether* to build at all → `product-thinker`.65- Offer to publish the PR-FAQ for team review: `/tap-skills:render-doc` then `/tap-skills:dossier-publish` (md stays source of truth; republish after edits).
teambrilliant