The PR/FAQ process as Amazon actually runs it — from the insiders who ran it — and why a one-page fake press release is the cheapest product experiment you'll ever ship.
The theory in one paragraph
Most product processes start from what's buildable and argue toward the customer; Amazon institutionalized the reverse. Before any significant product gets resources, someone writes the press release announcing its launch — in plain language a real customer would care about — plus an FAQ answering the hardest questions from customers, press, and internal skeptics. The document is fiction, and that's the point: fiction is cheap to revise and cheap to kill. If the press release isn't exciting, the product won't be either, and you've discovered it for the cost of a few pages instead of a few quarters. Bryar and Carr's book pairs the PR/FAQ with its supporting cast — six-page narratives instead of slides, because prose exposes reasoning that bullet points let you skip.
The mechanics — as Colin Bryar defined them, not the folklore version.
Heading, subheading, the problem, how the product solves it, a quote from the (imaginary) team, a quote from a (imaginary but plausible) customer, and how to get started. Written in a customer's vocabulary — no internal jargon, no technology worship. The discipline is the constraint: if the benefit needs three paragraphs, it isn't sharp enough to build yet.
External questions first (what does it cost, why trust you, what about my data), then internal ones (unit economics, dependencies, what we're explicitly not building, why now). The FAQ is deliberately the longer document — it's where the writers argue with themselves in public, and where reviewers' hardest questions get folded back in with each revision.
The PR/FAQ is read, not presented: meetings start with everyone reading the six pages in silence, then interrogating them. Prose can't hide a missing causal link the way a bullet point can, and silent reading means the idea competes without the author's charisma or seniority attached. Iterate, shelve, or fund — most PR/FAQs die, which is the system working.
The fake press release is a validation instrument
It's tempting to file Working Backwards under writing culture; it's actually the cheapest experiment in the lean toolbox. A landing-page test costs a build and traffic; a PR/FAQ costs an afternoon and forces the same confession — who is this for, what changes for them, why would they switch, why now. Teams that can't write an exciting press release haven't found a product worth testing yet, and learning that from paper is the entire return on the method. The quiet radicalism: at Amazon, the document's approval IS the product decision.
Amazon executives of the building years — Bezos's chief of staff and the VP of digital media
Bryar spent two years as Jeff Bezos's technical advisor — the 'shadow' role that sits in every meeting — while Carr built Amazon's digital media businesses through the launches of Prime Video and Kindle-era bets. Working Backwards is the rare operating book written by the people who ran the mechanism daily rather than observed it; its subtitle promise, 'insights, stories, and secrets', is mostly mechanism — the processes that made customer obsession a procedure instead of a poster.
Each step maps to a field in the Product Description tool — finishing the read means finishing the work.
One page, future-dated, customer language only. Force the customer quote to say something a real person would actually say about a real improvement in their week — that quote is where weak ideas go to be exposed.
Product Description · description & benefitsTen questions minimum: five from customers and press (price, trust, switching cost), five from your own skeptics (economics, dependencies, why us, why now, what we're not building). Answer honestly or mark 'unknown' — an unknown in the FAQ is a research task, not a failure.
Product Description · target user & use casesGive reviewers the document and twenty silent minutes before any discussion. Collect the questions you couldn't answer — they are the document's real output.
Two or three passes usually settle it: either the press release becomes something the room would genuinely want announced, or it doesn't — and a shelved PR/FAQ that cost three afternoons is the process succeeding, not failing.
If funded, the PR/FAQ becomes the fixed point: scope debates resolve by rereading what launch day promised the customer. Update it deliberately when reality forces changes — silent drift between the document and the build is how 'working backwards' degrades into ordinary working forwards.
Feeds your Readiness Score · PlanThe steps above are the Product Description tool's structure. Open it and work through them with your own startup — your readiness score starts building from the first field.
Free account · no card required
Teardowns from our benchmarks library where this framework is doing real work.
Benchmark teardown
Amazon
The origin: Prime, Kindle, and AWS all began life as press releases arguing with FAQs
Read the teardown
Benchmark teardown
Stripe
Working backwards from the developer's first five minutes — seven lines of code was a launch-day promise kept
Read the teardown
Benchmark teardown
Careem
Super-app expansion is PR/FAQ territory: every new vertical needs a launch story a Cairo or Riyadh customer would actually care about
Read the teardown
It's Amazon's discipline of starting product development from the customer announcement rather than the technology: before building, teams write a one-page mock press release announcing the finished product plus an FAQ answering the hardest customer and internal questions. The document is debated and revised until the idea is either compelling or shelved — cheaply, on paper.
A press release (heading, problem, solution, quotes, call to action — one page, customer language) stapled to a frequently-asked-questions section that stress-tests the idea: pricing, trust, unit economics, dependencies, and what's deliberately out of scope. The PR sells the dream; the FAQ interrogates it. Together they're Amazon's standard artifact for deciding what gets built.
Because prose exposes reasoning that bullets conceal: a narrative forces complete sentences, explicit causality, and answers to questions a slide can gesture past. Meetings begin with silent reading so the document is judged on its logic rather than the presenter's charisma or seniority — the idea has to survive on paper alone.
Date it at launch, name the customer and their problem in the first two sentences, describe what they can now do in their own vocabulary, add a customer quote that a real person could plausibly say, and end with how to get started. Strike every internal term and technology boast; if the excitement doesn't survive plain language, the product needs rethinking before it needs engineers.
Arguably more useful for startups: it's a validation experiment that costs an afternoon, needs no code, and forces the founding team to agree in writing on customer, problem, and promise before burning months. Many venture-backed teams now require a PR/FAQ before any major feature — the shelved documents are the cheapest failures they'll ever have.
Jobs to be Done
Clayton Christensen · 2003
The Lean Startup
Eric Ries · 2011
Positioning (Obviously Awesome)
April Dunford · 2019
Sources
Independent educational summary written by StartupKit from public sources. Working Backwards (PR/FAQ) is the work of Colin Bryar & Bill Carr; this page is not affiliated with or endorsed by the author.