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.”2 In other words, while it’s true that shareholder value stems from growth in profit, Amazon believes that long-term growth is best produced by putting the customer first.

“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.”

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.”

“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.”

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).

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.

At many companies, when the senior leadership meets, they tend to focus more on big-picture, high-level strategy issues than on execution. At Amazon, it’s the opposite. Amazon leaders toil over the execution details and regularly embody the Dive Deep leadership principle, which states: “Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdotes differ. No task is beneath them.”

According to Sequoia Capital, the average startup in Silicon Valley spends 990 hours to hire 12 software engineers!

Brent Gleeson, a leadership coach and Navy SEAL combat veteran, writes, “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.”

The Amazon Bar Raiser program has the goal of creating a scalable, repeatable, formal process for consistently making appropriate and successful hiring decisions.

Sometimes the hiring manager isn’t sure about a candidate but still invites them to go through the interview loop, hoping that this will assist in the hiring decision. This is a mistake. In most cases, the questionable candidate will not get the job, and a lot of time will have been wasted in the process.

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?”

Amazon interviewers are reminded to keep in mind that every candidate—whether qualified for the job or not—is a potential customer of the company and a source of leads. Assume they will tell their friends and co-workers about their interview experience. Sometimes that will be difficult, especially if you’ve determined the candidate is not right for the role or company, but it must be done.

One question that often gets a telling response is, “If given the chance, would you hire this person again?” Another is, “Of the people you have managed or worked with, in what percentile would you place this candidate?”

The Bar Raiser process is designed to minimize personal bias and maximize making data-based hiring decisions based on the substance of each candidate’s work and how that work maps to a set of principles. As discussed earlier in this chapter, personal biases naturally occur in an unstructured interview and hiring process. Bar Raiser process steps such as preparing a set of behavior-based interview questions in advance of the interview, insisting on written transcripts of the interview, rereading the transcript post interview (before making an assessment), conducting debriefs, basing debriefs on the interview transcripts, and making assessments based on well-understood principles are all steps that seek to eliminate individual biases.

Ideally, the bar continues to be set higher, so much that, eventually, employees should be able to say to themselves, “I’m glad I joined when I did. If I interviewed for a job today, I’m not sure I’d be hired!”

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

JEFF: So, this is all that you and your team work on every day? VP 1: Well, no. The only person working on it full time is one of our product managers, but we have lots of other people helping part time.

The answer lies in an Amazon innovation called “single-threaded leadership,” in which a single person, unencumbered by competing responsibilities, owns a single major initiative and heads up a separable, largely autonomous team to deliver its goals.

The single-threaded leadership model emerged at the tail end of a long, zigzag journey of well-informed trial and error. We asked ourselves a difficult question, then responded with bold critical thinking, experimentation, and relentless self-critique that helped us double down on successful ideas and jettison the failures.

During this phase, we became aware of another, less positive trend: our explosive growth was slowing down our pace of innovation. We were spending more time coordinating and less time building.

Managing dependencies requires coordination—two or more people sitting down to hash out a solution—and coordination takes time. As Amazon grew, we realized that despite our best efforts, we were spending too much time coordinating and not enough time building. That’s because, while the growth in employees was linear, the number of their possible lines of communication grew exponentially.

The project did launch successfully. But I noticed that in the areas where we controlled our own destiny—that is, the reporting, accounting, and payment changes, as well as our marketing plan—we were able to move fast. And in the areas where we had to make very minor changes to Obidos and acb, we moved painfully slowly. Why was that? Dependencies.

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.

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.

each team to act autonomously and move faster.

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.”

Sometimes it’s best to start slow in order to move fast.

The leaders who had been trying to get this service off the ground before Tom Taylor took it over were exceptionally capable people, but while they were tending to all their other responsibilities, they just didn’t have the bandwidth to manage the myriad details FBA entailed. FBA would have been, at best, much slower and more difficult to launch if Jeff Wilke hadn’t freed up Tom to focus on nothing but this one project. The single-threaded leader concept hadn’t yet been formalized at Amazon, but Tom became an important forerunner.

The other crucial component of the STL model is a separable, single-threaded team being run by a single-threaded leader like Tom. As Jeff Wilke explains, “Separable means almost as separable organizationally as APIs are for software. Single-threaded means they don’t work on anything else.”

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.

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

“As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense,” he writes, “the more damaging the bullet list becomes.”

“PowerPoint becomes ugly and inaccurate because our thoughts are foolish, but the slovenliness of PowerPoint makes it easier for us to have foolish thoughts.”

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.

Working as Jeff’s shadow was a bit like drinking from a fire hose. One surprising challenge of the job I (Colin) noticed early on was just how much context switching went on each day. Every week Jeff—and therefore I—had three recurring meetings: the four-hour S-Team meeting discussed in the previous chapter, a Weekly Business Review (chapter six), and an informal Monday-morning S-Team breakfast near the office. In addition to those, on any given day we’d usually meet with two to four product teams, where we’d spend between one and two hours doing a deep dive on new products and features. Throw in the occasional retail, finance, and operations updates, plus a fire drill or two requiring immediate attention, and you have a typical week.

Writing up our ideas was hard work. It required us to be thorough and precise. We had to describe features, pricing, how the service would work, why consumers would want it. Half-baked thinking was harder to disguise on the written page than in PowerPoint slides. It could not be glossed over through personal charm in the presentation.

The Working Backwards document became known as the PR/FAQ.

The Features and Benefits of the PR/FAQ The primary point of the process is to shift from an internal/company perspective to a customer perspective.

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.

Weekly Business Review (WBR). The purpose of the WBR was to provide a more comprehensive lens through which to see the business.

When the retail, operations, and finance teams began to construct 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.

In 2001 Jeff drew the simple diagram below on a napkin to illustrate Amazon’s virtuous cycle, also called the “Amazon flywheel.” This sketch, inspired by the flywheel concept in Jim Collins’s book Good to Great, is a model of how a set of controllable input metrics drives a single key output metric—in this case, growth. In this closed-loop system, as you inject energy into any one element, or all of them, the flywheel spins faster:

Note: Most of the examples we give in this chapter are of large companies with substantial resources. But DMAIC and the WBR process is eminently scalable. Your level of investment should be on par with the resources you have. If you are a nonprofit, figure out a modest number of key metrics that reliably show how well you are doing. For example, how often do you contact your donor base, and how does that frequency affect your funding? A big mistake people make is not getting started. Most WBRs have humble beginnings and undergo substantial changes and improvement over time.

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. When you see an anomaly, ask why it happened and iterate with another “Why?” until you get to the underlying factor that was the real culprit. This COE process requires the team who had a significant error or problem to write a document describing the problem or error, and to drill down on what caused it by asking and answering “Why?” five times in order to get to the true root cause.

“When you encounter a problem, the probability you’re actually looking at the actual root cause of the problem in the initial 24 hours is pretty close to zero, because it turns out that behind every issue there’s a very interesting story.”

Output Metrics Show Results. Input Metrics Provide Guidance.