Working Backwards (PR/FAQ)

What it is

A framework for deciding what to build by writing the documents you would publish at launch before any build work starts. The team drafts a short press release announcing the finished product to its target customer, then a set of frequently asked questions (FAQs) that test whether the idea holds up. The practice comes from Amazon: Werner Vogels, Amazon's CTO, described it publicly in 2006 as starting "by writing the documents we'll need at launch (the press release and the faq)" and then working towards documents closer to implementation. Colin Bryar and Bill Carr, two former Amazon executives, set out the full method in their 2021 book Working Backwards. The press release has fixed parts: a heading that names the product, a subheading that names the customer and the benefit, a summary paragraph with a planned launch date, a problem paragraph written from the customer's point of view, a solution paragraph that says how the product beats what customers use today, and quotes plus a "getting started" line. The FAQ splits into external questions a customer would ask and internal questions leadership would ask about cost, feasibility, legal exposure and operations. If the press release cannot be made compelling, the idea is not ready to build. For a PMM, this is the earliest point to fix the customer-facing narrative: the press release becomes the seed of positioning and launch messaging, written while the product can still change to match it.

When to use it

• A new product or major capability is being proposed and no build work has started. The method only has value while the answer can still be "do not build" or "build something different".
• The roadmap item is described in features, not customer problems. If nobody can state in one sentence who the customer is and what changes for them, the press release forces that sentence to exist.
• Product, engineering and PMM hold different pictures of the same initiative. A single written narrative gives every function one document to argue with.
• A launch keeps failing at the messaging stage because PMM receives a finished product and has to invent a story for it afterwards.
• Leadership needs to choose between several candidate bets and wants each one expressed in the same customer-facing format before committing headcount.

Ownership

Product leadership (a CPO, a general manager or the product lead proposing the idea) owns the decision to build, reject or reshape the initiative; the PR/FAQ is the input to that call, not the call itself. The PMM commonly drafts the press release and the external FAQ and owns the customer-facing narrative they fix, while the product manager and engineering lead write most of the internal FAQ on feasibility, cost and dependencies. Ownership shifts with stage: at a seed or Series A company, a founding PMM or the founder often writes the whole document and the CEO decides; at scale, the product manager usually holds the pen on the full PR/FAQ, the PMM owns the press release and external FAQ as the source of later positioning, and a product review forum makes the build decision.

How to apply it

1. Name one customer segment before writing anything. Bryar and Carr stress that a product "for everyone" is a mistake; write the subheading for a specific segment, such as "finance teams of 20 to 200 people closing the books monthly", not "businesses".
2. Write the problem paragraph first, in the customer's words. Use interview notes, win/loss transcripts or support tickets. If you cannot write it without inventing the customer's pain, stop and run discovery before going further.
3. Draft the full press release in a few hours, not days. Follow the fixed parts: heading, subheading, summary with a launch date, problem, solution, two quotes and a getting-started line. In the solution paragraph, state what customers use today and how this product is meaningfully better, faster or cheaper.
4. Write the external FAQ as the customer would ask it. Cover price, switching effort, what the product does not do and how it compares with the incumbent option. Use plain language with no internal jargon.
5. Hand the internal FAQ to product and engineering. It answers what leadership will ask: build cost and timeline, technical risk, dependencies, legal or regulatory exposure, and the market size the problem paragraph implies.
6. Review with a small group, reading in silence first. Bryar and Carr describe circulating the document at the start of the meeting, allowing 15 to 20 minutes of silent reading, then spending the remaining time on questions. Keep early reviews to about ten contributors.
7. Revise across several drafts until the decision-maker can say build, reshape or stop. Treat "stop" as a valid output: an idea that never produces a compelling press release has saved its build budget.
8. Carry the approved press release into launch work. Use its subheading and problem paragraph as the first draft of the positioning statement and message architecture, and its external FAQ as the seed for sales objection handling. Measure success by the share of PR/FAQs reaching a clear decision within one quarter, by how closely the launch messaging matches the approved press release, and by post-launch adoption against the claim the press release made.