The PR/FAQ Template: Amazon's Working Backwards for Your Bets

Most bet documents I see are built forwards. They start with what the team wants to build, list the features, and somewhere on page three reverse-engineer a customer benefit to justify it. The customer shows up as decoration. Then the thing ships and everyone is surprised when the launch post is hard to write, because the launch post was always going to be hard to write. Nobody checked.

The PR/FAQ checks first. You write the press release before you write a line of code, and if the press release is boring, you just saved a quarter. The template below is the full skeleton.

I think it is the highest-signal bet document ever designed, and the reason is structural: it forces the customer outcome into the first sentence. Not the roadmap slot. Not the architecture. The thing a customer would actually notice changed in their life. Everything else in the document exists to defend that sentence.

The short version

The PR/FAQ is Amazon's working backwards format, documented by Colin Bryar and Bill Carr: a one-page mock press release announcing the finished product, plus an FAQ split into external questions (what customers would ask) and internal questions (the hard ones: unit economics, the quality bar, the biggest risk, what you are deliberately not building). It is read in a 60-minute narrative meeting that opens with 20 minutes of silent reading and closes with an explicit decision. Use it for one-way doors and quarter-scale bets, never for small iterations. It is the working-backwards discipline behind storytelling in the skill stack, and the deep dive on why narrative wins decisions is storytelling is a PM core skill(coming Jul 6).

What's in the template

The press release page

One page, never more. Headline, subheadline, an opening paragraph that names the customer and the outcome in the first sentence, a customer quote slot, an internal leader quote slot, and a closing paragraph on how to get it.

The opening paragraph is where most drafts die, and that is the format working as intended. "Today we announced an improved data pipeline" is not an announcement, it is a changelog. "Starting today, [customer type] can [outcome they could not get before]" is an announcement. If you cannot complete that sentence in a way that would make a real customer lean in, the bet is not ready, and you learned it for the cost of an afternoon.

The customer quote is fictional and that is fine. The test is whether a real customer would plausibly say it. If your drafts keep coming out as marketing copy, the product is not solving something customers would describe in their own words. That is a finding, not a writing problem.

The external FAQ

Six to eight questions a customer or journalist would actually ask. How much does it cost. What happens to my existing data. Does it work with what I already use. What do I have to change. These are the questions support will field on day one, so answering them before building is free insurance.

The internal FAQ

This is where the document earns its keep, because it holds the questions teams avoid in decks. The template includes slots for: the unit economics (what it costs per customer outcome and at what scale it pays), the quality bar and how you will measure it (for anything AI-touched, this means the eval, per the eval is the spec), what you are explicitly not building, the biggest risk plus a premortem result, and why now instead of last year or next year.

The "what we are not building" question deserves special mention. Every bet has an expensive adjacent version that someone in the room is quietly assuming is included. Writing the boundary down before funding is much cheaper than discovering the disagreement in sprint four.

A worked example fragment

The shape of an opening paragraph from the artifact, sanitized:

Starting today, finance teams at mid-market companies can close their monthly books in two days instead of eight. [Product] connects directly to the systems where transactions already live, reconciles them continuously through the month, and flags exceptions the day they occur instead of the week the close begins. Teams spend the close reviewing judgment calls, not hunting discrepancies.

Customer named in the first clause. Outcome quantified in the first sentence. The how arrives only after the what. That ordering is the entire format compressed into one paragraph.

The narrative meeting protocol

Sixty minutes. Twenty minutes of silent reading, everyone in the room, no assumed pre-reads. Thirty-five minutes of discussion, working through the document section by section, hardest internal FAQ questions first. Five minutes for an explicit decision: fund it, kill it, or revise it with a named owner and a return date. The meeting fails if it ends without one of those three words being said out loud.

The silent reading feels strange the first time and then becomes the part people defend hardest. It puts the whole room on the same evidence before the loudest voice frames the conversation.

When not to use it

An honest section, because the format gets abused. Do not write a PR/FAQ for small iterations, pure tech debt, compliance work, or anything reversible in under a week. Those are two-way doors; walk through them. The PR/FAQ is for bets that consume a quarter or close a door. Teams that mandate it for everything teach themselves to skim it, and then it stops working where it matters. The right volume for most teams is a handful per quarter, which pairs naturally with keeping an anti-backlog of the bets you declined.

How to use it this week

Pick the biggest bet currently heading toward your roadmap on the strength of a deck or a Slack consensus. Block three hours. Write the press release page first, and do not let yourself touch the FAQ until the opening paragraph passes the lean-in test.

Then write the internal FAQ, starting with the question you least want to answer. That is usually unit economics or "why now."

Send it to two colleagues with the meeting protocol attached. Run the 60 minutes. Walk out with fund, kill, or revise.

If the press release was easy to write, you probably have a real bet. If it fought you the whole way, the format just did its job, and it cost you an afternoon instead of a quarter.

Sources: Bryar & Carr, Working Backwards (the PR/FAQ format and narrative meeting practice at Amazon), Gary Klein on the premortem, HBR.