Working Backwards: Amazon's PR/FAQ Method for New Products

Created by Amazon - https://www.aboutamazon.com/news/workplace/an-insider-look-at-amazons-culture-and-processes

Overview

Working Backwards is the process Amazon uses to decide which product ideas deserve to be built. Colin Bryar and Bill Carr, two former Amazon executives, define it this way in their book: "Working Backwards is a systematic way to vet ideas and create new products." Its key tenet, they write, is to start by defining the customer experience and then work backwards from it, draft after draft, until the team is clear about what to build (Amazon's excerpt from the book). The main tool is the PR/FAQ: a mock press release that announces the finished product, followed by a set of frequently asked questions.

Bryar and Carr write that most of Amazon's major products and initiatives since 2004 were created through Working Backwards, which is why they used the name as the title of their book (book excerpt on About Amazon). On their own site they describe how the format was found. In 2005, while working on new digital media and web services businesses, they first tried SWOT analysis, market sizing and pro forma P&L statements, then mock-ups and long documents, and "through trial and error (and Jeff's insight)" settled on a press release and FAQs (Working Backwards PR/FAQ instructions). Bryar was chief of staff to Jeff Bezos for two of his years at Amazon, and Carr was the vice president who launched Amazon Music and Prime Video (about the authors).

The press release comes first on purpose. Usually a press release is the last step in launching a product. Written at the start, it keeps the author away from competitors, current capabilities and the P&L, and on the reader who might buy the product. The authors put it plainly: "Writing a press release is a forcing function to ensure that the creator of the new product idea is focused on the customer." (PR/FAQ instructions) Executives reviewing a press release often ask "so what?", and if the product it describes is not meaningfully better (faster, easier, cheaper) than what is already out there, the authors say it is not worth building (book excerpt).

The PR/FAQ belongs to Amazon's wider habit of writing instead of presenting. In a 2004 email to his senior team, reported by Business Insider, Bezos ended PowerPoint presentations at those meetings and wrote that "If someone builds a list of bullet points in word, that would be just as bad as powerpoint." His 2017 shareholder letter describes narratively structured six-page memos that are read silently at the start of each meeting, in what he calls a kind of study hall. Bryar and Carr list the PR/FAQ as one type of these narratives (Narratives and Decision Making).

The format has limits. The press release is a few paragraphs, always less than one page, and the FAQ should be five pages or less. The authors call the length limit a forcing function that develops better thinkers and communicators. The author, usually the person who had the idea, circulates a draft in a one-hour meeting where everyone reads it to themselves before discussing it. The authors say it is not unusual for a team to write ten drafts or more and to meet senior leaders five times or more (book excerpt).

Most PR/FAQs never become products. Bryar and Carr say that during their time at Amazon most of them never reached launch, and they treat that as a strength of the process: deciding on paper which products not to build keeps engineering capacity for the ideas with the highest impact (book excerpt). They describe good product development as a funnel that takes in many ideas and narrows them, and they say a first draft should take only a few hours, which keeps writing many PR/FAQs affordable (PR/FAQ instructions).

Working Backwards decides what to build, and it leaves the building method open. The authors write that Amazon frequently used Agile together with the PR/FAQ process once a PR/FAQ was approved (PR/FAQ instructions). For a product manager, the method gives the least structured phase of the job, the time before anyone commits, a concrete document that stakeholders can read, question and approve or reject.

Core Principles

Start from the customer and work backwards

Amazon's first Leadership Principle, Customer Obsession, opens with "Leaders start with the customer and work backwards" (Amazon Leadership Principles). Bryar and Carr contrast this with the usual skills-forward approach, where a company looks for ideas that fit the business model and capabilities it already has (PR/FAQ instructions). Their example is the Kindle: a device plus a digital media service, two areas where Amazon had no prior capability. Starting from the customer lets the team see which capabilities it would have to build or buy, instead of limiting the idea to what it can already do.

Write the argument in full prose

The PR/FAQ is a narrative. Bezos's 2004 email argued that the narrative structure of a good memo "forces better thought and better understanding of what's more important than what" (Business Insider). Bullet points let a reader agree with a phrase while imagining different things. Full sentences force the author to say who the customer is, what changes for them and why it matters, and gaps in the logic show up on the page.

Keep the document short

Length limits are part of the method. The press release stays under one page and the FAQ at five pages or less, because the goal is to share distilled thinking instead of all the work that went into it (book excerpt). Long documents let the author avoid deciding what matters and hand that decision to the readers. A short limit forces the author to make it.

Name a specific customer and a meaningful improvement

The subheading of the press release names the customer, and the template's instructions are blunt: "If you think your product is for everyone, you are mistaken." The problem paragraph is written from the customer's point of view, and the solution must say how the product is meaningfully different from what that customer uses today (PR/FAQ instructions). If the product solves the same problem in roughly the same way as existing products, the authors say to go back to the drawing board.

Use the FAQ to face the hard problems

The external FAQ answers what customers and the press would ask. The internal FAQ anticipates questions from finance, marketing, support, operations and other departments, and covers the technical, financial, legal and operational problems that must be solved (PR/FAQ instructions). The authors want an FAQ that is "optimistic but also realistic" and states the conditions under which the product would succeed or fail. The FAQ is where an attractive press release meets the cost of delivering it.

Review to find the truth

Bryar and Carr describe PR/FAQ meetings as truth-seeking and improving, and they warn against treating them as a pitch for approval (PR/FAQ instructions). Reviewers read first, then comment line by line, and "The most senior attendees tend to speak last, to avoid influencing others" (book excerpt). An author who tries to sell the idea hides the weak points that the review exists to find.

Expect most ideas to stop on paper

A funnel of many cheap drafts only works if most drafts are allowed to stop. The authors list several reasons a PR/FAQ may not be approved: the idea copies existing products, the market is too small, the investment is too risky, or a problem in the FAQ has no solution yet (PR/FAQ instructions). A rejected PR/FAQ is still useful, because it records why the idea stopped and what would have to change for it to come back.

How the Process Took Shape

The sources below give the dates for the practices that make up Working Backwards. They describe related practices that grew up together, and none of them names a single first PR/FAQ or its author.

Two versions of the process appear in these sources. Vogels's 2006 post describes a longer sequence that continues past the FAQ to a detailed customer experience (screen mock-ups, or use cases with code snippets for web services) and a user manual, with the aim of reaching "the minimum set of technology requirements" (Vogels, Working Backwards). The version in the 2021 book centers on the PR/FAQ itself, with fixed length limits and a defined review meeting (book excerpt). The skills for this method use both: the PR/FAQ for the decision, and the customer experience and requirements steps for turning an approved PR/FAQ into a build plan.

Steps

1. Pick the customer and the problem Write down one specific customer segment and the problem that segment has today, in the customer's own terms. The template's example contrasts urban single professionals with suburban families who carpool, because the two want very different cars. Check that the problem matters enough that customers would pay to solve it, since the authors say a problem with too few customers or no willingness to pay is not worth solving. Gather evidence from support tickets, sales calls, reviews and interviews before you draft. You are done when a colleague could tell whether a given person is in the segment.

2. Draft the press release Write the heading, subheading, summary paragraph, problem paragraph, solution paragraph, a quote from a company spokesperson, a quote from a hypothetical customer, and a short getting-started paragraph. Keep it under one page and in plain language a customer would understand. Describe the experience and the benefit before any technology. Say what customers use today and why the new product is meaningfully better. Expect the first draft to be rough; the authors say it should take only a few hours.

3. Write the external FAQ List the questions a customer or journalist would ask after reading the release: price, how it works, where to buy it, how to get help, what happens in edge cases. Answer each one in the same plain language as the release. Where you do not know the answer, say so and mark it as open. An external FAQ is complete when a skeptical customer would have no major question left unanswered.

4. Write the internal FAQ Anticipate the questions leaders and other departments will ask. Cover who has the problem and how many of them there are, the competition, unit economics, the upfront investment, dependencies on partners, legal and regulatory issues, and the hard problems in engineering or operations. Include the question the authors' own list ends with: what are the top three reasons this product will not succeed. Back answers with evidence or reasoning instead of assertions.

5. Review with a small group Share the draft first with your manager and a few cross-functional peers, then hold a review meeting. Open with silent reading, collect written comments in the document, then go through the questions page by page. Ask the most senior person to speak last. Take notes on every point raised and send minutes afterwards.

6. Revise and escalate Rewrite the PR/FAQ to answer the strongest critiques, even when they change the customer, the benefit or the scope. Hold further reviews until the small group's decision maker is satisfied, then take the document to the executives who can fund it. Expect several drafts and several meetings for any idea under serious consideration. Stop revising when reviews produce refinements and no new structural problems.

7. Decide go or no-go Make the decision from the document. If the answer is go, the FAQ should already describe the people, money and rough timeline needed, and the PR/FAQ stays a living document that the team keeps editing as the project changes. If the answer is no, record the reason: not differentiated, market too small, investment too risky, an unsolved problem, or simply lower priority than the backlog. Keep the document so the idea can return when the reason no longer holds.

When to Use

• A team has several possible directions and no shared view of which one serves customers best. Writing a PR/FAQ for each turns a debate about strategy into a comparison of concrete documents.
• You are proposing a new product or a new market where there is no usage data to lean on. The PR/FAQ makes you reason explicitly about the customer and the economics before any data exists.
• Ideas in your organization tend to start from a technology or a capability looking for a use. The press release forces the conversation back to who the customer is and what changes for them.
• The initiative needs investment from several functions, such as engineering, legal, operations and marketing. The internal FAQ gives every function a place to raise its concerns before resources are committed.
• You need a funding decision from senior leaders who will want to see the customer case, the risks and the costs in one place.

When Not to Use

• The problem and the solution are both well understood and the work is execution, such as a bug fix or a small, clearly requested improvement. A full PR/FAQ adds process without adding insight.
• You cannot yet describe the customer or the problem credibly. Talk to customers or run small experiments first, then write the PR/FAQ once you have something real to say.
• Leaders will approve or reject ideas regardless of what the document says. Without a real chance of stopping an idea, the reviews become theatre and people stop writing honest FAQs.
• The decision is cheap to reverse. Bezos describes many decisions as reversible two-way doors that can use a light-weight process (2016 letter), and a quick test may answer the question faster than a document.