Roughly 30,000 new products launch every year, and about 95% of them fail, a figure the late Harvard Business School professor Clayton Christensen spent much of his career documenting (MIT Professional Education). Most of those products were built the same way: someone had an idea, the team sketched features, engineering built a prototype, and only then did anyone ask in earnest who wanted it and why.
Amazon’s working backwards method reverses that order. Before a single designer or engineer is assigned, the team writes a press release for the finished product and a list of the questions that product will have to answer. If the press release is boring and the questions have no good answers, the idea dies on a page instead of in the market. Amazon used this process to shape the Kindle, Prime, and AWS, and its two best-known chroniclers, former executives Colin Bryar and Bill Carr, laid it out in their book Working Backwards.
Here is how the method actually works, where it quietly fails (including inside Amazon), and how to run it on a team that does not have Amazon’s budget or culture.
What Amazon writes before it funds anything
Amazon developed the PR/FAQ around 2005, after its leaders decided the tools they had been leaning on, SWOT grids and spreadsheet projections, let them avoid thinking hard about the customer. That history comes from Working Backwards LLC, the practice Bryar and Carr now run. The fix was deceptively plain: describe the finished product as a press release, then answer every question that press release would provoke.
Two details make it work. First, it is a written narrative, not a slide deck. Amazon is well known for banning PowerPoint in these reviews, because bullet points let a presenter skate past the gaps that full sentences expose. Second, the document is read in silence at the start of the meeting. The official process gives everyone roughly 15 to 20 minutes to read and annotate the same document in the room, then opens the floor for debate. Nobody skims, nobody presents, everybody argues from the same text.
At Amazon, nothing of consequence gets funded without one. Most drafts get sent back or rejected outright, and that is the entire point. A one-page document is far cheaper to rewrite than a product is to rebuild after six months.
The two parts, and which one matters more
A PR/FAQ has a press release and a FAQ. Teams spend their energy on the first and get caught by the second.
The press release is one page, written in plain language a customer would actually use. The official template runs through a headline, a subheading, a summary, the customer problem, the solution, and a customer quote. No architecture, no acronyms, no internal codenames.
The FAQ splits in two. External questions are the ones a customer asks: what does it cost, does it work with what I already own, what happens to my data, how do I get help. Internal questions are the ones your CFO and your staff engineer ask: what is the market worth, what does the revenue model look like at year three, what are the technical risks, how does this cannibalize the product we already sell.
The press release is a writing exercise. The internal FAQ is a reckoning. It is where optimistic ideas run into the questions nobody wanted to ask out loud, and the gap between a confident press release and a thin FAQ is the most honest readiness signal you will get.
The press release that sells itself to no one
A good press release leads with a specific, measurable benefit. Amazon’s framing for the first Kindle was that you could buy and download a book in under a minute, not that it offered “an improved reading experience.” Specificity is the whole test.
Running pre-build reviews for small companies through my fractional COO work, I see the same first draft over and over. A founder writes a launch announcement that reads like an internal memo: a feature list, a nod to the target market, a line about efficiency. You cannot tell who it is for or why they would switch. The useful move is to hand it back with one question: who is the single person whose week changes when this ships, and by how much?
The rewrite is always better, and it is almost always shorter. “Operations managers at e-commerce companies with 10 to 50 staff who track inventory in spreadsheets” is a customer you can build for. “Small businesses” is not. “Cuts monthly close from four days to one” is a promise you can test. “Streamlines workflows” is not. The press release does not make a weak idea strong. It makes a weak idea obvious, early, while stopping is still cheap.
Amazon wrote a press release for the Fire Phone too
The method is not a guarantee, and Amazon’s own history proves it. The Fire Phone launched in July 2014 at $199 on a two-year contract, the same price as the iPhone, and was cut to 99 cents within about two months. Amazon took a $170 million write-down and was left with $83 million in unsold inventory (TIME). It went through the same working backwards process that produced the Kindle.
So what broke? The internal FAQ question that should have been fatal, “why would a customer leave the phone they already have for this one,” never got an honest answer. The headline features, a 3D “dynamic perspective” display and object scanning, dazzled in a demo and solved no real problem; object scanning mostly nudged people to buy more from Amazon. A press release can be written to flatter the features you already want to build. Working backwards protects you only if the room is willing to write down the uncomfortable answer and then act on it. The document surfaces the hard question. It does not force anyone to answer it honestly.
That is the lesson most PR/FAQ guides skip. The format is a forcing function, not a truth serum.
Why this beats a feature spec
A traditional PRD or feature spec describes what gets built. A team can agree on a feature list while holding completely different beliefs about who the user is and what problem the thing solves. The press release makes those disagreements visible before any code exists, because you cannot write a compelling one without naming the customer and committing to a concrete outcome.
That is also why it pairs well with assumption mapping. The press release states what you are claiming; assumption mapping identifies what you would have to prove for the claim to hold. One is the pitch, the other is the risk register behind it.
Running it when you are not Amazon
You do not need Amazon’s scale to use the method. A workable version for a normal team:
- One author, one draft. The PM, or whoever owns the idea, writes the first version alone. Committee drafts come out watered down.
- Silent read. Give three to five stakeholders the document and 20 minutes to read and annotate without talking, the way Amazon does it.
- Go section by section. Start at the headline. The feedback you want to hear early is “I cannot tell who this is for” and “that benefit is vague.” Both are free to fix on paper.
- Expect revisions. Two to four cycles is normal. Each one should sharpen the customer, harden the benefit, and fill a hole in the internal FAQ.
- Decide. When the press release is clear and the FAQ holds up, you have the alignment to move to roadmap and spec work. If it never gets there, you just saved a quarter.
The writing costs a few hours to a few days. Building the wrong thing costs months. In two decades running IT operations at a large telecom, the launches that went sideways almost never failed on the engineering. They failed because the room never agreed, in writing, on who the change was actually for. A press release written first would have exposed that gap in an afternoon.
The honest version of the pitch
Working backwards gets sold as a near-magic filter. It is not. It is a cheap, early, structured argument about the customer, and its value rests entirely on whether the people in the room will write down and act on the answer to the one question that matters: why would anyone choose this over what they already do. Amazon gets that wrong often enough to have a Fire Phone in its past. The teams that get the most from the method treat a rejected PR/FAQ as a win rather than a setback. For where it sits among the other tools you have, see our rundown of product management frameworks.