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.
Method
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
1---2name: prfaq-working-backwards3description: 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.4---56# PR-FAQ and working backwards78Amazon's PR-FAQ makes you write the launch announcement first, before any code,9so the idea has to survive contact with a customer who never read your roadmap.10Working backwards from that press release exposes the products that sparkle in a11planning deck but have no sentence a real person would care about. If the12release is boring to write, the product will be boring to use.1314## Method15161. **Draft the press release as if you ship today.** One page, dated at launch,17 written in past tense. Lead with the customer and their problem, then the18 solution, then a quote from someone relieved it exists. Ban internal jargon:19 if an outside reader cannot follow it, the pitch is not ready.202. **Load the value into the headline and subhead.** The headline names the21 product; the subhead states who it serves and the benefit in one line. If you22 cannot compress the value into that subhead, the idea is unfocused, and no23 amount of body copy will rescue it.243. **Write the customer FAQ in the customer's voice.** What it costs, what it25 replaces, what it will not do, how their data is handled. Answer plainly.26 This is where "delightful experience" phrasing dies and concrete commitments27 take its place.284. **Write the internal FAQ so it hurts.** The questions leadership will29 actually ask: unit economics, the riskiest assumption, why now, why us, what30 breaks at scale, what you will cut. A PR-FAQ that ducks its hardest question31 is marketing, and reviewers smell it instantly.325. **Size both the prize and the bill.** Rough market size, expected adoption,33 and the build cost. Working backwards includes admitting when the reachable34 audience cannot justify the engineering. Killing an idea on paper is the35 cheapest kill you will ever get.366. **Iterate the document, never a slide deck.** Circulate the PR-FAQ, absorb37 the review's objections, and rewrite until the press release is one you would38 truly publish. The doc is the deliverable; the meeting exists only to sharpen39 it.4041## Litmus tests4243- Would a customer nobody paid to like it read the release and want the product?44- Does the internal FAQ include the question you are most afraid of, answered45 honestly?46- Could you hand the release to PR on launch day with only light edits?4748## Boundaries4950A PR-FAQ decides whether to build, not how to build it: the engineering design51follows and belongs in a design doc. This is Amazon's convention, and companies52vary in length and required sections, so match the local template and reach for53the six-pager-narrative skill when the artifact is an operating or strategy54review rather than a new-product pitch.
Amey-Thakur