The Working Backwards PR/FAQ Process
Start every new product from the customer's problem, written as a press release, before any constraint enters the room.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 95%
Working backwards inverts the normal product sequence: instead of starting from your revenue target, resources, and engineering constraints and working forward, you start from a specific customer and their quantified problem, define the solution that would delight them, and only then work backwards into the engineering, cost, and legal work required to deliver it. The mechanism that makes the concept repeatable is the PR/FAQ: an internal, fictional press release plus FAQ written before a line of code. It is the single deliverable Amazon used both to decide what to build and to compare competing ideas against each other.
Origin
Developed at Amazon during the 2003–2007 process-innovation window described by Bill Carr, driven by Jeff Bezos' insistence on turning the 'customer obsession' leadership principle into a scalable, repeatable process. Carr and co-author Colin Bryar codified it in the book Working Backwards; templates are published at workingbackwards.com. Carr is explicit that Amazon 'stood on other people's shoulders' for most of its processes.
Core principles
- 01Customer needs are the only legitimate starting point — never revenue, active users, or cost structure.
- 02Write with zero constraints first; constraints are what the backwards journey resolves, not what it starts from.
- 03It is not a real press release — it is an internal, data-rich, hyperbole-free customer problem/solution statement.
- 04Cost reduction only counts as customer benefit if it is passed through as lower prices; otherwise it is just margin.
- 05The document is a decision tool, not an answer — it does not guarantee the product will work.
How to run it
- 1
Name the customer with painful specificity
Define exactly who the customer is. 'All restaurants' is a failure state — say which kinds of restaurants, in which cities, in which formats. This is the hardest paragraph in the document and most drafts die here.
Pro tip If you cannot narrow the customer without losing the story, you probably do not understand the customer yet.
Watch out A vague customer definition makes every downstream paragraph unfalsifiable.
- 2
Quantify the problem
State the specific problem you are solving and back it with data or customer insight that shows it is meaningful and big — ideally a problem people would pay to have solved, so you can show the economics of the customer's status quo versus your solution.
Pro tip Ask: if you solved this, would the customer's own P&L visibly change? If not, the problem may be too small.
- 3
Write the three money paragraphs plus headline and date
Paragraph one: a short description of the thing. Paragraph two: the problem statement. Paragraph three: the solution statement. Add a headline and a hypothetical launch date. The headline is a forcing function — if it is long and drawn out and a reader cannot tell what the thing is, the idea is muddy. The date signals scope: next month versus a year from now.
Pro tip Keep it factual and data-rich, with internal confidential numbers in it. No marketing hyperbole.
Watch out Ditching the headline and date (e.g. writing it as a tweet) strips out two of the document's best diagnostic signals.
- 4
Run the concentric-circle review
Start low-fidelity with one author. Share with a small group, take feedback, improve. Widen the circle, improve again, and keep widening — potentially up to the CEO, depending on the company's scale. Many drafts should be crumpled up by the author or their manager long before they reach the top.
Pro tip The first reviewer who makes you want to bin your own draft has just saved you a quarter of engineering time.
Watch out The goal is not buy-in accumulation. If every PR/FAQ that enters the process survives to the CEO, the process is broken.
- 5
Select, then separate deciding from building
Treat the accumulated PR/FAQs as a corpus of ideas and fund only the best. Once an idea is selected, hand it to the product development process and focus purely on shipping it efficiently with few to no bugs.
Pro tip Keep 'what should we build' and 'how do we ship it' as two distinct processes, so sprint mechanics never become the thing itself.
In the wild
Carr's read on Amazon's most famous failure is that the team started from a technology solution — 3D effects — and then went looking for a problem it solved. Carr, who had to build the music and Prime Video apps for the device, could not work out how 3D made it better for customers to discover or watch media.
→ The phone failed. Carr's diagnosis: when a well-executed product fails, ask what customer problem it actually solved — nine times out of ten, that is the answer.
Amazon never worked backwards from cost. But driving out cost was pursued hard because a low cost structure funds lower prices for customers — and only when it is passed through does it count.
→ Cost efficiency stayed on the flywheel as a customer input rather than becoming a competing objective that pulled the company away from customers.
Common mistakes
Working backwards from revenue
Teams substitute 'how do I increase revenue' or 'how do I increase active customers' for the customer problem. Carr is unambiguous that working backwards is strictly about customer needs — starting from the metric often leads you in the wrong direction.
Running a product tunnel instead of a product funnel
If everything that goes in comes out the other side, you have no method of comparison. You are deploying your most precious resource — engineering — without ever asking whether a better idea existed. Amazon killed plenty of genuinely good PR/FAQs because better ones existed.
Debating unfleshed big ideas
Companies stall in the thinking-to-doing gap by debating concepts that were never written down. Without documentation nobody can evaluate them realistically, so outcomes get decided by politics, willpower, or top-down fiat — and fatal flaws only surface after you have started building.
Is it for you?
Best for
Product leaders at post-product-market-fit companies with multiple product lines who need a repeatable way to choose between more ideas than they can fund.
Not ideal for
Pre-product-market-fit startups still hunting for their first customer, where the cost of writing beats the cost of just shipping.
From the transcript
“you're going to describe very carefully and clearly like who's the customer what's their problem and what's the solution that you're planning to build”
“the heart of it really is that like first paragraph that's a short description that second paragraph that's the problem statement and that third paragraph…”
“what you're really trying to create is a product funnel not a product tunnel”
“you should think of yourself honestly as like a venture capitalist”
“we took it as an article of faith that then things like sales things like revenue and active customers and things like the share price…”
“what most of us do is we start with those constraints”
From the episode
Unpacking Amazon’s unique ways of working
Bill Carr (author of Working Backwards)