I was a VP at Amazon from 2004 to 2014. In that time, every major new product innovation was built using the same exact process. 11 years later, they are still using that process for everything they build. Here’s how it works. The process is called Working Backwards. It flips the traditional invention approach by not starting with a company’s internal capabilities or current products. It starts instead with a clear definition of a customer problem. The goal is to write a press release describing a significant customer problem or need, how current solutions don’t solve the problem, and the new product user experience for a solution to the problem. This approach is “Backwards” because it starts with a press release (the last step in building a new product ). Most companies start building products by evaluating their existing technology or capabilities, or by looking at new trends, and then trying to build something customers will want. Amazon takes the opposite approach. Working Backwards starts with a deep understanding and concise definition of a customer problem before moving to potential solutions. After writing the Press Release, you add a list of frequently asked questions, or FAQs. The FAQs include the likely questions from customers and the press, as well as the typical questions the internal leaders ask about any new product idea, like "How big is the market?" and "How will we solve the technical challenges?" This document forces teams to clarify not only the customer problem they are solving, but also the ideal outcome from the customer’s perspective. This is all done before a single line of code is written or a prototype is built. To do this, teams frame the problem statement, the customer behaviors, and existing alternative solutions. Then, they describe the ideal customer experience, outlining how the product would solve the problem meaningfully. Finally, they anticipate key challenges (legal, technical, competitive, or operational) and document how they will address them. The key here is this: If the problem statement is weak, unclear, or does not represent a significant customer need (with a large TAM), then moving forward with development is a waste of time and money. While working backwards, teams iterate on the problem definition until it is strong and clear, or they move on to a different idea. Amazon has used this process to build many multi-billion dollar businesses, and it remains a core part of their innovation strategy. By working backwards, Amazon ensures that the products they build have a clear reason to exist before any resources are spent. Follow for more insights about building inside Amazon.
Bill Carr This is a masterclass in customer-first innovation—thanks for sharing it! I'm curious though: as a VP, how did you operationalize Working Backwards at scale? Was there a dedicated team, toolkit, or playbook that helped craft these narratives and validate them consistently? Having led multi-enterprise transformations myself, I know strong processes need more than a great idea—they need cultural enablers, discovery rituals, and clear ownership. Would love to hear how that looked at Amazon behind the scenes.
Great insights Bill Carr. On the HW front - product costs are locked in early in the concept phase, which makes it tough (or near impossible) to backtrack after design decisions are made in a startup. This is a great idea to develop a tighter business case before getting started.
There's an interesting contradiction between this post and another recent one also from a former Amazon VP. This post celebrates Amazon's "Working Backwards" process as the secret to their innovation success - starting with customer problems before solutions. Yet weeks ago, another former VP described Amazon's multiple failures trying to compete with Steam in gaming, despite being "250x bigger." Their key admission: "We never validated our core assumptions before investing heavily in solutions." So which is it? Is Amazon religiously "working backwards" from customer needs, or do they sometimes rush ahead without validating assumptions? Perhaps the truth is that even with excellent frameworks like "Working Backwards," execution is incredibly difficult at any scale. As I commented on the previous post: You can write "Customer Obsession" on every bathroom wall, but knowing the right methodology isn't the same as executing it consistently. Even giants like Amazon sometimes fall into the trap of assuming they understand their customers when they don't.
Is this how Bezos started initially or adapted later?
When I was at Amazon, learning how to write these documents was genuinely life-changing. It’s a practice I still use today. There’s something incredibly powerful about sitting down and forcing yourself to answer tough questions like: Who is this product for? How does it benefit them? How does it benefit the business? That said, I do think the process had its shortcomings. People often became so focused on crafting the perfect doc that the document itself started to feel like the product—rather than the thing they were actually building or promoting.
Thanks for sharing, Bill
Thanks for sharing, Bill
Start with the end in mind . . . . on steroids
Supply Chain Leader | Data-Driven Decision Maker | Passionate About Insights & Analytics
6dA masterclass in customer-centric innovation. Thxn Bill Carr I’m curious—on average, how much time did teams spend from ideation to a final go/no-go decision using the Working Backwards process? Also, how did Amazon identify and seize white-space opportunities where limited data points existed to start with?