PR/FAQ Template
Amazon's working backwards format (Bryar & Carr). Write the press release before building anything. The PR page never exceeds one page. Total document under six pages. Use for one-way doors and qua...
The template
PR/FAQ Template
Amazon's working backwards format (Bryar & Carr). Write the press release before building anything. The PR page never exceeds one page. Total document under six pages. Use for one-way doors and quarter-scale bets only, never for small iterations or tech debt.
Page 1: The Press Release
Headline
[Customer-facing announcement, under 12 words. Names the outcome, not the feature. "Finance teams close the books in two days, not eight," not "Introducing continuous reconciliation."]
Subheadline
[One sentence. Who it is for and the single biggest benefit. "New [product capability] gives [customer type] [outcome] without [cost they pay today]."]
Opening paragraph
[3-5 sentences. THE FIRST SENTENCE NAMES THE CUSTOMER AND THE OUTCOME. Pattern: "Starting today, [customer type] can [outcome they could not get before]." Then what it does, in customer language. The how comes last, and briefly. If you cannot write a first sentence a real customer would lean in for, stop here. The bet is not ready, and you just learned that for the cost of an afternoon.]
Customer quote
"[Fictional but plausible. Written in the customer's voice, describing the outcome in their words, not yours. Test: would a real customer in this segment actually say this sentence out loud? If it reads like marketing copy after three drafts, that is a finding about the product, not your writing.]" [Role, company type. e.g., "VP Finance at a 400-person logistics company"]
Internal leader quote
"[Why the company built this. The strategic why-now, in one or two sentences. Not hype. The honest version of why this deserved a quarter.]" [Name, title]
How to get it
[Closing paragraph, 2-3 sentences. Where the customer goes, what it costs (or pricing model), what they need to do first. If this paragraph is hard to write, distribution is an unsolved part of the bet.]
Hard rule: this page never exceeds one page. If it does, the idea is not sharp enough yet. Cut until it fits.
Page 2-3: External FAQ
Questions a customer or journalist would actually ask. 6-8 of them. These are the questions support fields on day one, so answer them before building. Suggested set, replace as needed:
Q1: How much does it cost? [Pricing or pricing model. If undecided, write the leading option and the open question.]
Q2: What happens to my existing [data / setup / workflow]? [Migration story. Be specific about what carries over and what does not.]
Q3: Does it work with [the tools this segment already uses]? [Integration reality, including what is not supported at launch.]
Q4: What do I have to change about how I work today? [Honest adoption cost. "Nothing" is almost never true.]
Q5: How is this different from [the obvious alternative or competitor]? [The one-sentence differentiation a customer would repeat to a colleague.]
Q6: Is my data safe / who can see it? [Security and privacy answer at the depth this segment requires.]
Q7: [Segment-specific question] [The question only this customer type would ask.]
Q8: When can I get it? [Availability, rollout order, waitlist mechanics if any.]
Page 3-5: Internal FAQ
The hard questions. This section is where the document earns its keep. Do not skip any of these.
Q: What are the unit economics? [What does one customer outcome cost to deliver (compute, support, services), what does it earn, and at what scale does it pay? For AI-touched products: cost per outcome at current model prices and the trend. If nobody on the team can fill this in, that is the first task, not a reason to delete the question.]
Q: What is the quality bar, and how will we measure it? [Define "good enough to ship" as something falsifiable. For anything AI-touched: the eval. What are the labeled examples, the score threshold, and who owns the eval? "We'll know it when we see it" is not an answer.]
Q: What are we explicitly NOT building? [The boundary. Every bet has an expensive adjacent version someone in the room assumes is included. Name 3-5 things out of scope, especially the ones stakeholders will assume are in. Writing this down now is cheaper than discovering the disagreement in sprint four.]
Q: What is the biggest risk, and what did the premortem say? [Run a 10-minute premortem before the narrative meeting: assume it is twelve months later and this failed completely. Write why. Record here: the single most plausible failure cause, whether it changes the plan, and what tripwire you set. If you have not run the premortem, the answer to this question is "we have not run the premortem," which the room will treat accordingly.]
Q: Why now? [What changed that makes this the right quarter? A real answer names a shift: customer behavior, technology cost, competitive move, internal capability. "It's been on the roadmap a while" is the wrong answer dressed as patience.]
Q: What would have to be true for this to be a top-three bet? [The assumptions, stated as testable claims. Which are validated, which are open, and how the open ones get tested cheaply before full commitment.]
Q: Who is the team, and what stops while they build this? [A quarter-scale bet displaces something. Name what.]
The Narrative Meeting Protocol (60 minutes)
- Silent reading, 20 minutes. Everyone reads the full document in the room. No assumed pre-reads, no exceptions, no phones. The point is the whole room on the same evidence before the loudest voice frames the discussion.
- Discussion, 35 minutes. Work through the document section by section. Start with the hardest internal FAQ questions (economics, risk, why now), not the press release. The author answers; gaps get written into the doc live as open questions.
- Decision, 5 minutes. The meeting ends with one of three words said out loud:
- Fund. Named team, named start date.
- Kill. Written one-line reason, logged.
- Revise. Named owner, named return date for the next version.
A narrative meeting that ends without one of those three words failed.
Revision Rules
- The press release page never exceeds one page. Ever. Cutting it sharper is the work.
- Total document under six pages.
- Every revision updates the date in the header and keeps a one-line changelog at the bottom ("v2: tightened economics answer after finance review").
- Maximum two revise cycles. If the third meeting cannot say fund or kill, the answer is kill.
- If the opening paragraph still does not pass the lean-in test after revision two, stop revising the writing. The problem is the bet.
Header block (top of your document):
PR/FAQ: [Bet name]
Author: [name] Date: [date] Version: [v1]
Status: [Draft / In review / Funded / Killed / Revising]
Decision meeting: [date]