Working Backwards

Discovery

Planning

Strategy

Write the press release before coding. Amazon's method for starting from the ideal customer experience and working back to the solution.

Description

Working Backwards is a product development methodology created at Amazon in the early 2000s, formalized by Colin Bryar and Bill Carr in their book Working Backwards: Insights, Stories, and Secrets from Inside Amazon (2021), which reverses the traditional design process by starting from the ideal customer experience (materialized through a fictional press release and FAQ) before defining the product to build. Its purpose: to ensure that every product solves a real customer problem before a single line of code is written. The principle is radical: instead of starting from a technology or an idea and looking for a market, you begin by writing the press release for the finished product. This one-page document describes the customer problem, the proposed solution, the key benefits, and a fictional quote from a satisfied customer. If the press release does not make a reader say "I want that," the product does not deserve to be built. Werner Vogels (Amazon CTO) summed up the philosophy: "Start with the customer and work backwards." Working Backwards functions like an architect who draws the finished house before calculating the foundations: you define the living experience (the PR/FAQ), then work your way back to the technical plans. The internal FAQ that accompanies the press release anticipates stakeholder questions: "Why now?", "How is this different from the competition?", "What is the business model?" This PR/FAQ tandem forces a clarity of thought that traditional technical specifications do not demand. Amazon used this method to launch Kindle, AWS, Prime, and Alexa. Unlike the Lean Canvas (which models the business model) or the Product Vision Board (which synthesizes the vision), Working Backwards focuses on a single question: "Will the customer be excited about this product?" If the answer is unclear, the press release reveals it immediately.

Objectives

Define the vision
Understand users
Ensure strategic alignment

Used by

-Amazon (creator of the Working Backwards method, used to launch Kindle, AWS, Prime, and Alexa)
-Intuit (adopted Amazon's PR/FAQ process to frame its product innovations)

Advantages

Forces value proposition clarity before any investment. If the press release excites nobody, you save months of development on a product nobody wants.
Aligns all stakeholders on a shared vision. A 3 to 6 page PR/FAQ is readable by the engineer, marketer, CFO and CEO, eliminating divergent interpretations.
Anticipates objections from the start. The internal FAQ forces answering difficult questions (business model, competition, costs) before they arise mid-development.
Testable with real customers. You can show the press release to potential users and measure their reaction before writing a single line of code.

Limitations

Demanding writing process. Crafting a convincing PR/FAQ requires storytelling and synthesis skills that not all teams have. The 5 to 10 iterations at Amazon are not an exaggeration.
Less suited to incremental improvements. Writing a press release for a bug fix or minor UX optimization is disproportionate. Working Backwards is designed for new products or major innovations.
Risk of "great press release, bad product". A well-written PR/FAQ can mask technical or business flaws if the internal FAQ is not rigorous enough. Question quality determines process quality.
Requires a writing culture. At Amazon, the "six-page memo" culture supports Working Backwards. In organizations that favor slides and meetings, adoption requires cultural change.

How to apply Working Backwards

1
Identify the customer problem to solve
Before writing anything, clarify the problem. Who is the customer? What is their main pain point? How do they solve it today (and why is that solution insufficient)? If you cannot articulate the problem in 2 sentences, you are not ready to write the press release. Output: clearly formulated customer problem with identified target segment.
2
Write the fictional Press Release (1 page)
Write a one-page press release as if the product were launching today. Structure: catchy headline (the customer benefit, not the feature name), subtitle (one sentence about the problem solved), opening paragraph (the what and the why), context paragraph (the current problem), solution paragraph (how it works for the user), fictional executive quote ("We created X because..."), fictional customer quote ("Thanks to X, I can now..."), call-to-action. Output: a one-page press release written in customer language.
3
Write the Internal FAQ (2-5 pages)
The FAQ anticipates the questions that stakeholders, engineers, and customers will ask. Divide it into two parts: external FAQ (customer questions) and internal FAQ (business and technical questions). Examples of internal questions: "What is the market size?", "What are the technical dependencies?", "What is the estimated development cost?", "How do we measure success?". Be honest in your answers. If you don't know, write "to be validated". Output: a 2 to 5 page FAQ covering customer and internal questions.
4
Circulate the PR/FAQ for feedback
Send the PR/FAQ to key stakeholders: engineering, design, marketing, finance, leadership. Request written feedback before any meeting. The document must stand on its own: if a reader needs oral explanations to understand, the PR/FAQ is not clear enough. Allow 1 to 2 weeks of asynchronous feedback. Output: annotated PR/FAQ with stakeholder feedback.
5
Iterate on the PR/FAQ until convergence
The first draft is rarely the right one. Amazon often goes through 5 to 10 iterations before reaching a PR/FAQ that satisfies everyone. Each iteration refines the problem, clarifies the solution, and anticipates new objections. If the PR/FAQ does not converge after several iterations, perhaps the problem is not clear enough or the solution is not distinctive enough. Output: final PR/FAQ validated by leadership.
6
Create visual mockups (optional but recommended)
At Amazon, the PR/FAQ is often accompanied by visual mockups that illustrate the user experience described in the press release. These visuals are not technical wireframes but representations of what the customer will see. They make the PR/FAQ tangible and testable with real users. Output: 3 to 5 key screens illustrating the experience described in the PR.
7
Define the success metrics
Before launching development, define how you will know the product has succeeded. Which metrics will validate that the customer problem is solved? What is the success threshold at 6 months, 12 months? At Amazon, these metrics are integrated into the internal FAQ. Without success metrics, you cannot evaluate whether the product delivered on the press release's promise. Output: 3 to 5 success metrics with defined thresholds.
8
Launch development keeping the PR/FAQ as a compass
The PR/FAQ becomes the reference document throughout development. When a technical or product decision arises, return to the press release: "Does this decision bring us closer to or further from the customer experience described?" If a feature does not contribute to the PR promise, it does not deserve to be in the MVP. Output: development launched with the PR/FAQ as a permanent decision criterion.