The PRFAQ Working Backwards Document
Write the launch press release before you build, so every word forces a real decision
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 8
- Confidence
- 95%
Amazon's mechanism for defining a product before a line of code is written: draft the press release and FAQ that would accompany the launch. The document has a fixed structure and brutal language rules — no subjective adjectives, numbers instead of descriptors, relentless cutting. The point is not the artefact; it is that a press release cannot be written vaguely, so it surfaces strategy and scope decisions that a slide deck lets you dodge.
Origin
Amazon's Working Backwards process and its PRFAQ mechanism, taught to every Amazon employee via an internal business-writing class (they hand out a card with five writing tips for your desk). Jason Shah learned it during his year at Amazon following the do.com acqui-hire and describes the template and the language rules from the inside. Contrasted in the episode with Airbnb's 11-star experience (Brian Chesky), which works backwards from a quality standard rather than from a launch moment.
Core principles
- 01Define the ideal end state first; the roadmap is derived from it, not the other way round.
- 02A press release is a forcing function because you must state what is actually true and specific about the product on day one.
- 03Ban subjective words. 'Great' is banned outright — say what is great and by how much ('saves customers 20 minutes each day').
- 04Numbers beat adjectives. Concision is not about saving ink; fewer words means every word carries ten pounds of weight, so trade-offs become deliberate.
- 05The customer quote must come from a real customer segment, not from you projecting yourself as the customer.
- 06Internal FAQs exist to de-risk the launch by naming the elephant in the room — the dog that isn't barking.
- 07Moving from slides to docs is worthless if you import the slide mindset and just add more words.
How to run it
- 1
Write the introduction — announce the thing
Open by getting straight to the point: state what you are announcing, as a real press release would. No preamble, no context-setting throat-clearing.
- 2
State the problem in one paragraph
Describe the customer problem in a single paragraph of clear, concrete language. If it takes more than a paragraph, the problem is not yet understood.
Watch out Vagueness here is where most PRFAQs die — a fuzzy problem statement makes every downstream section unfalsifiable.
- 3
Briefly describe the solution
Describe the product itself, briefly. It comes after the problem deliberately, so that the solution is visibly derived from the problem rather than the reverse.
- 4
Write the customer quote
Put yourself in the shoes of a specific named customer persona and write what they would actually say on launch day — what changed for them, in their own words, versus their life today. This is the mechanism that makes 'customer obsession' real rather than a value on a wall.
Pro tip Pick a persona from a real segment of your addressable market, not the segment you happen to belong to.
Watch out The lazy failure is writing the quote as yourself: 'I would like Prime, so let me write what I would say.' You may be a tiny slice of the market.
- 5
Write the leadership quote
Add one quote from a leader that explains how this product fits the company's strategy — phrased for the public, but honest about the internal strategic rationale. If you cannot write it without embarrassment, the strategic fit isn't there.
- 6
Close with a concrete call to action
Not 'download here'. State exactly how and when customers get it: available next month, via these portals, in these stores, in this state. This forces clarity on the rollout plan, which is usually the least-examined part of a product plan.
- 7
Append external and internal FAQs
External FAQs go in an appendix as a customer would ask them. Internal FAQs exist to de-risk the launch: raise the elephant in the room, name the dog that isn't barking, and answer the questions leadership will ask before they ask them.
Pro tip The internal FAQ is where the real review happens. Write the questions you are most afraid of.
- 8
Cut, then cut again — then read it as a customer
Go over the document countless times removing words. Then read the finished press release cold and ask honestly: would you use this product? If the answer is no, the product is wrong, not the writing.
Pro tip Kill your darlings. Cutting is not about brevity; it forces clarity of thought and makes each remaining trade-off intentional.
Watch out Any 'great' left in the draft will get red-penned by peers. Treat that as the standard, not a stylistic quirk.
In the wild
Amazon writers are forbidden from calling anything great in a press release. Shah explains why with a strategy argument: if something is 'great' because it arrives in two hours, versus 'great' because the selection is very wide, the implications for the entire strategy are completely different — but the word 'great' hides that fork entirely.
→ Forcing the specific claim ('user friendly in XYZ way', 'saves customers 20 minutes each day') surfaces the strategic choice that the adjective was concealing, before the team commits engineering time to it.
The mechanism is used at Amazon not only for new-product proposals but for proposals to buy a company — writing the launch announcement and FAQ for the acquisition to simulate what the end state actually looks like before committing.
→ Amazon reviewers get to evaluate the fully-imagined outcome and its risks rather than a deck of arguments, on decisions as large as an acquisition.
Common mistakes
Importing the slide mindset into a doc
Shah's sharpest observation: when people move from slides to docs, they often just carry the same fluffy, assertion-heavy mindset over and add more words. The document format buys nothing unless the language discipline comes with it.
Being the customer in your own customer quote
Product managers and leaders default to the intellectually lazy assumption that they are the customer. Writing the quote as yourself smuggles your own preferences in as market evidence, and you may represent only a small segment of the addressable market.
Confusing working backwards from a launch with working backwards from a quality bar
Amazon works backwards from a moment in time (the launch); Airbnb's 11-star experience works backwards from a quality standard. Both work, but they answer different questions — using one where you needed the other produces either an unambitious launch or an unshippable ideal.
Is it for you?
Best for
PMs and founders proposing a new product, feature line, or acquisition who need to lock strategy and scope before engineering starts, and who want a review artefact leadership can actually interrogate.
Not ideal for
Fast iterative optimisation on an existing product, or genuinely exploratory work where the end state is unknowable and the point of the work is to discover it.
From the transcript
“the structure of the prfa2 docs was generally an introduction where you announced the product problem solution customer quote leadership quote and a call to…”
“you should never write the word great in an amazon press release”
“because it forces clarity of thought fewer words means every word is you know 10 pounds in weight instead of one”
“in addition to not using the word great and words like it that are either subjective and what they mean or unclear and what they…”
“it it's intended to be very concrete in a way that avoids some of the fluffiness that frankly is funny when people try to move…”
From the episode
Building a meaningful career
Jason Shah (Airbnb, Amazon, Microsoft, Alchemy)