git:20260718.7c1285c to git:20260728.fac4544

11 added, 11 removed. Audit A to A.

---

name: prfaq-working-backwards

description: Write an Amazon PR-FAQ that starts from a launch-day press release and hard customer questions so an idea is tested on the customer before it is built. Use when proposing a new product or feature and you need to prove it is worth building.

---

# PR-FAQ and working backwards

Amazon's PR-FAQ makes you write the launch announcement first, before any code,

so the idea has to survive contact with a customer who never read your roadmap.

Working backwards from that press release exposes the products that sparkle in a

- planning deck but have no sentence a real person would care about. If the release

- is boring to write, the product will be boring to use.

+ planning deck but have no sentence a real person would care about. If the

+ release is boring to write, the product will be boring to use.

## Method

1. **Draft the press release as if you ship today.** One page, dated at launch,

written in past tense. Lead with the customer and their problem, then the

solution, then a quote from someone relieved it exists. Ban internal jargon:

if an outside reader cannot follow it, the pitch is not ready.

2. **Load the value into the headline and subhead.** The headline names the

product; the subhead states who it serves and the benefit in one line. If you

cannot compress the value into that subhead, the idea is unfocused, and no

amount of body copy will rescue it.

3. **Write the customer FAQ in the customer's voice.** What it costs, what it

- replaces, what it will not do, how their data is handled. Answer plainly. This

- is where "delightful experience" phrasing dies and concrete commitments take

- its place.

- 4. **Write the internal FAQ so it hurts.** The questions leadership will actually

- ask: unit economics, the riskiest assumption, why now, why us, what breaks at

- scale, what you will cut. A PR-FAQ that ducks its hardest question is

- marketing, and reviewers smell it instantly.

+ replaces, what it will not do, how their data is handled. Answer plainly.

+ This is where "delightful experience" phrasing dies and concrete commitments

+ take its place.

+ 4. **Write the internal FAQ so it hurts.** The questions leadership will

+ actually ask: unit economics, the riskiest assumption, why now, why us, what

+ breaks at scale, what you will cut. A PR-FAQ that ducks its hardest question

+ is marketing, and reviewers smell it instantly.

5. **Size both the prize and the bill.** Rough market size, expected adoption,

and the build cost. Working backwards includes admitting when the reachable

audience cannot justify the engineering. Killing an idea on paper is the

cheapest kill you will ever get.

- 6. **Iterate the document, never a slide deck.** Circulate the PR-FAQ, absorb the

- review's objections, and rewrite until the press release is one you would

+ 6. **Iterate the document, never a slide deck.** Circulate the PR-FAQ, absorb

+ the review's objections, and rewrite until the press release is one you would

truly publish. The doc is the deliverable; the meeting exists only to sharpen

it.

## Litmus tests

- Would a customer nobody paid to like it read the release and want the product?

- Does the internal FAQ include the question you are most afraid of, answered

honestly?

- Could you hand the release to PR on launch day with only light edits?

## Boundaries

A PR-FAQ decides whether to build, not how to build it: the engineering design

follows and belongs in a design doc. This is Amazon's convention, and companies

vary in length and required sections, so match the local template and reach for

the six-pager-narrative skill when the artifact is an operating or strategy

review rather than a new-product pitch.