Working Backwards: Insights, Stories, and Secrets from Inside Amazon

by Colin Bryar

“We have an unshakeable conviction that the long-term interests of shareowners are perfectly aligned with the interests of customers.”

“Our culture is four things: customer obsession instead of competitor obsession; willingness to think long term, with a longer investment horizon than most of our peers; eagerness to invent, which of course goes hand in hand with failure; and then, finally, taking professional pride in operational excellence.”

Jeff and his leadership team crafted a set of 14 Leadership Principles, as well as a broad set of explicit, practical methodologies, that constantly reinforce its cultural goals. These include: the Bar Raiser hiring process that ensures that the company continues to acquire top talent; a bias for separable teams run by leaders with a singular focus that optimizes for speed of delivery and innovation; the use of written narratives instead of slide decks to ensure that deep understanding of complex issues drives well-informed decisions; a relentless focus on input metrics to ensure that teams work on activities that propel the business. And finally there is the product development process that gives this book its name: working backwards from the desired customer experience.

He truly embodies the Amazon motto, “Work hard, have fun, make history.”

I worked with him during his regular office hours from ten in the morning to seven in the evening.

“We need to plant many seeds,” he would say, “because we don’t know which one of those seeds will grow into a mighty oak.”

After reading this book, we hope you’ll see that being Amazonian is not a mystical leadership cult but a flexible mindset.

We also found that what really works in meetings is not what most companies do in meetings. As much as we respect PowerPoint as a visual communication tool and speaking aid, we learned the hard way that it’s not the best format to communicate complex information about initiatives and ongoing projects in a one-hour meeting. We found, instead, that a six-page narrative written by a given team is the method that best enables everyone in a meeting to get up to speed quickly and efficiently on the project that team is working on.

From the tone of customer emails to the condition of the books and their packaging, Jeff had one simple rule: “It has to be perfect.” He’d remind his team that one bad customer experience would undo the goodwill of hundreds of perfect ones.

Amazon’s Leadership Principles6 Customer Obsession. Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers. Ownership. Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say, “that’s not my job.” Invent and Simplify. Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here.” As we do new things, we accept that we may be misunderstood for long periods of time. Are Right, A Lot. Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs. Learn and Be Curious. Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them. Hire and Develop the Best. Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice. Insist on the Highest Standards. Leaders have relentlessly high stan...

Mechanisms: Reinforcing the Leadership Principles There’s a saying often heard at Amazon: “Good intentions don’t work. Mechanisms do.”

goals must be Specific, Measurable, Attainable, Relevant, and Timely (SMART). An actual S-Team goal could be as specific as “Add 500 new products in the amazon.fr Musical Instruments category (100 products in Q1, 200 in Q2…),” or “Ensure 99.99 percent of all calls to software service ‘Y’ are successfully responded to within 10 milliseconds,” or “Increase repeat advertisers from 50 percent to 75 percent by Q3 of next year.” S-Team goals are aggressive enough that Amazon only expects about three-quarters of them to be fully achieved during the year. Hitting every one of them would be a clear sign that the bar had been set too low.

Amazon’s compensation is, by contrast, simple and oriented toward the long term. As one is promoted at Amazon, the ratio of cash to equity compensation becomes more and more skewed toward long-term equity.

managers will often be driven by urgency, biases, and convenience rather than purpose, data, and analysis.

“Organizational culture comes about in one of two ways. It’s either decisively defined, nurtured and protected from the inception of the organization; or—more typically—it comes about haphazardly as a collective sum of the beliefs, experiences and behaviors of those on the team. Either way, you will have a culture. For better or worse.”

jumped from roughly 600 employees in 1997 to 9,000 in 2000, and then to 100,000 by 2013 (as of this writing, in 2020, Amazon is approaching one million employees).

The method that Amazon interviewers use for drilling down goes by the acronym STAR (Situation, Task, Action, Result): “What was the situation?” “What were you tasked with?” “What actions did you take?” “What was the result?”

It’s also a good reminder to always be on the lookout for those places where bias can go undetected and undermine your results.

When a software architecture includes a large number of technical dependencies, it is said to be tightly coupled, a bad thing that frustrates all involved when you are trying to double and triple the size of the software team. Amazon’s code had been designed in such a way that it became more tightly coupled over time.

At last we realized that all this cross-team communication didn’t really need refinement at all—it needed elimination. Where was it written in stone that every project had to involve so many separate entities? It wasn’t just that we had had the wrong solution in mind; rather, we’d been trying to solve the wrong problem altogether. We didn’t yet have the new solution, but we finally grasped the true identity of our problem: the ever-expanding cost of coordination among teams. This change in our thinking was of course nudged along by Jeff. In my tenure at Amazon I heard him say many times that if we wanted Amazon to be a place where builders can build, we needed to eliminate communication, not encourage it. When you view effective communication across groups as a “defect,” the solutions to your problems start to look quite different from traditional ones. He suggested that each software team should build and clearly document a set of application program interfaces (APIs) for all their systems/services. An API is a set of routines, protocols, and tools for building software applications and defining how software components should interact. In other words, Jeff’s vision was that we needed to focus on loosely coupled interaction via machines through well-defined APIs rather than via humans through emails and meetings. This would free each team to act autonomously and move faster.

We went through a period of serious introspection and concluded that a service-oriented architecture would give us the level of isolation that would allow us to build many software components rapidly and independently. By the way, this was way before service-oriented was a buzzword. For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services.

The most successful teams invested much of their early time in removing dependencies and building “instrumentation”—our term for infrastructure used to measure every important action—before they began to innovate, meaning, add new features.

In the 2016 shareholder letter, even though he wasn’t explicitly talking about two-pizza teams, Jeff suggested that “most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.”5

After experimenting over many months across many teams, we realized that as long as we did the up-front work to agree on the specific metrics for a team, and we agreed on specific goals for each input metric, that was sufficient to ensure the team would move in the right direction.

We all agreed at the outset that a smaller team would work better than a larger one. But we later came to realize that the biggest predictor of a team’s success was not whether it was small but whether it had a leader with the appropriate skills, authority, and experience to staff and manage a team whose sole focus was to get the job done.

“The best way to fail at inventing something is by making it somebody’s part-time job.”6

As former Amazon VP Tom Killalea aptly observed, a good rule of thumb to see if a team has sufficient autonomy is deployment—can the team build and roll out their changes without coupling, coordination, and approvals from other teams?

This journey is also a great example of another phrase you’ll hear at Amazon: be stubborn on the vision but flexible on the details.

“The Cognitive Style of PowerPoint: Pitching Out Corrupts Within,” by Edward Tufte, a Yale professor who is an authority on the visualization of information.

1

Tufte offered wise advice on how to get started. “Making this transition in large organizations requires a straightforward executive order: From now on your presentation software is Microsoft Word, not PowerPoint. Get used to it.” That is essentially what we did.

A complete narrative should also anticipate the likely objections, concerns, and alternate points of view that we expect our team to deliver.

Jeff has an uncanny ability to read a narrative and consistently arrive at insights that no one else did, even though we were all reading the same narrative. After one meeting, I asked him how he was able to do that. He responded with a simple and useful tip that I have not forgotten: he assumes each sentence he reads is wrong until he can prove otherwise. He’s challenging the content of the sentence, not the motive of the writer. Jeff, by the way, was usually among the last to finish reading.

Working Backwards is a systematic way to vet ideas and create new products. Its key tenet is to start by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build. Its principal tool is a second form of written narrative called the PR/FAQ, short for press release/frequently asked questions.

Jeff and I would need to get up to speed on where we left off with any given team, so the first part of each product meeting could be viewed as setup cost. Then we’d discuss the progress made since our last meeting, ask and answer questions, discuss new issues or problems, and agree on next steps that needed to be addressed before we met with the team again.

The PR gives the reader the highlights of the customer experience. The FAQ provides all the salient details of the customer experience as well as a clear-eyed and thorough assessment of how expensive and challenging it will be for the company to build the product or create the service. That’s why it’s not unusual for an Amazon team to write ten drafts of the PR/FAQ or more, and to meet with their senior leaders five times or more to iterate, debate, and refine the idea.

The creation of the PR/FAQ starts with the person who originated either the idea or the project writing a draft. When it’s in shareable condition, that person sets up a one-hour meeting with stakeholders to review the document and get feedback. At the meeting, they distribute the PR/FAQ in either soft or hard copy, and everyone reads it to themselves. When they have finished, the writer asks for general feedback. The most senior attendees tend to speak last, to avoid influencing others. Once everyone has given their high-level responses, the writer asks for specific comments, line by line, paragraph by paragraph. This discussion of the details is the critical part of the meeting. People ask hard questions. They engage in intense debate and discussion of the key ideas and the way they are expressed. They point out things that should be omitted or things that are missing. After the meeting, the writer distributes meeting minutes to all the attendees, including notes on the feedback. Then they get to work on the revision, incorporating responses to the feedback. When it is polished, they present it to the executive leaders in the company. There will be more feedback and discussion. More revision and more meetings may be required.

The fact that most PR/FAQs don’t get approved is a feature, not a bug.

There is no guarantee that an idea expressed in an excellent PR/FAQ will move forward and become a product. As we’ve said, only a small percentage will get the green light. But this is not a drawback. It is, in fact, a huge benefit of the process—a considered, thorough, data-driven method for deciding when and how to invest development resources. Generating and evaluating great ideas is the real benefit of the Working Backwards process.

Though we focus on the WBR in this chapter, the same principles and techniques can be applied wherever you need to look at data to help make informed decisions.

the initial Amazon WBR, they turned to a well-known Six Sigma process improvement method called DMAIC, an acronym for Define-Measure-Analyze-Improve-Control.1 Should you decide to implement a Weekly Business Review for your business, we recommend following the DMAIC steps as well. The order of the steps matters. Progressing through this metrics life cycle in this order can prevent a lot of frustration and rework, allowing you to achieve your goals faster.

Input metrics track things like selection, price, or convenience—factors that Amazon can control through actions such as adding items to the catalog, lowering cost so prices can be lowered, or positioning inventory to facilitate faster delivery to customers. Output metrics—things like orders, revenue, and profit—are important, but they generally can’t be directly manipulated in a sustainable manner over the long term. Input metrics measure things that, done right, bring about the desired results in your output metrics.

cost, provided the teams with an actionable and correct set

The right input metrics get the entire organization focused on the things that matter most.

Start with the customer and work backwards by aligning your metrics with the customer experience.

the Analyze stage is all about developing a comprehensive understanding of what drives your metrics. Until you know all the external factors that impact the process, it will be difficult to implement positive changes. The objective in this stage is separating signals from noise in data and then identifying and addressing root causes. Why is it we can pick 100 items per hour in a fulfillment center on one shift and 30 items per hour on another? Why are we able to display pages in under 100 milliseconds most of the time yet some pages take 10 seconds to display? Why are customer service contacts per order always higher on Mondays than on other days of the week? When Amazon teams come across a surprise or a perplexing problem with the data, they are relentless until they discover the root cause. Perhaps the most widely used technique at Amazon for these situations is the Correction of Errors (COE) process, based upon the “Five Whys” method developed at Toyota and used by many companies worldwide.

How many metrics should you review? There is no magic number or formula. Coming up with the right metrics takes time, and you should seek to improve them continuously.

We focus on variances and don’t waste time on the expected People like talking about their area, especially when they’re delivering as expected, and even more so when they exceed expectations, but WBR time is precious. If things are operating normally, say “Nothing to see here” and move along. The goal of the meeting is to discuss exceptions and what is being done about them. The status quo needs no elaboration.