Most product teams build forward. They start with an idea, sketch some features, build a prototype, and then try to figure out who wants it and why. The Amazon working backwards method flips that sequence entirely. You start by writing a press release for a product that does not exist yet, and if you cannot make the press release compelling, the product is not worth building.
This is not theory. Amazon used this process to develop Kindle, Prime, AWS, and Alexa. Colin Bryar and Bill Carr, two former Amazon VPs with 27 combined years at the company, documented it in their book Working Backwards: Insights, Stories, and Secrets from Inside Amazon. The method has since spread to product teams at startups and enterprises worldwide because it solves a problem every PM faces: building something nobody actually needs.
Here is how the process works, what a real PR/FAQ document looks like, and how to adapt it for your own team.
Table of contents
- What is the Amazon working backwards method?
- How the PR/FAQ document works
- The press release: structure and example
- The FAQ section: internal and external questions
- Why this method works better than a feature spec
- How to run a working backwards session with your team
- Common mistakes teams make with PR/FAQs
- Frequently asked questions
What is the Amazon working backwards method?
The Amazon working backwards method requires product teams to write a mock press release and FAQ document before any design, engineering, or roadmap work begins. The press release describes the finished product as if it has already launched successfully. The FAQ addresses both customer questions and internal business questions.
The core idea traces back to Amazon’s Leadership Principle of “Customer Obsession.” Instead of starting with what the company can build or what technology is available, teams start with the customer experience they want to deliver and then figure out what needs to be true to make that experience real.
At Amazon, every new product initiative, from a small feature to an entirely new service, requires a PR/FAQ before it receives funding or engineering resources. The document goes through multiple rounds of review. Senior leaders read it, challenge assumptions, and send it back for revision. Most PR/FAQs get rejected or significantly reworked before approval, and that is the point: it is far cheaper to iterate on a one page document than to rebuild a product after six months of development.
How the PR/FAQ document works
The PR/FAQ is a narrative document, not a slide deck. Amazon banned PowerPoint in meetings years ago in favor of written narratives because writing forces precision that bullet points allow you to skip.
A complete PR/FAQ has two parts:
Part 1: The press release. One page maximum. Written in plain language that a customer would understand. No jargon, no internal acronyms, no technical architecture details.
Part 2: The FAQ. Typically two to five pages. Split into external FAQs (questions customers would ask) and internal FAQs (questions executives and stakeholders would ask about feasibility, costs, risks, and metrics).
The document is read silently at the start of the review meeting. Everyone reads the same document at the same time, in the room. Then the discussion begins. This “study hall” format ensures everyone has the same context before providing feedback.
The press release: structure and example
A working backwards press release follows a specific structure. Every element is intentional.
Headline. One sentence that names the product and states the primary customer benefit. Example: “Amazon announces Kindle, a wireless reading device that lets you download any book in 60 seconds.”
Subheadline. One sentence that specifies the target customer and the key differentiator.
Date and location. Treat it as a real press release.
Opening paragraph. Summarize the product, who it is for, and why it matters in three to four sentences. The focus keyword “amazon working backwards” should feel natural here because you are describing what the method produces.
Problem paragraph. Describe the customer problem in concrete terms. Use specific scenarios, not abstract pain points. “Readers who travel frequently carry three to four books in their bag, adding weight and bulk” is better than “customers want convenience.”
Solution paragraph. Explain how the product solves the problem. Stay at the experience level, not the implementation level. The customer does not care about your microservices architecture.
Quote from a company leader. A fictional quote that captures the vision and ambition. This forces someone on the team to articulate, in a single paragraph, why this product matters to the company.
How it works. A brief walkthrough of the customer journey from discovery to first use.
Customer quote. A fictional quote from a target customer describing how the product changed their experience. This is harder than it sounds because you have to imagine the emotional payoff, not just the functional benefit.
Call to action. One sentence telling the reader what to do next.
What a strong press release looks like in practice
Landon, a senior PM at a B2B SaaS company, used the working backwards method to pitch an onboarding automation feature. His first draft described the feature set: automated emails, in-app tours, progress tracking. His VP sent it back with one note: “I cannot tell who this is for or why they would care.”
The second draft started differently. The headline read: “New customers complete setup in 20 minutes instead of three days.” The problem paragraph described a specific scenario: a customer success manager spending 45 minutes on every onboarding call walking new users through the same twelve steps. The solution paragraph described the experience from the new user’s perspective, not the feature list.
That second draft got approved in one review cycle. The difference was not the product idea; it was the clarity of the customer problem and the specificity of the benefit.
The FAQ section: internal and external questions
The FAQ section is where most of the analytical work lives. It is divided into two categories.
External FAQs (customer perspective)
These are questions a real customer would ask after reading the press release:
- How much does it cost?
- Does it work with the tools I already use?
- What happens to my existing data?
- How long does setup take?
- What if I need help?
The answers should be specific. “Competitive pricing” is not an answer. “$29 per month for teams under 50 users” is an answer.
Internal FAQs (business perspective)
These are the hard questions your leadership team, finance team, and engineering team will ask:
- What is the total addressable market?
- What does the revenue model look like at 1, 3, and 5 years?
- What engineering resources does this require and for how long?
- What are the biggest technical risks?
- How does this affect our existing product lines?
- What does the competitive landscape look like?
- What metrics will we use to determine if this is successful?
The internal FAQ is where PR/FAQs most often fall apart. Teams write optimistic press releases and then cannot answer the business questions. That gap is precisely the signal that more work is needed before committing resources.
Why this method works better than a feature spec
Traditional product development often starts with a PRD or feature spec. The problem is that feature specs describe what gets built, not why it matters to a customer. Teams can align on a feature list while having completely different assumptions about who will use it and what problem it solves.
The working backwards method forces alignment on three things before any specification work begins:
1. Customer clarity. You cannot write a compelling press release without knowing exactly who the customer is and what they struggle with today. Vague personas (“busy professionals”) get exposed immediately because they produce vague press releases.
2. Benefit specificity. The press release demands a concrete, measurable benefit. Not “improved efficiency” but “reduces report generation from four hours to fifteen minutes.” This specificity forces the team to commit to an outcome.
3. Viability testing. Writing the press release is an inexpensive gut check. If the team cannot make the product sound exciting in a one page document, it is unlikely to be exciting in the market. As Bryar and Carr note, the fact that most PR/FAQs get rejected is a feature of the process, not a bug. It preserves resources for ideas that survive scrutiny.
This is also why the method pairs well with assumption mapping. The press release reveals what you are claiming; assumption mapping reveals what you need to prove.
How to run a working backwards session with your team
You do not need to work at Amazon to use this method. Here is a practical approach for any product team.
Step 1: Write the first draft alone. The PM (or whoever is championing the idea) writes the press release and FAQ in isolation. Group writing produces watered down documents. One voice, one draft.
Step 2: Silent review. Share the document with 3 to 5 stakeholders. Give them 20 minutes to read and annotate in silence. No discussion until everyone has finished reading.
Step 3: Structured feedback. Go section by section. Start with the headline and opening paragraph. The most common feedback at this stage is “I do not understand who this is for” or “the benefit is not specific enough.” Both are exactly the kind of feedback you want before you have written a single line of code.
Step 4: Revise and resubmit. Most PR/FAQs need two to four revision cycles. Each revision should sharpen the customer problem, make the benefit more specific, and address gaps in the FAQ.
Step 5: Make the go/no-go decision. Once the PR/FAQ is clear, compelling, and the FAQ answers hold up to scrutiny, the team has enough alignment to proceed to roadmap planning and technical specification.
Time investment
A typical PR/FAQ takes 5 to 15 hours of writing and revision spread over one to three weeks. That might sound like a lot until you compare it to the cost of building the wrong product for three to six months. The Research & Technology Management journal published a case study examining Amazon’s working backwards approach as a framework for corporate innovation, finding that the narrative driven process significantly improved decision quality at the early stages of product development.
Common mistakes teams make with PR/FAQs
Writing it as an internal memo. The press release should be written for a customer, not for your boss. If it reads like a business case, start over.
Being vague about the customer. “Small businesses” is not specific enough. “Operations managers at e-commerce companies with 10 to 50 employees who currently track inventory in spreadsheets” is a customer you can build for.
Skipping the FAQ. The press release is the easy part. The FAQ is where the rigor lives. Teams that write a strong press release and a thin FAQ are fooling themselves about readiness.
Treating it as a one-time exercise. The PR/FAQ should be a living document that gets updated as you learn more through product discovery. The original vision may shift as customer research reveals new information.
Making the benefit aspirational instead of specific. “Transforming the way teams collaborate” is a red flag. “Reducing meeting time by 40% for distributed engineering teams” is a testable claim.
Frequently asked questions
What is the Amazon working backwards method?
The Amazon working backwards method is a product development process where teams write a mock press release and FAQ for a product before building it. The press release describes the finished product as if it has already launched, forcing teams to clarify the customer, the problem, and the specific benefit before any engineering work begins.
What is the difference between a PR/FAQ and a PRD?
A PR/FAQ focuses on the customer experience and the “why” behind a product, written as a one page press release plus FAQ. A PRD (product requirements document) focuses on what gets built, including features, user stories, and technical requirements. The PR/FAQ comes first to establish alignment on customer value; the PRD comes after to guide implementation.
Can you use the working backwards method outside of Amazon?
Yes. The working backwards method is non-proprietary and has been adopted by product teams at startups and enterprises across industries. You do not need Amazon’s scale or culture to use it. Any team that struggles with alignment on what to build and why can benefit from writing a PR/FAQ before committing development resources.
How long does it take to write a good PR/FAQ?
A strong PR/FAQ typically takes 5 to 15 hours of writing and revision over one to three weeks. The press release itself may only take a few hours, but the internal FAQ section, which addresses business model questions, technical risks, and go-to-market strategy, requires more research and iteration.
What is the Amazon PRFAQ format?
The Amazon PRFAQ consists of two sections: a one page press release (headline, subheadline, customer problem, solution, company quote, customer quote, and call to action) and a multi-page FAQ split into external questions (from the customer perspective) and internal questions (covering business viability, costs, risks, metrics, and competitive landscape).