Architecting at Amazon Scale
Working Backwards Process
Start with the Customer
Before designing any system, a solutions architect must answer a fundamental question: who is this for, and what problem does it solve for them? Many projects fail because they start with a cool technology and then search for a problem. The Amazonian approach, known as Working Backwards, flips this script. It forces teams to start with the customer and work their way back to the technology. This ensures every architectural decision serves a verified customer need.
The entire process is anchored by five simple, customer-centric questions. Answering them isn't a mere formality; it's the foundation upon which the entire system vision is built. These questions force clarity and prevent teams from building something nobody wants.
Start with customer problems and work backward to solutions
| Question | Purpose |
|---|---|
| 1. Who is the customer? | Define the target user persona(s) with enough detail to feel real. |
| 2. What is the customer's problem or opportunity? | Articulate the core pain point you are solving. |
| 3. What is the most important customer benefit? | Pinpoint the single, clearest value proposition. |
| 4. How do you know what customers need? | Use data, research, and anecdotes to validate the problem. |
| 5. What does the customer experience look like? | Describe the user's journey from their perspective. |
The PR/FAQ Document
The answers to the five questions don't just live in a slide deck. They are synthesized into a formal, internal document called the Press Release and Frequently Asked Questions (PR/FAQ). This artifact becomes the living vision for the product or service before a single line of code is written or a server is provisioned.
The Press Release is a one-page narrative, written as if the product has already launched and is a wild success. It's optimistic and written in customer-facing language, free of jargon. Its purpose is to crystallize the value proposition and generate excitement. If the PR doesn't sound compelling, the idea itself probably isn't.
This process helps teams avoid building complex solutions for problems that don't matter, focusing resources on what truly adds value instead of on where a simpler, off-the-shelf solution might suffice.
Following the one-page PR are two sets of FAQs. The first is the customer FAQ, which anticipates questions a real user might have. How much does it cost? How do I get started? Is my data secure? Answering these forces the team to think through the entire customer experience.
The second is the internal FAQ. This is where the hard questions get asked and answered. What is the architecture? How will we scale this? What are the dependencies? What's our go-to-market strategy? This section defines the solution's blueprint and identifies potential roadblocks. A key output of this internal FAQ is the definition of the Minimal Lovable Product (MLP), which is the smallest version of the product that still solves the core customer problem and delivers significant value.
The goal of an MLP is to create a product that users will love from the very first release, even if it has limited features. It prioritizes user experience and core value over a long list of functionalities.
Validation and Iteration
The PR/FAQ is not a static document. It's a tool for iteration and validation. Once a draft is ready, it's circulated among stakeholders for a rigorous audit. In these reviews, the team defends the idea. Is the customer problem real? Is the proposed benefit truly compelling? Are our assumptions in the internal FAQ sound?
This iterative process of writing, reviewing, and rewriting forces deep thinking and surfaces flaws in logic early, when they are cheap to fix. The PR/FAQ becomes the team's , a concrete vision that guides all subsequent design and implementation decisions. If a proposed feature or architectural choice doesn't support the vision outlined in the PR, it's questioned and likely discarded. This keeps the project focused on delivering what the customer actually needs.
Now that you understand the core principles of the Working Backwards process, let's test your knowledge.
What is the primary principle of the "Working Backwards" methodology?
In the context of a PR/FAQ, what is the key difference between the Customer FAQ and the Internal FAQ?
By mastering this customer-centric approach, you ensure that the complex architectural systems you design are not just technically sound, but are also guaranteed to solve a real-world problem for a clearly defined customer.