Prfaq working backwards

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.