Working Backwards: How to Write an Amazon PR/FAQ (Template & Guide)

Working Backwards is Amazon's product-development method for starting with the customer and the finished experience, then working backwards to what you need to build. Its central artifact is the PR/FAQ — a Press Release and Frequently Asked Questions document written before any code, as if the product had already launched. If the press release does not excite a customer, the idea is reworked or killed before a single engineer is assigned. This guide explains how Working Backwards and the PR/FAQ work, how to write one, the mistakes that sink them, and — critically — how to validate the customer assumptions inside your PR/FAQ with real interviews using Koji.

What is Working Backwards?

Working Backwards is a systematic way to vet ideas: you begin by defining the ideal customer experience, then iterate backwards from that point until the team has clarity on what to build. Most of Amazon's major products and initiatives since 2004 — including the Kindle, Amazon Prime, and Amazon Web Services — were created through this process (Working Backwards).

The method was popularized by two long-serving Amazon executives, Colin Bryar and Bill Carr, in their book Working Backwards. As they describe it, the PR/FAQ process "reinforces customer obsession, starting with customer needs and working backwards from there." Instead of starting with a technology or a feature and hunting for a market, you start with the customer problem and let it dictate the solution.

What is a PR/FAQ?

The PR/FAQ is a short narrative document — typically around six pages — with two parts:

The Press Release (PR)

A one-page mock press release written from a future date, announcing the launched product as if it already exists. It is written in plain, customer-facing language — no jargon, no internal acronyms — and answers: Who is the customer? What problem does this solve? Why is the solution remarkable? A useful litmus test: if this press release would not make a customer want the product, the idea needs to be rewritten before anything else happens.

A strong press release usually includes a headline, a subheading naming the target customer and benefit, the customer problem, the solution, a quote from a company leader, a description of how the product works, a customer quote, and a call to action.

The Frequently Asked Questions (FAQ)

The FAQ anticipates the hard questions, split into two groups:

• Customer/external FAQs — what a customer or journalist would ask: How much does it cost? How is it different from alternatives? How do I get started?
• Internal/stakeholder FAQs — the hard business and technical questions: How big is the opportunity? What is the unit economics? What are the biggest risks? What do we need to believe for this to work?

The FAQ is where the rigor lives. It forces the team to confront the assumptions and risks they would otherwise discover only after launch.

Why Working Backwards works

The method is a forcing function for clarity and customer focus. As the Amazon team puts it, "iterating on a press release is a lot less expensive than iterating on the product itself." A few key principles make it powerful:

• It surfaces weak ideas early. It is not unusual for an Amazon team to write ten or more drafts of a PR/FAQ and meet with senior leaders five times or more to debate and refine an idea — sometimes over months — before approving the team and beginning production (Working Backwards).
• Killing ideas is a feature, not a bug. Most PR/FAQs never get approved. Deciding not to build something — without spending engineering resources to find out — preserves the company's most precious resource.
• Writing beats slides. A narrative document forces complete, logical thinking in a way a slide deck never can. Gaps in reasoning have nowhere to hide in prose.

This matters because the cost of building the wrong thing is enormous. In CB Insights' analysis of why startups fail, "no market need" is one of the top reasons, cited by roughly 35% of failed startups (CB Insights). And by various industry estimates, a large majority of new products underperform or fail outright — MIT reports figures as high as 95% for new products that "miss the mark" (MIT Professional Education). A PR/FAQ is a cheap way to fail on paper instead of in the market.

How to write a PR/FAQ: step by step

1. Pick the customer and the problem. Name one specific customer and the single most important problem you are solving for them. Vague targets produce vague products.
2. Write the press release first. Draft the one-page PR from a future launch date. Lead with the customer benefit, not the feature. Keep it jargon-free.
3. Draft the customer FAQs. Answer what a real customer would ask — price, differentiation, how to start.
4. Draft the internal FAQs. Confront the uncomfortable questions: market size, economics, risks, and the assumptions the whole idea rests on.
5. List your assumptions explicitly. Every PR/FAQ rests on beliefs about what customers want, what they will pay, and how they behave. Write them down as testable claims.
6. Circulate, debate, and iterate. Share the document, gather hard questions, and rewrite. Expect many drafts. The goal is to strengthen — or kill — the idea on paper.

The hidden risk: your PR/FAQ is full of assumptions

Here is the trap most teams fall into. A PR/FAQ reads as confident and finished — the customer quote, the benefit, the "why customers love it." But every one of those statements is a hypothesis about how real customers will react. The customer quote is invented. The claimed benefit is assumed. The willingness-to-pay number in the internal FAQ is a guess. A beautifully written PR/FAQ can be completely wrong about the customer, and its polish makes the error harder to see.

Amazon could absorb this risk because it had massive existing customer bases to learn from. Most teams do not. That is why the single highest-leverage thing you can do with a PR/FAQ is validate its customer assumptions with real customers before you build — and that is exactly where modern research tools change the game.

The modern approach: validate your PR/FAQ with Koji

Traditionally, validating the assumptions in a PR/FAQ meant weeks of recruiting and interviewing — long enough that teams skipped it and shipped on faith. AI-native platforms like Koji collapse that timeline so validation fits inside the drafting cycle, not after it.

With Koji you can take the core claims in your PR/FAQ — the problem, the promised benefit, the differentiation, the price — and test them with AI-moderated interviews (voice or text) that adapt their follow-up questions in real time, the way a skilled researcher would probe a vague answer. Hundreds of interviews run in parallel, around the clock, and each transcript is analyzed automatically: themes extracted, sentiment scored, and response quality rated on a 1–5 scale.

Koji's structured questions let one validation study cover every PR/FAQ assumption in a single pass, using all six question types:

• open_ended — "Tell me about the last time you faced [the problem]" (does the problem in your PR even exist?)
• scale — how severe is the pain, on a 1–5 scale?
• single_choice / multiple_choice — which alternatives do they use today?
• ranking — rank the benefits in your press release by what they value most
• yes_no — would they switch?

The output is direct evidence for or against the story in your press release — in days, not weeks. Compared with a legacy survey tool like SurveyMonkey, which can only ask preset questions and never probes a surprising answer, Koji conducts an actual conversation and tells you why customers react the way they do. The result: your PR/FAQ stops being a confident guess and becomes a customer-validated plan — and you do not need a research team to get there.

"The PR/FAQ reinforces customer obsession, starting with customer needs and working backwards from there." — Colin Bryar & Bill Carr, Working Backwards

Pairing the PR/FAQ method with fast customer validation closes the loop Amazon's principle implies: real customer obsession means checking the customer reaction, not just imagining it. From there, the validated narrative flows naturally into a PRD built from customer research.

Key takeaways

• Working Backwards starts with the customer and the finished experience, then works back to what to build.
• The PR/FAQ — a future-dated press release plus customer and internal FAQs — is the forcing function that surfaces weak ideas before any code is written.
• Most PR/FAQs should be killed on paper; that is the point.
• Every PR/FAQ is full of customer assumptions — validate them with real interviews before building.
• AI-moderated platforms like Koji let you validate a PR/FAQ in days, turning a confident guess into a customer-backed plan.

Related Resources

• Structured Questions: The 6 Question Types Every Study Needs
• Writing a PRD from Customer Research
• Customer Discovery Interviews
• Assumption Testing Guide
• Jobs to Be Done Framework
• Product Discovery Research Guide