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

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.

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

Third, there were two large book-distribution companies, Ingram and Baker & Taylor, that acted as intermediaries between publishers and retailers and maintained huge inventories in vast warehouses. They kept detailed electronic catalogs of books in print to make it easy for bookstores and libraries to order from them. Jeff realized that he could combine the infrastructure that Ingram and Baker & Taylor had created—warehouses full of books ready to be shipped, plus an electronic catalog of those books—with the growing infrastructure of the Web, making it possible for consumers to find and buy any book in print and get it shipped directly to their homes.

If, for example, a person spoke up at a meeting and suggested an idea that was obviously geared toward short-term considerations and ignored significant longer-term ones, or proposed something that was competitor- rather than customer-centric, there would be an uncomfortable pause before someone pointed out what was on everyone else’s mind. While this practice may not be unique to Amazon, it is a defining element of its success.

“You can write down your corporate culture, but when you do so, you’re discovering it, uncovering it—not creating it.”

For example, the Insist on the Highest Standards leadership principle is described like this: “Leaders have relentlessly high standards—many people may think these standards are unreasonably high.” The words “relentlessly” and “unreasonably high” are distinctly Jeff-ian and therefore Amazonian ways of thinking and speaking.

The Door Desk Award goes to a person who exemplifies Frugality and Invention. The Just Do It Award is an abnormally large, well-worn Nike sneaker given to employees who exhibit a Bias for Action. It usually goes to a person who has come up with a clever idea outside the scope of their job. What’s peculiarly Amazonian about the award is that the idea doesn’t have to be implemented—nor does it have to actually work if it is—in order to be eligible.

Amazon realized early on that if you don’t change the underlying condition that created a problem, you should expect the problem to recur.

Three foundational mechanisms are: the annual planning process; the S-Team goals process (the S-Team consists of the senior vice presidents and direct reports to Jeff Bezos); and Amazon’s compensation plan, which aligns incentives with what’s best for customers and the company over the long term.

Three notably Amazonian features of S-Team goals are their unusually large number, their level of detail, and their aggressiveness. S-Team goals once numbered in the dozens, but these have expanded to many hundreds every year, scattered across the entire company.

Reviews are conducted in multihour S-Team meetings scheduled on a rolling basis over the quarter rather than all at once. 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.”

finance team tracks the S-Team goals throughout the year with a status of green, yellow, and red. Green means you are on track, yellow means there is some risk of missing the goal, and red means you are not likely to hit the goal unless something meaningful changes.

Second, no loop participant should be more than one level below the level of the position the candidate will hold. Nor should there be an interviewer who would become a direct report of the candidate. People often want to have a say in hiring their manager and may be upset if they are excluded from the process, but it is a mistake for direct reports to interview a prospective boss. It’s uncomfortable for the candidate during the interview, and the direct report will learn about the candidate’s weaknesses, and other employees’ views of those weaknesses, during the debrief—which could lead to problems for the future functioning of the team. Also, nothing good happens if a future direct report is not inclined to hire the candidate and you hire that person anyway.

Other questions that can reveal this information include “If you were assigned to work on a different project instead of Project X, what would have changed about Project X?” and “What was the toughest call on Project X, and who made it?”

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

A two-pizza team will: Be small. No more than ten people. Be autonomous.

Be evaluated by a well-defined “fitness function.”

Be monitored in real time.

Be the business owner.

Be led by a multidisciplined top-flight leader.

Be self-funding.

Be approved in advance by the S-Team.

I participated in every one of the Fitness Function alignment meetings for the first set of two-pizza teams, which owned things like Forecasting, Customer Reviews, and Customer Service Tools. We questioned every metric from every angle, probing how those data would be collected and how the results would be used to drive the team accurately toward its goals. These meetings clearly established expectations and confirmed the team’s readiness. Just as importantly, they also built up trust between Jeff and the new team, reinforcing their autonomy—and therefore their velocity.

started with a small number of two-pizza teams so that we could learn what worked and refine the model before widespread adoption.

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.

They also built systems to track every important event that happened in their area at a detailed, real-time level. Their business results didn’t improve much while they did so, but once they had removed dependencies, built their fitness function, and instrumented their systems, they became a strong example of how fast a two-pizza team could innovate and deliver results. They became advocates of this new way of working.

We found it helpful to think of such cross-functional projects as a kind of tax, a payment one team had to make in support of the overall forward progress of the company.

The Order Pipeline and Payments teams, for example, had to be involved in almost every new initiative, even though it wasn’t in their original charters.

The original idea was to create a large number of small teams, each under a solid, multidisciplined, frontline manager and arranged collectively into a traditional, hierarchical org chart. The manager would be comfortable mentoring and diving deep in areas ranging from technical challenges to financial modeling and business performance. Although we did identify a few such brilliant managers, they turned out to be notoriously difficult to find in sufficient numbers, even at Amazon.

We found instead that two-pizza teams could also operate successfully in a matrix organization model, where each team member would have a solid-line reporting relationship to a functional manager who matched their job description—for example, director of software development or director of product management—and a dotted-line reporting relationship to their two-pizza manager.

Sometimes You Need More Than Two Pizzas 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. Now free of its initial size limits, the two-pizza team clearly needed a new name.

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

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? If the answer is no, then one solution is to carve out a small piece of functionality that can be autonomous and repeat.

In his essay, Tufte proposed a solution. “For serious presentations,” he wrote, “it will be useful to replace PowerPoint slides with paper handouts showing words, numbers, data graphics, images together. High-resolution handouts allow viewers to contextualize, compare, narrate, and recast evidence. In contrast, data-thin, forgetful displays tend to make audiences ignorant and passive, and also to diminish the credibility of the presenter.”

Heading: Name the product in a way the reader (i.e., your target customers) will understand.

Subheading: Describe the customer for the product and what benefits they will gain from using it. One sentence only underneath the heading.

Summary Paragraph: Begin with the city, media outlet, and your proposed launch date. Give a summary of the product and the benefit.

Problem Paragraph: This is where you describe the problem that your product is designed to solve. Make sure that you write this paragraph from the customer’s point of view.

Solution Paragraph(s): Describe your product in some detail and how it simply and easily solves the customer’s problem. For more complex products, you may need more than one paragraph.

Quotes and Getting Started: Add one quote from you or your company’s spokesperson and a second quote from a hypothetical customer in which they describe the benefit they are getting from using your new product. Describe how easy it is to get started, and provide a link to your website where customers can get more information and purchase the product.

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?

Economics and P&L What are the per-unit economics of the device? That is, what is the expected gross profit and contribution profit per unit? What is the rationale for the price point you have chosen for the product? How much will we have to invest up front to build this product in terms of people, technology, inventory, warehouse space, and so on?

Dependencies How will we convince couriers (USPS, UPS, FedEx, Amazon Fulfillment, Instacart, etc.) to actually use this device instead of their current/standard delivery methods? How will we ensure that couriers (who don’t work for you and over whom you have no control) will use the Melinda UI properly and bother to actually put packages in it instead of just leaving the package by the front door like they typically do? Won’t it take more time (which is precious) for them to make a delivery than it does today? What third-party technologies are we dependent on for Melinda to function as promised?

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?

number of detail pages, which we refined to number of detail page views (you don’t get credit for a new detail page if customers don’t view it), which then became the percentage of detail page views where the products were in stock (you don’t get credit if you add items but can’t keep them in stock), which was ultimately finalized as the percentage of detail page views where the products were in stock and immediately ready for two-day shipping, which ended up being called Fast Track In Stock.

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.

Mistakes should be a learning experience for all. If people become afraid of pointing out their own mistakes because they will feel humiliated in front of their peers, it’s human nature for them to do whatever they can to hide those mistakes in future meetings. Variances that get glossed over are lost learning opportunities for everybody. To prevent this, mistakes should be acknowledged as a chance to take ownership, understand the root cause, and learn from the experience. Some tension is unavoidable and appropriate, but we think it’s better to establish a culture where it’s not just okay, it’s actually encouraged to openly discuss mistakes.

Zooming In: Weekly and Monthly Metrics on a Single Graph As we noted above, at Amazon we routinely place our trailing 6 weeks and trailing 12 months side by side on the same x-axis. The effect is like adding a “zoom” function to a static graph that gives you a snapshot of a shorter time period, with the added bonus that you’re seeing both the monthly graph and the “zoomed-in” version of it simultaneously.