The scenarioAmazon's "Working Backwards" process — the practice of writing a press release and FAQ for a product before building it — is often described as a customer-obsession ritual. It is that. But its deeper mechanism is inversion. When
Jeff Bezos formalised the process in the early 2000s, the problem he was solving wasn't a lack of customer focus. It was a pattern he'd observed repeatedly: teams would build technically impressive products that failed because they'd never confronted the conditions under which customers would reject them. The forward question — "What should we build?" — produced feature lists. The inverted question embedded in the FAQ — "What are all the reasons a customer would choose not to use this?" — produced the design constraints that actually mattered.
How the tool appliedThe FAQ section of Amazon's internal press release template is structured inversion. Product teams must answer questions like: "Why would a customer not switch from their current solution?" "What's the most common objection a customer would raise?" "Under what conditions would this product make a customer's life worse?" These are failure-condition questions dressed in customer language. The team behind the original Kindle, for instance, had to confront the failure mode "customers won't switch from physical books if the e-reader doesn't have a library of at least 100,000 titles at launch." That specific inversion — what would guarantee that nobody buys this? — drove the decision to delay launch until the content library was large enough to overcome the switching cost. The team reportedly pushed back on the timeline, arguing the hardware was ready. The FAQ's failure-mode logic won.
What it surfacedThe Kindle example illustrates inversion's core contribution: it surfaces the binding constraints that forward planning misses. A forward plan for the Kindle would prioritise hardware specs, screen technology, battery life, industrial design. All important. But none of them mattered if the content library was too thin. Inversion identified the single condition — insufficient content — that would have guaranteed failure regardless of how good the hardware was. The entire launch timeline reorganised around that constraint.