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

by Colin Bryar

I worked with him during his regular office hours from ten in the morning to seven in the evening. Most days entailed between five and seven meetings with product or executive teams. Before and after Jeff’s office hours I worked with those teams to help them prepare for their interactions with him so they’d be more productive for everyone.

Note the shape of the day, not the hours. Meetings with product/exec teams vs 1:1s, e.g.

Jeff often used an analogy in those days when describing our efforts to innovate and build new businesses. “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.”

People often ask, “How do you remember all 14 principles?” The answer is not that we are particularly good at memorization. In fact, if a company’s principles must be memorized, it’s a warning sign that they aren’t sufficiently woven into the fabric of that company. We know and remember Amazon’s principles because they are the basic framework used for making decisions and taking action.

How do we make our culture/virtues a core framework of our decision making across the company, in every team?

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.

Clarity around where we're setting the bar re aggressiveness of a goal.

For example, during the period when we were transitioning to autonomous teams (more in chapter three), we sought to hire fewer people in coordinator roles while ramping up our search for builders and inventors. That required new and more specific language in the JDs. Until the JDs were revised, we received too many résumés from people whose skills included such things as “coordinated between teams,” and these would be discarded.

Importance of aligning incentives (hiring, promotion, compensation) with desired outcomes

The Reference Check has been de-emphasized in today’s Bar Raiser process since it has rarely affected a hiring decision,

In another case, a simple tweak to the Bar Raiser process generated surprisingly positive results. One director wanted to increase the gender diversity of the team. Over the ensuing quarters, the efforts were so successful that they were noticeable outside the department. When asked how they did it, the team revealed their very simple solution: every résumé received from a female applicant automatically led to a phone screen. It’s important to say that this solution did not lower the hiring bar, nor did it favor unqualified candidates on the basis of gender. If the candidate did not pass the phone screen, they would not move forward to the next step in the process.

Very interesting! Should consider adopting this.

The toughest job for many project teams was to accurately predict consumer behavior. Time and time again, we learned that consumers would behave in ways we hadn’t imagined during the development phase—especially for brand-new features or products. Even the most rigorous models we used to predict consumer adoption could be well off the mark, leading to long, vigorous debates that never quite felt conclusive. (See, for example, our story of the Fire Phone in the introduction to part two. It’s not like we thought, “Here’s a dud, but we’re going to launch it anyway.” We had high expectations for this product in which we had invested a great deal of time and money!)

Emphasizes the significance of gaining accurate customer signal. Painted-door experiments, direct customer feedback throughout product development, etc.

Autonomous teams are built for speed. When they are aligned toward a common destination, they can go a long way in a short time. But when they are poorly aligned, the team can veer far off course just as quickly. So they need to be pointed in the right direction and have the tools to quickly course-correct when warranted. That’s why, before any proposed two-pizza team was approved, they had to meet with Jeff and their S-Team manager—often more than once—to discuss the team’s composition, charter, and fitness function.

Ties into an earlier highlight about the shape of Jeff's days - meeting with product and exec teams to iterate on mission, KPIs, and relative priorities. (This is at the level of creating a team and how it measures progress, not quarterly OKRs for an individual team.)

Importantly, the specifics of how the proposed team would go about achieving its goal were not discussed at the meeting. That was the team’s role to figure out for themselves.

Autonomy - delegate the "how"

One significant lesson became clear fairly early: each team started out with its own share of dependencies that would hold them back until eliminated, and eliminating the dependencies was hard work with little to no immediate payback. 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.

Create the platform to enable moving fast. Enable data to connect actions to results and learn.

Q: Why not distribute the narrative ahead of the meeting so we’re ready? A: The short time between distribution and the meeting might not give all attendees sufficient time for that task. Also, since the document replaces the deck, no time is lost by dedicating this phase of the meeting to a silent reading that brings everybody up to speed before Q&A begins. Last but certainly not least, this gives each presenting team the most possible time to complete and refine their presentation.

Narratives are designed to increase the quantity and quality of effective communication in your organization—by an order of magnitude over traditional methods. Creating such solid narratives requires hard work and some risk-taking. Good ones take many days to write. The team writing the narrative toils over the topic, writes its first draft, circulates and reviews and iterates and repeats, then finally takes the vulnerable step of saying to their management and their peers, “Here’s our best effort. Tell us where we fell short.” At first this openness can prove intimidating.

Note that "the team" writes the narrative and obtains external feedback from peers / execs that helps the idea move forward. Shared ownership.

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. The product team meetings usually took up a plurality of the available hours in the week.

Note the focus on product. Wonder about the frequency of meeting with any given product team, considering the scale of Amazon at the time.

But Kindle had not started out that way. In the early stages of its development—before we got started on the press release approach and when we were still using PowerPoint and Excel—we had not described a device that could do all these things from the customer perspective. We had focused on the technology challenges, business constraints, sales and financial projections, and marketing opportunities. We were working forward, trying to invent a product that would be good for Amazon, the company, not the customer.

Consumer Needs and Total Addressable Market (TAM) How many consumers have this need or problem? How big is the need? For how many consumers is this problem big enough that they are willing to spend money to do something about it? If so, how much money would they be willing to spend? How many of these consumers have the characteristics/capabilities/constraints necessary to make use of the product?

Some of the best new product proposals set a not-to-exceed price point because it forces the team to innovate within that constraint and face the tough trade-offs early on. The problem(s) associated with achieving that price point should be fully explained and explored in the FAQ.

Feasibility What are the challenging product engineering problems we will need to solve? What are the challenging customer UI problems we will need to solve? What are the third-party dependencies we will need to solve? How will we manage the risk of the up-front investment required?

The fact that most PR/FAQs don’t get approved is a feature, not a bug. Spending time up front to think through all the details of a product, and to determine—without committing precious software development resources—which products not to build, preserves your company’s resources to build products that will yield the highest impact for customers and your business.

How to increase predictability. Takes more resources from user research & viability — product, design — to focus up-front on discovery, so we can test a whole lot of ideas and then discard most of them to focus our efforts.

As your fundamental understanding of what drives the business improves, it’s common for the WBR to become an exception-based meeting rather than a regular one for discussing each and every metric.

One may wonder, at what level is it appropriate for executives to shift focus to output metrics? After all, companies and their senior executives are routinely judged by output metrics like revenue and profit. Jeff knows this well, in part based on his time spent working at a Wall Street investment firm. The simple answer is that the focus does not shift at any level of management. Yes, executives know their output metrics backward and forward. But if they don’t continue to focus on inputs, they lose control over and visibility into the tools that generate output results. Therefore, at Amazon, everyone from the individual contributor to the CEO must have detailed knowledge of input metrics to know whether the organization is maximizing outputs.

With a sizable existing business, if you only pay attention to the output metric “revenue,” you typically won’t see the effects of new customer deceleration for quite some time. However, if you look at input metrics instead—things like “new customers,” “new customer revenue,” and “existing customer revenue”—you will detect the signal much earlier, and with a much clearer call to action.

Collectively, we should have recognized that many of the areas being measured were not yet operationally under control and predictable. Many of the teams had skipped the first three DMAIC steps—define, measure, analyze—in an attempt to operate at the Improve stage. They ended up chasing blips on a graph with not much to show for their effort. We should have—politely and constructively!—recommended they do the necessary legwork to convert their metrics from noise to signal.

The relevance of Customer Obsession becomes evident in the company’s focus on input versus output metrics. If you look at the input metrics for Amazon, they often describe things customers care about, such as low prices, lots of available products, fast shipping, few customer service contacts, and a speedy website or app. A lot of the output metrics, such as revenue and free cash flow, are what you’d typically see in a company’s financial report. Customers don’t care about those.

Of course, Jeff also wrote in that same shareholder letter, “I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment. Most large organizations embrace the idea of invention, but are not willing to suffer the string of failed experiments necessary to get there.”

The magnitude of your inventions, and therefore your mistakes, needs to grow in lockstep with the growth of your organization. If it doesn’t, your inventions will likely not be big enough to move the needle.

Big companies tend to develop a decision-making process that is designed to manage one-way door decisions, precisely because poor decisions can lead to big problems, even disaster. The process is typically slow, cumbersome, and riddled with risk aversion. This process tends to become the dominant one in large companies, and it is routinely, almost thoughtlessly, applied to two-way door decisions. The result is reduced speed, impaired idea generation, stifled innovation, and longer development cycles.

There were times when we had heated debates about what products to build and how we should build them. Should we focus on books, music, or video? Should we build a subscription service, make it free with advertisements, let people buy à la carte, or all of the above? Should we build our own devices or partner with manufacturers? Should we acquire companies to accelerate our entry into digital? Throughout the organization, leaders, including some members of the board of directors, questioned why we should invest so much time, effort, and money on digital media. For as you’ll see, the skills required to succeed in digital media are quite different from what’s needed to excel at delivering physical goods sold online. But we (the leaders and members of the digital media team) were persistent, always ready to reinvent our approach, change our tactics, and iterate on our strategy. We were guided by an unwavering long-term goal—to create a large digital media business that invested in new services (and devices) that consumers loved—and by Jeff’s ever-present reminder that no matter what we did, we had to constantly push to figure out the right experience for our customers. It would take several years for our digital effort to gain a foothold and become a meaningful business.

Over our long march to building Amazon’s digital business, we proved a powerful lesson: it takes exceptionally patient and unwavering leadership to persevere through the prolonged process of building a new business and navigating through transformative times in an established industry with entrenched interests. The fact that we entered as total beginners and emerged as industry leaders is in no small part a result of our adherence to being Amazonian in our principles and our way of thinking, including thinking big, thinking long-term, being obsessed with customers, being willing to be misunderstood for long periods of time, and being frugal—principles that few companies are capable of maintaining in the face of quarterly reporting requirements and the daily gyrations of the stock market.

In other words, his first action was not a “what” decision, it was a “who” and “how” decision. This is an incredibly important difference. Jeff did not jump straight to focusing on what product to build, which seems like the straightest line from A to B. Instead, the choices he made suggest he believed that the scale of the opportunity was large and that the scope of the work required to achieve success was equally large and complex. He focused first on how to organize the team and who was the right leader to achieve the right result.

This change would be one of the first major examples of the single-threaded leader org structure concept at Amazon. Before Steve moved over to head Digital, the most senior leader of the digital media business was a product manager, four levels below Steve. There was no way that someone at that level could lead and develop the kinds of new products and initiatives that we would launch in the coming years. For this to become one of Amazon’s biggest and most important businesses, Jeff needed Steve, an experienced and proven vice president (now promoted to senior vice president), reporting to Jeff, single-threaded on digital.

To work through the details of our approach to digital books, music, and video, we spent roughly six months researching the digital media landscape and meeting as a leadership team with Jeff on a weekly basis to review and brainstorm countless ideas and concepts.

Many companies that decide to enter a business area in which they have little internal expertise or capability choose to outsource, as happened in the early days of e-commerce when brick-and-mortar retailers created their first online retail sites. They brought in third-party developers, consultants, and sometimes both. This approach enabled them to move much more quickly. But it deprived them of the flexibility to innovate and differentiate, and to continuously incorporate customer desire.

If we had outsourced the work and succeeded in creating the first great reader device, much of the knowledge and know-how would accrue outside Amazon, in the minds and methods of the outsourcer. Since the kind of partner we would need was typically in the business of building custom spec hardware for a wide range of clients, not just us, the outsourcer might further develop the technology and eventually offer a comparable or even better reader to other companies, including our competitors. We wanted to be the keepers of the intellectual property.

One year earlier, that same business had been growing by 15 percent year over year. From 15 to 12 is a 20 percent drop in growth rate. Every other product segment was experiencing the same slow decline—growing more slowly than before.

Relying on promotions over the long term can be a slippery slope for any retailer, especially one-off promotions. There is danger in training your customers to delay purchases until the next deal comes along.

We didn’t want to come in second to Apple so we were in a frenzy to ship Unbox and ship it fast. This was directly antithetical to the notion of focusing on the customer, not the competitor.

We had conducted an internal employee-only beta test, but we failed to use the results as an opportunity to slow down, carefully review the customer feedback, and take the time needed to make real changes to improve the quality of the customer experience. We were just focused on shipping. We had prioritized speed, press coverage, and competitor obsession over the customer experience.

it became increasingly clear to us that the digital media business was very different from our online physical goods retail business. We did not have full control of the content (movies and TV shows) we were selling. We did not have proprietary or unique content, as Netflix did. Nor did we have control of the devices people used to play and display content, as Microsoft, Sony, and Apple did. The inputs to the Amazon flywheel of growth—low prices, faster delivery, lower cost structure—were not dimensions along which we could differentiate from our competitors if we only offered an à la carte digital video store. There was one aspect of the process, however, that did require technical skill: building applications that functioned well on a range of TVs and set-top devices and delivered high-quality video without crashing or constant rebuffering. That’s why we eventually purchased a small London-based software engineering shop called Pushbutton.

Jeff argued that even if we offered streaming videos to Prime members at no additional cost, the business could still be profitable in the long run. (Long-term thinking = being Amazonian.) How? A streaming subscription service is a fixed-cost business. When Netflix licensed a movie or TV series from a studio, they paid a fixed fee. The amount was not based on usage. Netflix customers could watch the video once or ten million times, the costs were the same. Yes, there were some variable costs involved, for bandwidth and servers, but these costs amounted to pennies per view. And, as with most technology, those costs declined over time.

The major benefit of establishing a popular subscription service with a fixed-cost base is that once you exceed a certain number of subscribers, every new dollar of subscription revenue is pure profit. The hard parts of pulling off this strategy are (a) acquiring a large number of subscribers, and (b) building a catalog of must-see movies and TV series.

This experience crystallized our thinking about the value chain. It seemed to me that going forward we had to get out of the never-ending cycle of bidding against Netflix and, later, Hulu. We didn’t want to pay studios additional fees for each and every country we entered. We had to control our own destiny. That led me to a startling conclusion: we had to create our own content. It was time to make our own movies and TV shows.

We did add one interesting new wrinkle. We made all the pilots available to view for free on Amazon before making a decision as to which to greenlight. Through this process, we were able to gather viewership data and ratings and reviews from real customers in order to make better-informed decisions about which shows would attract the most viewers. So, after all, we did find a way to make the process more customer centric than the studios’, and therefore more Amazonian.

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.

We had to adjust our model to account for all the dimensions of resource usage so that AWS could be a sustainable business.8

Defining the basics of the culture, articulating leadership principles, regularizing essential practices—Bar Raiser hiring, teams with single-threaded leaders, written narratives, Working Backwards, focusing on input metrics—all these things have proved to be essential to us in other endeavors. Indeed, we can’t imagine doing business without them.

For the company, then, failure is typically viewed as an experiment from which a great deal can be learned that can lead to change and improvement. Very often, failure is temporary and eventually gives birth to success.

What do I actually do to bring some of the aspects of being Amazonian into my business?” Here are a few suggestions: Ban PowerPoint as a tool to discuss complicated topics and start using six-page narratives and PR/FAQ documents in your leadership team meetings. This can be implemented almost instantly. There will be pushback and grumbling, but we’ve found it produces results swiftly, and eventually your leaders will say to themselves, “We can never go back to the old way.”

Establish the Bar Raiser hiring process. This approach is no longer unique to Amazon and we have seen it work in many companies. It too can be established relatively quickly, once a training process is in place. It also delivers short-term results by improving the quality of the process and enabling learning for everyone involved in the loop. It should reduce the number of poor hires and, in the long run, improve the overall quality of thinking and performance in each team, and in the company as a whole.

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. Note too that this is not an ar...