prfaq-working-backwards

---
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.

## 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.
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
   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.