Amazon's Working Backwards PR/FAQ Framework

Start with the customer and work backwards—harder than it sounds but a clear path to innovating and delighting customers—a useful working backwards tool: writing the press release and FAQ before you build the product.

Introduction

Most of Amazon's major products and initiatives since 2004 have one thing in common—they were created through a process called Working Backwards. It is so central to the company's success that we used it as the title for our book. Working Backwards is a systematic way to vet ideas and create new products. Its key tenet is to start by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build. Its principal tool is a second form of written narrative called the PR/FAQ, short for Press Release and Frequently Asked Questions.

Why Amazon Created the PR/FAQ Process

At Amazon, focusing on the customer is so central to the management mindset that it is the company's first Leadership Principle:

Customer Obsession. Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

The Working Backwards PR/FAQ process was created so that every leader at Amazon could stay focused on customers' needs while building and inventing new products. Start with the customer and work backwards…easy, right? In practice, it is much harder than it sounds. We encountered this firsthand in 2005 as we sought to create new digital media and web services businesses. The tools we initially applied to identify new business opportunities included S.W.O.T. analysis, gathering research on the expected market size and growth rate of each new business sector, drafting a pro forma P&L, etc. We applied all of these and more, but after a few meetings, we realized that none of these tools required us to think deeply enough about the needs of customers and how we could create something new and valuable for them.

We then tried other tools like mock-ups and lengthy documents describing each new product idea. Through a process of trial and error (and Jeff's insight), we eventually landed on the idea of writing a press release and a series of frequently asked questions (FAQs) to describe each new product. Normally, writing a press release is the last step in launching a new product. When writing the press release, you are laser-focused on describing your product so that when a potential customer reads about it in the press, they will be excited and compelled to buy it. You aren't focused on your competitors, current capabilities, P&L, business partners, or other considerations. Writing a press release is a forcing function to ensure that the creator of the new product idea is focused on the customer. Once you have written a compelling press release, you and your team can work backwards from there, using the FAQ process, to figure out how to bring your new product vision to market.

Press Release Components

Heading

Name the product so the reader (i.e., your target customers) will understand—one sentence under the title.

Subheading

Describe the customer for the product and what benefits they will gain from using it—one sentence underneath the Heading. Describing the customers precisely here is critical. If you think your product is for everyone, you are mistaken. Great products are tailored to the specific needs of a specific customer segment. For instance, If you are designing a new car, you need to decide whether your customer is: - a) urban, single professionals under 35 who live in apartments, or - b) suburban families, 35+ with dual incomes, 3 kids, a dog, and the need to carpool to soccer games

Carefully defining the customer segment you are serving is critical.

Summary Paragraph

Start with the city, media outlet, and your proposed launch date. Give a summary of the product and its benefits. The launch date should have meaning. That is, pick a date when you expect actually to launch this product. At first, this will be a rough estimate, but by the final draft, this will be the planned launch date.

Problem Paragraph

This is where you describe the problem(s) that your product is designed to solve. Make sure you write this paragraph from the customer's point of view. This sounds simple, but in practice, this requires a deep understanding of customer needs. Even if you understand their needs, there may be more than one problem that you could solve. Consider which problem(s) is most important to the customer. Not all problems are created equal. You must identify a problem with a large total addressable market (TAM). The market size is the number of customers who have this problem multiplied by how much each is willing to pay to solve it. The problem is not worth solving if there is either a small population of potential customers or customers aren't willing to pay the price to solve it.

Solution Paragraph(s)

Describe your product in detail and how it simply and easily solves the customer's problem. For more complex products, you may need more than one paragraph. This may seem obvious, but the solution needs to address the problem directly.

Key Requirements: 1. Direct Problem-Solution Fit - The solution must address the problem directly 2. Clear Detail - Must be described in sufficient detail to clarify how it addresses the problem 3. Competitive Differentiation - Must acknowledge competition and state meaningful differentiation

Your paragraph should include: "Today, customers with this problem use x, y, or z products to meet their needs. Those products fall short of solving x problem(s). Our product addresses these unmet needs in the following ways."

The solution(s) you describe here relative to competition is how your product is differentiated and creates value. If your proposed product solution solves the same problems in roughly the same ways as existing products, then you need to go back to the drawing board.

Quotes & Getting Started

Add one quote from you or your company's spokesperson and a second from a hypothetical customer describing the benefit of using your new product. Describe how easy it is to get started, and provide a link to your website where customers can get more information and get started.

The FAQ

A well-written PR defines a specific objective– a destination where there is a treasure. Think of the FAQ section as the map to that destination and a detailed description of the dragons you will need to slay along your journey. The questions you ask and the answers you provide explain what problems you need to solve and how your team proposes to solve them.

External FAQs

This is where you provide detailed answers to the questions that you can expect the press and customers to ask: - How does it work? - What is the warranty? - What is the return policy? - How do I install it?

These are relatively straightforward questions, but the details you provide in your answer matter a lot. As with the Press Release, the External FAQ is a dialogue with your customer addressing their most important issues using language they can understand (that is, no corporate jargon).

Internal FAQs

A well-written internal FAQ section anticipates the most important questions that senior leaders and stakeholders in the company will ask after reading the PR. Anticipate questions from every department in the company: finance, marketing, customer support, operations, HR, etc. Additionally, the internal FAQ should cover all the challenging problems that need to be solved to build the product, whether technical, financial, legal, or operational.

An excellent FAQ demonstrates mastery of every aspect of the product. It should be optimistic but also realistic. It should demonstrate that the authors aren't looking through rose-colored glasses and are in love with their ideas. Instead, it should include a data-based assessment of the potential market for the product, a firm grasp of what will be required to build it, the risks involved, and the conditions under which the product will succeed or fail.

The Process of Writing a PR/FAQ

One of the great things about the PR/FAQ process is that anyone can use it. Whether you are a college student, an entry-level employee at a big company, or a C-level executive, you don't need specialized design or coding skills, you just need to be able to write. The process is designed to be lightweight, enabling teams to develop many new product ideas. The first draft of a PR/FAQ should take only a few hours, not a few days.

Funnel vs. Tunnel Approach

A great product development process should be a funnel, not a tunnel: - Funnel - Accepts and considers many new product ideas at the onset, progressively eliminating lower-potential ideas and focusing on a short list of products with the most significant potential - Tunnel - Constrained at the outset, and all or nearly all new product ideas that enter the process are built and launched

Iterative Development Process

The best PR/FAQs are produced through an iterative process requiring discussion, debate, and collaboration with many stakeholders:

1. Solo Effort - Early drafts by product manager with many holes and questions
2. Research Phase - Fill in blanks through research and investigation
3. Peer Review - Seek feedback from manager and cross-functional peers
4. Small Group Review - Review with cross-functional team (~10 contributors)
5. Executive Review - Multiple drafts and review meetings with executives

You may need more than one PR/FAQ document for complicated projects. For example, Fulfillment By Amazon was developed using two PR/FAQs, one from a seller perspective and one from a buying perspective.

The PR/FAQ Review Meeting

A common misconception is that the goal of any PR/FAQ meeting is to "sell" the idea to the reviewers and for the decision maker to give it a thumbs up or thumbs down. This was not the case at Amazon, where we were focused more on truth-seeking vs. selling and improving vs. deciding.

Meeting Structure

1. Silent Reading (15-20 minutes) - Document circulated and read silently with note-taking
2. Discussion (40 minutes) - Open questions, debate, and discussion
3. Documentation - Authoring team takes detailed notes of conversation

Reviewer Evaluation Criteria

The reviewer's job is to evaluate objectively: 1. Is the customer clearly defined? 2. Is the problem clearly defined? 3. Does the proposed solution address the problem? 4. Would we expect customers to change their behavior to buy/use the solution? 5. Which dimension(s) is the new product better, cheaper, or faster than substitutes? 6. Is the TAM and the payback big enough? 7. What are the constraints or problems (business, resources, technical, legal) we will need to solve?

The Decision

At some point, a level of completion of the PR/FAQ document is reached, and a go/no-go decision can be made. If approved, what happens next should be well understood because it is described in the FAQs.

Possible Outcomes for Non-Approved PR/FAQs

1. Insufficient Differentiation - Solution is "copycat" or not sufficiently differentiated
2. Small TAM - Total addressable market is too small
3. Poor Risk/Return - High upfront investment with risky/low payoff
4. Technical Barriers - Product not viable due to unsolved problems
5. Prioritization - Good idea but needs to be prioritized against existing backlog

Implementation Example

The Phoenix 400 vs. Excel 850

Phoenix 400 (Bad Example): - Mid-size SUV, gasoline-powered, Jeep-like design, cloth interior, $65,000 - Problem: No elements relatively better/faster/cheaper than existing mid-sized SUVs - Issue: Started with company capabilities, worked backward

Excel 850 (Good Direction): - Zero-emission electric car, 850-mile range, 15-minute recharge, large SUV capacity, sports car handling, luxurious interior, $19,000 - Advantage: Meaningfully better/faster/cheaper than alternatives - Challenge: Requires solving multiple complex technical problems

The key is finding innovative solutions that make ambitious ideas possible in a near-term timeframe.

Watch Outs & Common Mistakes

Speed vs. Velocity

• Speed - Fast movement without direction
• Velocity - Speed with direction (vector)
• Lesson: Investing time upfront in planning enables faster execution later

Truth Seeking vs. Selling

Focus on understanding issues and alternatives rather than "winning" approval. Ask: - What needs to be true for this product to be successful? - What new, innovative, unique approach have we developed to address barriers?

Competitive Analysis

Don't discount competition or current solutions: - What solutions exist today for customers? - Is this solution compelling enough for people to switch? - Can we reasonably believe customers will change their behavior?

Customer Backwards, Not Skills Forward

• Wrong: Rely on current business model, skills, and capabilities
• Right: Start with customer needs and work backward to identify required capabilities

Standard FAQ Templates

External FAQs

• What is the price?
• How does it work?
• How do I get help/customer support?
• Where can I buy it?

Internal FAQs

• What products/solutions does the target customer use today?
• What problem(s) does this product solve for customers?
• How does this create value for customers?
• What/who are the current competitors?
• How large is the estimated consumer demand and TAM?
• What are the challenging problems that need to be solved?
• What new capabilities will we need to establish?
• What are the per-unit economics?
• How much upfront investment is required?
• What are the top three reasons this product will not succeed?

Key Takeaways

1. Customer Focus - Always start with the customer and work backwards
2. Iterative Process - Expect multiple drafts and extensive collaboration
3. Truth Seeking - Focus on understanding and improving, not selling
4. Comprehensive Planning - Address all aspects before building
5. Differentiation - Must be meaningfully better/faster/cheaper than alternatives
6. Market Validation - Ensure sufficient TAM and customer willingness to switch
7. Capability Building - Be willing to develop new capabilities for customer needs

This framework has been successfully used to develop major Amazon products including AWS, Kindle, and Prime Video.