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

by Colin Bryar

the simplest and best distillation is still that of founder Jeff Bezos (hereafter referred to as Jeff): “We have an unshakeable conviction that the long-term interests of shareowners are perfectly aligned with the interests of customers.”

Jeff described Amazon this way: “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;

the use of written narratives instead of slide decks to ensure that deep understanding of complex issues drives well-informed decisions;

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.

Think Big. Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

Frugality. Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention.

goals must be Specific, Measurable, Attainable, Relevant, and Timely (SMART).

The name was intended to signal to everyone involved in the hiring process that every new hire should “raise the bar,” that is, be better in one important way (or more) than the other members of the team they join. The theory held that by raising the bar with each new hire, the team would get progressively stronger and produce increasingly powerful results.

General, open-ended questions such as “Tell me about your career” or “Walk me through your résumé” are usually a waste of time and will not produce the kind of specific information you’re after.

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

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.

a clearly defined model that people would talk about for years to come: the two-pizza team, so named because the teams would be no larger than the number of people that could be adequately fed by two large pizzas.

Be the business owner. The team will own and be responsible for all aspects of its area of focus, including design, technology, and business results. This paradigm shift eliminates the all-too-often heard excuses such as, “We built what the business folks asked us to, they just asked for the wrong product,” or “If the tech team had actually delivered what we asked for and did it on time, we would have hit our numbers.”

Amazon’s SVP of Devices, Dave Limp, summed up nicely what might happen next: “The best way to fail at inventing something is by making it somebody’s part-time job.”

Amazon uses two main forms of narrative. The first is known as the “six-pager.” It is used to describe, review, or propose just about any type of idea, process, or business. The second narrative form is the PR/FAQ. This one is specifically linked to the Working Backwards process for new product development.

Tufte identified in one sentence the problem we’d been experiencing: “As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense,” he writes, “the more damaging the bullet list becomes.” That description fit our discussions at the S-Team meetings: complex, interconnected, requiring plenty of information to explore, with greater and greater consequences connected to decisions. Such analysis is not well served by a linear progression of slides that makes it difficult to refer one idea to another, sparsely worded bits of text that don’t fully express an idea, and visual effects that are more distracting than enlightening. Rather than making things clear and simple, PowerPoint can strip the discussion of important nuance. In our meetings, even when a presenter included supporting information in the notes or accompanying audio, the PowerPoint presentation was never enough.

While Tufte’s essay wasn’t the sole impetus behind the move to narratives, it crystallized our thinking. On June 9, 2004, the members of the S-Team received an email with the following subject line: “No PowerPoint presentations from now on at S-Team.”

We probably should not have been surprised by that reaction. Until that June day in 2004, PowerPoint had been the default tool for communication of ideas in many meetings at Amazon, just as it was and still is at many companies. Everybody knew its delights and perils. What could be more exhilarating than listening to a charismatic executive deliver a rousing presentation backed up by snappy phrases, dancing clip art, and cool slide transitions? So what if you couldn’t remember the details a few days later? And what could be worse than suffering through a badly organized presentation using a drab template and tons of text in a font too small to read? Or, worse still, squirming as a nervous presenter stumbled and faltered through slide after slide?

Jeff offered a short explanation of the reason behind the change. The reason writing a good 4 page memo is harder than “writing” a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related. Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.

The style of the deck varies from team to team, but all share the constraints imposed by the PowerPoint format. No matter how complex or nuanced the underlying concepts, they are presented as a series of small blocks of text, short bullet-pointed lists, or graphics. Even the most ardent PP fans acknowledge that too much information actually spoils the deck. Amazon’s bestselling book on PowerPoint describes three categories of slides: 75 words or more: A dense discussion document or white paper that is not suitable for a presentation—it’s better distributed in advance and read before the meeting. 50 words or so: A crutch for the presenter who uses it as a teleprompter, often turning away from an audience while reading aloud. Even fewer words: A proper presentation slide, used to visually reinforce primarily spoken content. The presenter must invest time to develop and rehearse this type of content.

A switch to narratives places the team’s ideas and reasoning center stage, leveling the playing field by removing the natural variance in speaking skills and graphic design expertise that today plays too great a role in the success of presentations.

One useful metric for comparison is what we call the Narrative Information Multiplier (tip of the hat to former Amazon VP Jim Freeman for coining this term). A typical Word document, with text in Arial 11-point font, contains 3,000–4,000 characters per page. For comparison, we analyzed the last 50 S-Team PowerPoint slide presentations and found that they contained an average of just 440 characters per page. This means a written narrative would contain seven to nine times the information density of our typical PowerPoint presentation.

Our goal as presenters is not to merely introduce an idea but to demonstrate that it’s been carefully weighed and thoroughly analyzed. Unlike a PP deck, a solid narrative can—and must—demonstrate how its many, often disparate, facts and analyses are interconnected. While an ideal PP presentation can do this, experience has shown that they rarely do in practice. A complete narrative should also anticipate the likely objections, concerns, and alternate points of view that we expect our team to deliver. Writers will be forced to anticipate smart questions, reasonable objections, even common misunderstandings—and to address them proactively in their narrative document. You simply cannot gloss over an important topic in a narrative presentation, especially when you know it’s going to be dissected by an audience full of critical thinkers. While this may seem a bit intimidating at first, it merely reflects our long-standing commitment to thinking deeply and correctly about our opportunities.

We know that people read complex information at the rough average of three minutes per page, which in turn defines the functional length of a written narrative as about six pages for a 60-minute meeting.

NO. Reproducing PP on paper also reproduces its weaknesses. There’s nothing one can do in PP that cannot be done more thoroughly, though sometimes less attractively, in a narrative.

We mentioned earlier the estimated reading speed of three minutes per page, which led to the six-page limit. If yours is a 30-minute meeting, a three-page narrative would therefore be more appropriate. Our goal has been to leave two-thirds of the meeting time for discussing what we’ve read.

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.

Working Backwards process—starting from the customer experience and working backwards from that by writing a press release that literally announces the product as if it were ready to launch and an FAQ anticipating the tough questions.

He found our proposals light on the details as to how the service would work for customers. Finally, inevitably, he would ask, “Where are the mock-ups?” Jeff was referring to the visual representations that would show exactly how the new service would look on the Amazon website. Mock-ups should be detailed, showing the entire customer experience from landing page to purchase—screen design, buttons, text, the sequence of clicks, everything. To create a meaningful and informative mock-up you have to think through every element of what the service will offer, what the experience will be for the customer, how all the features will work on the page.

It was clear that half-baked mock-ups were no better, perhaps worse, than no mock-ups at all. To Jeff, a half-baked mock-up was evidence of half-baked thinking.

We had freed ourselves of the quantitative demands of Excel, the visual seduction of PowerPoint, and the distracting effect of personal performance. The idea had to be in the writing.

Half-baked thinking was harder to disguise on the written page than in PowerPoint slides.

There was no assembly line to halt, but the CS agent would be given the authority to click on what we called “the big red button” on their control screen. Once that button was clicked, two things happened: the “Add to Cart” and “1-Click” buttons would disappear from the product page so no customers could buy that product, and the category manager would immediately be notified that purchasing for one of their products had been disabled until they could investigate and fix the issue. It took some time to put Jeff’s idea into operation. We had to build the tools that would remove the Buy Now or Add to Cart button and alert the appropriate internal teams, put together the necessary reporting infrastructure, and train the CS team on how and when to press the big red button. There was some concern that the big red button would be pressed too often. Selling products on a regular basis, after all, was quite important for the health of the company.

Jeff would reject what he saw as copycat thinking, emphasizing again and again that whatever music product we built, it had to offer a truly unique value proposition for the customer.

The other key feature we debated was the use of E Ink, a nascent technology. It had been developed in the MIT Media Lab and spun out as a company in 1997, but there were no major commercial applications in 2005. Although Jeff and the team were unified in their desire to use the new E Ink technology,2 we recognized there would be some trade-offs. E Ink screens were black-and-white only, so the Kindle could not support color graphics or video. The transition from one page to the next was slow.

The Kindle went on sale for the first time on November 19, 2007. It retailed for $399 and featured a six-inch screen, a keyboard, and 250 MB of memory, enough to hold about two hundred non-illustrated books.3 It sold out so astonishingly quickly—in less than six hours

Jeff would say something like this to a leader who had just laid an egg: “Why would I fire you now? I just made a million-dollar investment in you. Now you have an obligation to make that investment pay off. Figure out and clearly document where you went wrong. Share what you have learned with other leaders throughout the company. Be sure you don’t make the same mistake again, and help others avoid making it the first time.”

in January 2007, Netflix launched its video streaming service, then called Watch Now, inaugurating one of the most profound changes in the history of the entertainment industry.

After the launch, as we monitored the response, we had another surprise. Some of our biggest customers were not affiliates and not outsiders of any kind. They were Amazon software engineers. They found Amazon Web Services easier to use than some of our existing internal software tools they had been working with to build amazon.com. At this point there was little doubt that web services were going to become a new way of building things.

In several of the Working Backwards documents for the early AWS products, the PR/FAQ stated that we wanted the student in a dorm room to have access to the same world-class computing infrastructure as any Amazon software engineer. That powerful metaphor in the PR/FAQ document really helped crystallize the thoughts and ideas of the AWS product development teams.

Focus on controllable input metrics. Amazon is relentless about identifying metrics that can be controlled and have the greatest impact on outputs such as free cash flow per share. This is not an easy process, because it requires patient trial and error as you seek the input metrics that best allow you to assume control of your desired results.

Move to an organizational structure that accommodates autonomous teams with single-threaded leaders. As noted in chapter three, this takes time and requires careful management, as it invariably raises questions about authority and power, jurisdiction, and “turf.” You’ll also have to be on the lookout for dependencies and roadblocks that are preventing autonomy in your organization. But it can be done. Start with your product development group, and then see what other areas, if any, work better in teams.