Working Backwards Summary

A normal company starts with a product idea, then looks for buyers. Amazon tries to begin with the buyer, then makes the product earn its way into the room.

Colin Bryar and Bill Carr watched that method from close range. Bryar joined Amazon in 1998 and became Jeff Bezos’s Chief of Staff, while Carr joined in 1999 and helped build the company’s digital media business.

Their book is less a memoir than a field guide to Amazon’s operating system. The central claim is simple and useful: if you force a team to write the future customer experience before it builds anything, weak ideas fail while they are still cheap.

That is the famous working backwards method. It turns a dream into a draft, a draft into a test, and a test into a set of decisions that people can argue about before money starts running.

A press release usually belongs at the end, when the champagne is cold and the facts have behaved. Amazon puts it at the start, when the idea is still soft enough to bruise.

The tool is called the PR/FAQ, which means press release and frequently asked questions. A team writes a short launch announcement from the future, aimed at the customer, not the boss. Then it writes the hard questions that customers, lawyers, finance teams, and operators would ask if the thing were real.

A vague idea can smile in a slide deck. It sweats on a press release.

Before the Kindle reached customers in 2007, Amazon teams had to make the customer promise clear in plain language. The point was not to praise the device. The point was to explain why a reader would care, what pain would go away, and why Amazon had any right to solve it.

This matters because most companies confuse internal excitement with external demand. A room can fall in love with a feature because the feature took six months and three teams to build. The customer, rude creature, only asks what it does for them.

Amazon’s real trick is making enthusiasm fill out paperwork before it gets a badge.

The FAQ section is where the blueprint starts to change shape. It asks about price, failures, edge cases, launch steps, and reasons not to build. A strong answer does not guarantee success, but a weak answer is a mercy. It kills the project before the project hires people, claims status, and becomes too proud to die.