The PR/FAQ is the centerpiece of Amazon's Working Backwards method: before you write a line of code, you write a fake press release announcing the finished product, plus an FAQ that interrogates it. It forces the team to start from the customer and the outcome, not the backlog. The method is genuinely good — that part isn't the problem. The problem is the artifact. A PR/FAQ is a static document, so the day it's approved is the day it starts drifting from the product you actually ship. This page teaches you how to write one properly, then shows how Draftlize keeps the decisions inside it — price, scope, who it's for — from quietly becoming fiction.
A PR/FAQ has two halves: a one-page press release that imagines the launch, and an FAQ that pressure-tests it. Write it before building. If you can't make the press release compelling and the FAQ survivable, the idea isn't ready — and you just saved a quarter. Here's exactly what each part holds.
A short, real-sounding announcement of the finished product, dated at launch. Headline, sub-headline, the problem in the customer's words, your solution, a quote from a leader, a quote from a delighted customer, and how to get started. Plain language, no jargon — if it doesn't excite a stranger, it won't excite the market.
Name the customer and the pain before the product. Working backwards means the release reads as the outcome the customer gets, not the features you built. If the problem isn't sharp, nothing downstream matters.
The questions a customer or journalist would ask: What is it, what does it cost, how is it different, when can I have it, is my data safe? These answers are the public-facing decisions — pricing, positioning, availability — stated plainly enough to publish.
The hard questions leadership will ask: Why us, why now, what's the size of the prize, what could go wrong, what do we have to believe, what are we NOT doing? This is where scope, target customer, and the risky assumptions get pinned down — the decisions that drive every spec after.
The beliefs the whole plan rests on, made explicit. "We assume customers will pay per use, not per seat." Surfacing them is the point of the exercise — and each one is a decision you'll either confirm or be forced to revisit.
The deliberate non-goals. Amazon insists on this line because scope is a decision, and an unstated non-goal becomes scope creep three sprints later. The clearest signal that a team has actually decided.
That's the method. Below: why the document drifts the moment it's approved — and what we do about it.
A PR/FAQ captures what you believed on the day it was signed off. But the product keeps moving — pricing shifts, scope narrows, the target customer sharpens. The document doesn't move with it. By launch, the press release describes a product that no longer exists, and the FAQ answers questions with last quarter's decisions.
The PR/FAQ is where you decide the price, the scope, the "what we are NOT doing." Then the PRD, the specs, and the eng tickets all assume those calls. When you change the pricing decision later, nothing connects it back to the PR/FAQ or forward to the specs that depended on it — so they silently go wrong.
The PR/FAQ does its job once — in the review meeting — and then gets filed. The assumptions it surfaced were supposed to be revisited as you learned. But a static doc isn't a reader; it can't notice that an assumption it recorded has since been disproven. So the drift accumulates unwatched.
Write the press release and FAQ in Draftlize and the load-bearing calls inside — price, scope, target customer, the non-goals, each risky assumption — become typed cards: structured, addressable by ID, citable from the PRD instead of buried in a doc. The narrative stays a narrative; the decisions get a spine.
Change the pricing decision and every card that rested on it — the external FAQ answer, the PRD section, the spec that assumed per-use billing — turns stale automatically, the way a build system invalidates everything downstream of a changed file. The PR/FAQ stops being a snapshot and starts tracking reality.
Claude Code or Cursor, over MCP, reads the press release and both FAQs before it drafts the PRD, and writes new decisions back into the same structure. The working-backwards thinking you did up front becomes living context the agent honors on every turn — not a document a reader never reopens.
Working backwards is the right way to think. The mistake is freezing the thinking in a document the moment you finish it.Keep the method. Let the substrate keep the decisions current.
Draft the press release and FAQ the Amazon way, let the agent turn the decisions inside into cards, and keep every one of them — and the PRD that depends on them — current as you learn.
Start free with $5