Working Backwards
Working Backwards: Before building anything, write a press release announcing the finished product as if it were already launched β describing what it does, why customers love it, and how it solves their problem. If you can't write a compelling press release, you don't understand the product well enough to build it. Amazon uses this to force clarity on customer value before any engineering investment.
What Is Working Backwards?β
Working Backwards is Amazon's internal product development methodology, formalised during the early 2000s under Jeff Bezos. The core practice is the "PR/FAQ" β a mock press release and FAQ document written before any engineering begins.
The press release is written as if the product has already launched successfully. It describes: the customer and their problem, what the product does, how it makes their life better, and includes a customer quote. The FAQ anticipates the most important questions from customers and from internal stakeholders. Both documents are written in plain English β no jargon, no technical specifications.
The insight behind the methodology is that it forces the hard thinking early. Writing a compelling press release forces you to answer: Who exactly is the customer? What specific problem are they experiencing? Why does our solution actually solve it better than alternatives? What is the concrete, measurable improvement in their life or work? These questions are easy to defer when you're talking about requirements documents and architecture β but unavoidable when you're writing a customer-facing announcement.
Amazon has described this practice as "starting from the customer and working backwards to the technology," rather than the more common practice of starting with technology (what can we build?) and then finding a market (who might want this?). Both approaches can produce good products β but Working Backwards forces customer-centricity as a discipline, not just an aspiration.
Beyond Amazon, the general principle β defining the end state clearly before beginning the path to it β applies to any project where the desired outcome can be specified more precisely than the required process.
How It Worksβ
Step 1: Write the mock press release
β Headline: product name + what it does for the customer
β Summary: the problem, the solution, the primary benefit (1 paragraph)
β Problem section: the customer's current pain in their words
β Solution section: how your product solves it
β Customer quote: what a real customer would say if delighted
β Getting started: how easy is it to start?
Step 2: Write the internal FAQ
β Customer questions: the 5 most important things customers would ask
β Internal/stakeholder questions: commercial viability, technical feasibility,
operational requirements, risks
Step 3: Review and iterate
β Is the customer benefit compelling and specific?
β Is the problem real and significant?
β Could a real customer actually use this?
β Does the internal FAQ reveal fatal flaws?
Step 4: Use the PR/FAQ as the project brief
β The press release defines what success looks like
β Engineering, design, and marketing derive their requirements from it
β Revisit when scope creep tempts
Step 5: Evaluate: does the product at launch match the press release?
Three Real-World Examplesβ
Amazon Kindleβ
Before building the Kindle, Amazon wrote a press release describing how "every book ever printed in any language" would be available for download in 60 seconds on a device with a month-long battery life that fits in a pocket. The press release forced critical questions: What does 60-second downloads require technically (always-on connectivity β Amazon covered 3G costs)? What does a month of battery life require (E-ink display β much harder engineering)? What does "every book" require (publisher negotiations β years of relationship-building)?
The press release identified the most valuable customer outcome and then forced Amazon to figure out whether they could actually deliver it, and at what cost. Several features initially in the press release were cut when the FAQ revealed they were technically impossible at acceptable cost β better to cut them in a Word document than after months of engineering.
Internal Amazon Servicesβ
When Amazon teams launch internal services (like AWS components), the same PR/FAQ discipline applies. The team writes a press release as if the service is already being used by developers successfully, then uses this as a filter: would a developer actually read this and think "that solves my problem"? If the press release is boring, vague, or unconvincing, the product concept needs revision before investment.
This has produced an interesting secondary benefit: Amazon's internal products tend to be more customer-friendly than those of companies where products are designed by engineering teams for internal engineering consumers, because the press release discipline enforces thinking about the customer experience.
Startup Product Developmentβ
A startup building B2B analytics might draft: "Acme Analytics Cuts Monthly Reporting Time from 3 Hours to 15 Minutes for Finance Teams." The press release describes a finance manager who used to spend every month-end manually consolidating spreadsheets, now presses one button and shares a live dashboard with executives. A customer quote: "I used to dread month-end close. Now I look forward to showing the team our numbers in real time."
Writing this press release before any code surfaced several insights: "finance teams" is too broad β the specific persona matters; "15 minutes" is a specific, testable claim; "month-end close" is a trigger moment that shapes the product roadmap; and "live dashboard" implies a different architecture than "monthly report."
When to Use Itβ
β Working Backwards is valuable for:
- New product development where customer value is uncertain
- Feature prioritisation (does this feature appear in the press release?)
- Cross-functional alignment (everyone building toward the same customer outcome)
- Evaluating whether a project is worth pursuing
β Less essential for:
- Well-understood products with clear requirements
- Infrastructure or platform projects where there's no direct customer press release
- Very early-stage exploration (sometimes you need to build to learn what to build)
| Pairs well with | Why |
|---|---|
| First Principles | First principles defines what's possible; Working Backwards defines what's valuable |
| Jobs to Be Done | JTBD identifies the customer's real job; Working Backwards designs the product that does it |
| Pre-mortem | Pre-mortem asks what could go wrong; Working Backwards asks what perfect looks like |
| Minimum Viable Test | MVT tests the hypotheses embedded in the Working Backwards press release |
Common Misuses and Limitationsβ
Confusing the press release with the product spec. The press release describes customer outcomes; it doesn't specify technical requirements. The engineering team's job is to figure out how to make the press release true. Treating the press release as a spec sheet loses the customer-centricity that makes the method valuable.
Writing the press release for the engineering team, not the customer. Press releases written in technical language or focused on features rather than benefits defeat the purpose. The customer quote in a bad Working Backwards doc reads: "This API has 99.9% uptime." The customer quote in a good one reads: "I used to worry about our payment system going down on Black Friday. I don't anymore."
Skipping the FAQ. The FAQ is where the hard questions get asked: Is this technically feasible? How much will it cost? Who are the competitors? What would prevent adoption? Many bad ideas survive a plausible press release but fail the FAQ. Both halves are essential.
Using it only once at the start. Working Backwards is most valuable when the press release is revisited as the product evolves. Scope creep and feature additions should be evaluated: does this addition appear in the press release? Does it make the press release more compelling? If not, it's probably not worth doing.
Related Modelsβ
| Model | Relationship |
|---|---|
| First Principles | Working Backwards asks what the customer needs; First Principles asks how to build it |
| Regret Minimization | Working Backwards from the regret you'd feel if you didn't build the right thing |
| Pre-mortem | Pre-mortem uses the same "future retrospective" framing in the opposite direction |
| Jobs to Be Done | JTBD provides the customer insight that makes the Working Backwards press release accurate |
Frequently Asked Questionsβ
How long should a Working Backwards PR/FAQ document be?
Amazon enforces strict limits: the press release is one page maximum; the FAQ is typically 4β6 pages. The length constraint is deliberate β it forces clarity and prioritisation. If you can't describe the product's value in a one-page press release, you don't understand it well enough yet. Longer documents enable vague thinking to hide in volume.
Can Working Backwards be applied to internal tools, not just customer products?
Yes β and this is actually one of its most powerful applications. Amazon uses it for internal APIs, developer tools, and organisational initiatives. The "customer" in this context is the internal user: the engineer, the analyst, the operations team. Writing a press release from their perspective forces the same clarity about what problem you're solving and why your approach actually makes their work better.
What's the difference between Working Backwards and a Business Plan?
A business plan typically covers financial projections, market analysis, and competitive positioning β it's primarily a document to convince investors. Working Backwards focuses exclusively on customer value: what is the customer experience, and why will customers love it? Business plans can exist without deeply understanding the product; Working Backwards is specifically about product clarity. They're complementary: Working Backwards defines what you're building; a business plan defines why it's commercially viable.
Further Readingβ
- Bryar, C. & Carr, B. (2021). Working Backwards: Insights, Stories, and Secrets from Inside Amazon β the authoritative account
- Bezos, J. (1997β2020). Amazon shareholder letters β repeated articulation of Working Backwards philosophy
- Ries, E. (2011). The Lean Startup β complementary methodology for testing Working Backwards hypotheses
Apply with AIβ
π Write a Working Backwards press release with MindMax β
This page is part of the MindMax Mental Models Knowledge Base.