Working Backwards (Amazon Decision Making)

Books · Management

URL

Working Backwards

Summary

This was a summary of Amazon's operational principles, written by two senior insiders. The first half of the book lays out these principles, while the second half talks about how they were applied within the organization

I found the first half super useful and well-written, but the second half was lacking. My main takeaways were:

1. Define operating principles for key leaders in your organization and make sure they stick to it
2. Ensure that you have a structured processing for hiring. In an interview, if you ask inane questions like: “Tell me something about yourself that isn’t apparent by reading your résumé.” You might as well just say, “Look, I don’t know what I’m looking for or how to find it, so can you please help me out?”
3. Ensure that your leaders and key teams are responsible for doing one thing and one thing only. The best way to fail at inventing something is by making it somebody’s part-time job. Have separable teams with single-threaded leaders. Separable means almost as separable organizationally as APIs are for software. Single-threaded means they don’t work on anything else
4. Using narratives and the written word to develop and communicate ideas can help you identify flaws in ideas before you execute them. Don't rely on oral, power-point based presentations. Removing the natural variance in speaking skills and graphic design expertise can help you get to the innate quality of an idea (unaffected by the charisma or lack thereof of the presenter) quicker
5. Start with the desired customer experience when coming up with new product ideas. Start by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build. Create the press release and Frequently Asked Questions (FAQs) for a product before you put any engineering effort into it
6. Don't try to optimise for output variables (like sales, or valuation). You can't control them. Instead, create a strong model of how variables you can control (input variables) map to the output variables. Then, optimise the input variables that you can actually control
7. Use data and dashboards effectively to keep track of matrics. With so many metrics to review, written narrative or explanatory notes would undercut the efficiency of the read-through. Instead, stick to charts, graphs, and data tables.
8. Outsourcing can often have devastating long-term implications. Much of the knowledge and know-how accrues in the minds and methods of the outsourcer. Never outsource critical IP or knowhow. Specially when you need to continually iterate on the product

Highlights

Introduction

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

Though the books, CD, and VHS/DVD business was Amazon’s most popular, changes in internet and device technology, as well as the emergence of Napster and Apple iPod/iTunes, made it clear that this would not last. We expected that the physical media business would decline over time due to the shift to digital. We felt we had to act right

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

You can take the elements that you need as you need them, then tweak and customize them as conditions warrant. The concept also has a wonderful fractal quality, meaning it can add benefit at any scale. We

In the very early days of the company, Jeff was the leadership principles. He wrote the job descriptions, interviewed candidates, packed and shipped boxes, and read every email that went out to customers. Taking part in every aspect of the business allowed him to communicate the Amazon philosophy informally to the relatively small group of employees.

But the company expanded so quickly that it was soon impossible to communicate it that way anymore. Thus, the need for the Leadership Principles.

One of the major pitfalls of needing to hire a lot of new people very quickly is urgency bias: the tendency to overlook a candidate’s flaws because you are overwhelmed with work and need bodies. The Bar Raiser provides teams with methods to make the strongest hires efficiently and quickly, but without cutting corners.

single-threaded leadership The basic premise is, for each initiative or project, there is a single leader whose focus is that project and that project alone, and that leader oversees teams of people whose attention is similarly focused on that one project.

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.

how new ideas and products are developed at Amazon: Working Backwards from the desired customer experience. Before we start building, we write a Press Release to clearly define how the new idea or product will benefit customers, and we create a list of Frequently Asked Questions to resolve the tough issues up front.

The customer is also at the center of how we analyze and manage performance metrics. Our emphasis is on what we call controllable input metrics, rather than output metrics.

Amazon should always underpromise and overdeliver, to ensure that customer expectations were exceeded. Postal Service First-Class Mail. In actuality, all these shipments were sent by Priority Mail—a far more expensive option that guaranteed delivery within two to three business days anywhere in the United States.

This was called out as a complimentary upgrade in the shipment-confirmation email.

The job description he wrote for his very first employee said, “You must have experience designing and building large and complex (yet maintainable) systems, and you should be able to do so in about one-third the time that most competent people think possible.”

Amazon’s Leadership Principles

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

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 standards—many people may think these standards are unreasonably high. Leaders are continually raising the bar and drive their teams to deliver high-quality products, services, and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

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.

Bias for Action. Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk-taking.

Frugality. Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense

Frugality. Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense.

Earn Trust. Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.

Dive Deep. 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.

Have Backbone; Disagree and Commit. Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

Deliver Results. Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

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

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.

Annual Planning Process

Once these high-level expectations are established, each group begins work on its own more granular operating plan—known as OP1—which sets out the individual group’s “bottom-up” proposal. The main components of an OP1 narrative are: Assessment of past performance, including goals achieved, goals missed, and lessons learned Key initiatives for the following year A detailed income statement Requests (and justifications) for resources, which may include things like new hires, marketing spend, equipment, and other fixed assets

Each group works in partnership with its finance and human resources counterparts to create their detailed plan, which is then presented to a panel of leaders.

The panel then reconciles any gaps between the bottom-up proposal and the top-down goals the group has been asked to meet. Sometimes a team may be asked to rework its plan and re-present it until there’s agreement between the top-down goals and bottom-up plan.

In January, after the holiday season ends, OP1 is adjusted as necessary to reflect the fourth-quarter results, as well as to update the trajectory of the business. This shorter process is called OP2, and it generates the plan of record for the calendar year.

OP2 aligns each group with the goals of the company. Everybody knows their overall objectives, including targets for revenue, cost, and performance. The metrics are agreed upon and will be supplied as part of every team’s deliverables. OP2 makes it crystal clear what each group has committed to do, how they intend to achieve those goals, and what resources they need to get the work done.

S-Team Goals

During OP1, as the S-Team reads and reviews the various operating plans, they select the initiatives and goals from each team that they consider to be the most important to achieve.

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.

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

The OP planning process aligns the entire company on what’s truly important to accomplish for the year. S-Team goals refine that alignment by giving top priority to the company’s biggest or most pressing objectives.

The review cadence helps maintain alignment, no matter what happens along the way.

Executive Compensation

No matter how clear your leadership principles and yearly plan may be, they speak softly in comparison to financial incentives.

the compensation of Amazon S-Team members and all senior leaders is heavily weighted toward equity earned over a period of several years.

The wrong kind of compensation practice can cause misalignment in two ways: (1) by rewarding short-term goals at the expense of long-term value creation, and (2) by rewarding the achievement of localized departmental milestones whether or not they benefit the company as a whole.

In other industries, such as media and financial services, a large percentage of executive compensation is doled out in annual performance bonuses. These short-term goals (and yes, a year is definitely short term) can generate behaviors that are detrimental to creating long-term value.

One clear downside to this approach is that other companies with deep pockets can try to hire away your best employees with big cash offers. It’s true, some employees leave for a short-term jump in their cash compensation.

Hiring and Bar-Raisers

If you say: “Tell me something about yourself that isn’t apparent by reading your résumé.” You might as well just say, “Look, I don’t know what I’m looking for or how to find it, so can you please help me out?”

Jeff often said in those days, “We want missionaries, not mercenaries.” We have all encountered mercenaries in our career. They are in it to make a fast buck for themselves, they don’t have the organization’s best interests at heart, and they don’t have the resolve to stick with your company through challenging times. Missionaries, as Jeff defined the term, would not only believe in Amazon’s mission but also embody its Leadership Principles. They would also stick around: we wanted people who would thrive and work at Amazon for five-plus years, not the 18–24 months typical of Silicon Valley.

what’s wrong with the conventional approach.

Even the smartest interviewer can wander off script and ask questions that lack a clear objective, leading to answers that reveal nothing about a candidate’s likely job performance. Interviewer feedback is often communicated to the broader team with insufficient clarity and unintentional bias. Focusing on candidate qualities that don’t reliably predict performance can also skew decisions in the wrong direction. Unstructured hiring decision meetings can give rise to groupthink, confirmation bias, and other cognitive traps that feel right at the time but produce poor decisions.

Several significant flaws appear in this hiring process. First, the fact that the team members shared their thoughts after each interview increased the likelihood that subsequent interviewers would be biased. And Carson’s failure to immediately write up his assessment meant that the group was deprived of the wisdom of its most experienced and insightful team member.

urgency bias that affected the whole process. With a key position glaringly open, and a critical employee doing double duty to cover, the whole team felt time pressure that compelled them to accentuate the positive and to overlook some shortcomings in the process.

Brandon’s evaluation, for example, showed that his interview questions had lacked specificity and purpose. He commented that Joe “has a solid background owning and driving strategy” but did not provide any detailed, credible examples of what Joe actually had accomplished in that regard.

The group had also succumbed to some serious confirmation bias—the tendency for people to focus on the positive elements that others identify and ignore the negatives and contradictory signals.

The feedback meeting itself had been relatively unstructured, which had given rise to groupthink among a team that valued each other’s approval and wanted to help solve the problem by making a hire.

The Effects of Personal Bias and Hiring Urgency There are other types of cognitive biases that affect the hiring process. Another harmful one is personal bias, the basic human instinct to surround yourself with people who are like you.

The problems with this approach are obviously (1) that such superficial similarities typically have nothing to do with performance, and (2) hiring for them tends to make for un-diverse workforces with a narrower field of vision.

It takes almost no time to spot the superstars and to weed out the duds, but the majority of candidates, alas, falls somewhere in between, and that is when biases tend to kick

Another force that works against successful hiring is the lack of a formal process and training. Startups and rapidly growing companies are particularly likely to hire new people without a process in place, though all too many more-established companies have the same problem.

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

Like all good processes, it’s simple to understand, can be easily taught to new people, does not depend on scarce resources (such as a single individual), and has a feedback loop to ensure continual improvement.

Amazon’s Bar Raiser process was designed to provide that framework, minimize the variability of ad hoc hiring processes, and improve results.

There are eight steps in the Bar Raiser hiring process:

• Job Description
• Résumé Review
• Phone Screen
• In-House Interview
• Written Feedback
• Debrief/Hiring Meeting
• Reference Check
• Offer Through Onboarding

Job Description

At Amazon, it is the hiring manager’s responsibility to write the description, which the Bar Raiser can review for clarity. A good job description must be specific and focused.

If the JD is for a new position, members of the interview loop often begin by meeting with the hiring manager and Bar Raiser to review the description and ask clarifying questions.

most hiring managers are desperate to get the process started, and without this review process, they tend to get fuzzy and/or out-of-date job descriptions. It is very hard to recover from this mistake. The hiring process will inevitably run into trouble—even fail—if the JD does not clearly articulate the job responsibilities and required skills. The people doing the phone screens and in-person interviews need to be clear on the JD so they can ask the right questions to collect the information required to make their decision.

Résumé Review

If the selected candidates as a result of this are off target, the JD probably needs work.

Phone Screen

During the phone screen, the hiring manager describes the position to the candidate in detail and seeks to establish some rapport with them by describing their own background, and why they chose to join Amazon. Roughly 45 minutes of that hour should consist of the manager questioning the candidate and following up where necessary.

The questions, formulated in advance by the hiring manager, are designed to solicit examples of the candidate’s past behavior (“Tell me about a time when you…”) and focus on a subset of the Amazon Leadership Principles.

The hiring manager should not bring a candidate in for the time-consuming and expensive interview loop unless they are inclined to hire them after the phone interview.

In-House Interview Loop

The in-house interview loop takes five to seven hours to complete and requires the participation of several people who undoubtedly have many other responsibilities and tasks on their plate, so this step must be carefully planned, prepared, and executed.

Typically, the most effective loops consist of five to seven interviewers. Whatever the exact number of participants, the loop always includes the hiring manager, the recruiter, and a Bar Raiser.

everyone must have been properly trained in the company’s interviewing process. Amazon runs a half-day course on how the interview process works and how to conduct an interview

After training, the interviewer is required to pair up with an experienced senior interviewer to jointly conduct at least one real interview before they do one on their own. Second, no loop participant should be

After training, the interviewer is required to pair up with an experienced senior

After training, the interviewer is required to pair up with an experienced senior interviewer to jointly conduct at least one real interview before they do one on their own.

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.

There are two distinctive features in an Amazon in-house interview loop: behavioral interviewing and Bar Raiser.

Behavioral Interviewing

This involves assigning one or more of the 14 Leadership Principles to each member of the interview panel, who in turn poses questions that map to their assigned leadership principle, seeking to elicit two kinds of data.

First, the interviewer wants the candidate to provide detailed examples of what they personally contributed to solving hard problems or how they performed in work situations like the ones they will experience at Amazon. Second, the interviewer wants to learn how the candidate accomplished their goals and whether their methods align with the Amazon Leadership Principles.

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.

Instead the questions are mapped to their assigned principles.

After the candidate answers, the interviewer probes further. Each follow-up question is designed to acquire specific information, which is particularly important in determining exactly what role the candidate played in some past accomplishment.

The method that Amazon interviewers use for drilling down goes by the acronym STAR (Situation, Task, Action, Result):

Interviewers are also trained to maintain control of the interview. We’ve all been in a situation where the candidate, perhaps seeking to avoid a question, goes on long detours designed to deflect.

In such cases, interviewers know to politely cut the candidate short and move on to the next question.

The Bar Raiser

In addition to conducting one of the interviews, the Bar Raiser coaches others on interviewing techniques, asks probing questions in the debrief, makes sure that personal biases do not affect the hiring decision, and determines whether the candidate meets or exceeds the hiring bar set by the company.

Written Feedback

Some interviewers create a document with the questions, which they use to record notes.

Some enter the notes in their computer, while others write them longhand on paper or on the back of the candidate’s résumé.

If you do not take complete and detailed notes, expect a visit from your Bar Raiser.

Written feedback is expected to be specific, detailed, and filled with examples from the interview to address the Leadership Principles assigned to the interviewer. The feedback should be written shortly after the interview is complete to ensure that nothing of value is forgotten.

this is not an optional exercise at Amazon: oral feedback offered in lieu of the written is simply unacceptable.

The written feedback includes the interviewer’s vote on the candidate. There are only four options—strongly inclined to hire, inclined to hire, not inclined to hire, or strongly not inclined to hire. There is no “undecided” option.

Debrief/Hiring Meeting

Once the in-house interviews are complete and the written feedback and votes have been collected, the interviewers get together in person or via video conference to debrief and make the hiring decision.

The Bar Raiser leads the meeting, which should be held as soon as possible, usually no more than a few days after the interviews have been completed.

“Now that everyone has had a chance to read all the feedback, would anyone like to change their vote?” The reason for this is that each interviewer submitted their vote based on only the data that they gathered in their interview. In a five-person interview loop, this means that the initial vote is given while in possession of one-fifth of the data.

The meeting is concluded with a decision from the hiring manager (validated by the Bar Raiser) to hire or not hire.

It is extremely rare for a Bar Raiser to exercise their veto power.

4,000 interviews over the course of 15 years. We’ve only been able to identify three instances in which the veto was exercised. One of them came during the early days of the process in 1999. The other two involved hiring managers who were new to Amazon and had not yet adapted to the organization.

debrief meeting is an opportunity for each interviewer to learn from others and to develop their ability to assess talent.

Reference Check

The hiring manager or recruiter next asks the candidate to supply four or five references. Ideally, the references will include former managers, peers and subordinates, and others who have worked directly with the candidate, possibly for many years.

Offer Through Onboarding

At many companies, the hiring manager has the recruiter make the offer. This is another mistake. The hiring manager should personally make the offer and sell him/her on the role and company. You may have chosen the candidate, but that doesn’t mean the candidate has chosen you. You must assume that good employees are being actively pursued by other companies, including their current employer. There is always the risk that you could lose the candidate. Nothing is certain until the day they report to the office.

After the offer is made, a team member should check in with the candidate at least once a week until he or she makes a final decision. The contact can be as simple as an email saying how excited you are about the candidate joining the team. Sometimes we would send a “book bomb” to a candidate—a stack of books we thought they would like—or a handful of their favorite DVDs. It could be a coffee or lunch. What matters is that the gesture be sincere and personal.

Sometimes you’ll be surprised by what you learn. The candidate may be sold on the role and compensation, but their spouse or partner may have reservations about some aspects of the job.

Don’t be afraid to ask your VP or CEO to get involved by making contact in some way. An email or a quick phone call from a person outside the hiring team, especially a person high up in the organization, may help seal the deal.

the Amazon hiring process has a flywheel effect—it pays greater and greater dividends the longer it is used. 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!”

Organization: Single-threaded leaders

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

Scene: A conference room. Jeff and several S-Team members sit across the table from the leadership team of a large Amazon business unit, including its VP, two other VPs who report to her, and several of their directors. It’s their quarterly business review, and they’re discussing an initiative that has been stuck in “Status Red” for the past two quarters. Someone asks, “What blockers are stopping you from making progress?”

JEFF (interrupting): Before we get to those issues, would someone please tell me who’s the most senior single-threaded leader for this initiative? BUSINESS UNIT VP (after an uncomfortably long pause): I am. JEFF: But you’re in charge of the whole business unit. I want you focused on your whole group’s performance, and that includes a lot more than this one initiative. VP 1 (trying to take one for his team): That would be me, then. 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. JEFF (impatient now): Does a PM have all the skills, authority, and people on their team to get this done? VP 1: Not really, no, which is why we plan to hire a director to head it up.

JEFF: How many phone screens and in-house interviews have you conducted so far for this new director?

VP 1: Well, it’s not an open position yet. We still need to complete the job description. So the answer is, zero. JEFF: Then we’re kidding ourselves. This initiative won’t go “green” until the new leader is in place. That is the real roadblock this initiative is facing. Let’s remove that one first. VP 1 dashes off a terse email to head recruiter titled, “Open director role for project X leader…”

With all other things being equal, the organization that moves faster will innovate more, simply because it will be able to conduct a higher number of experiments per unit of time.

many companies find themselves struggling against their own bureaucratic drag, which appears in the form of layer upon layer of permission, ownership, and accountability, all working against fast, decisive forward progress.

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.

Each overlap created one kind of dependency, which describes something one team needs but can’t supply for itself. If my team’s work requires effort from yours—whether it’s to build something new, participate, or review—you’re one of my dependencies. Conversely, if your team needs something from mine, I’m a dependency of yours. 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.

while the growth in employees was linear, the number of their possible lines of communication grew exponentially.

The Cabal reviewers were understandably protective of acb and did a good job at overseeing this important company asset. Anyone who wanted to make a change to acb would have to undergo an intimidating, if well-intentioned, design review. Given the tangled state of our technical architecture, the stakes were high and many things could go wrong, so we needed these skillful, cautious gatekeepers.

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.

Better Coordination Was the Wrong Answer Resolving a dependency usually requires coordination and communication. And when your dependencies keep growing, requiring more and more coordination, it’s only natural to try speeding things up by improving your communication.

we realized that all this cross-team communication didn’t really need refinement at all—it needed elimination.

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.

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.

Morale is, in a sense, an output metric, whereas freedom to invent and build is an input metric.

First Proposed Solution: Two-Pizza Team Seeing that our best short-term solutions would not be enough, Jeff proposed that instead of finding new and better ways to manage our dependencies, we figure out how to remove them. We could do this, he said, by reorganizing software engineers into smaller teams that would be essentially autonomous, connected to other teams only loosely, and only when unavoidable.

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. With hundreds of these two-pizza teams eventually in place, Rick believed that we would innovate at a dazzling pace. The experiment would begin in the product development organization and, if it worked, would spread throughout the rest of the company.

two-pizza team will: Be small. No more than ten people. Be autonomous. They should have no need to coordinate with other teams to get their work done. With the new service-based software architecture in place, any team could simply refer to the published application programming interfaces (APIs) for other teams. (More on this new software architecture to follow.)

evaluated by a well-defined “fitness function.” This is the sum of a weighted series of metrics. Example: a team that is in charge of adding selection in a product category might be evaluated on: a)  how many new distinct items were added for the period (50 percent weighting) b)  how many units of those new distinct items were sold (30 percent weighting) c)  how many page views those distinct items received (20 percent weighting)

Be monitored in real time. A team’s real-time score on its fitness function would be displayed on a dashboard next to all the other two-pizza teams’ scores. 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.” Be

led by a multidisciplined top-flight leader. The leader must have deep technical expertise, know how to hire world-class software engineers and product managers, and possess excellent business judgment. Be self-funding. The team’s work will pay for itself. Be approved in advance by the S-Team. The S-Team must approve the formation of every two-pizza team.

Some of its tenets endured, some evolved, and some perished over the course of several years.

Tearing Down Monoliths

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.3 That’s

The First Autonomous Teams 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.

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,

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

long-term thinking, in the form of their up-front investments, generated compound returns over time. Later teams followed their lead. Sometimes it’s best to start slow in order to move fast.

other limits to autonomy would also need to remain, with each team still tied to others by varying levels of dependency. While each two-pizza team crafted its own product vision and development roadmap, unavoidable dependencies could arise in the form of cross-functional projects or top-down initiatives that spanned multiple teams. For example, a two-pizza team working on picking algorithms for the fulfillment centers might also be called upon to add support for robotics being implemented to move products around the warehouse.

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. We tried to minimize such intrusions but could not avoid them altogether.

Fitness Functions Were Actually Worse Than Their Component Metrics

We tried them out for more than a year, but fitness functions never really delivered on their promise for a couple of important reasons.

First, teams spent an inordinate amount of time struggling with how to construct the most meaningful fitness function. Should the formula be 50 percent for Metric A plus 30 percent for Metric B plus 20 percent for Metric C? Or should it be 45 percent for Metric A plus 40 percent for Metric B plus 15 percent for Metric C?

The discussions became less useful and ultimately distracting—just another argument that people needed to win.

Second, some of these overly complicated functions combined seven or more metrics, a few of which were composite numbers built from their own submetrics. When graphed over time, they might describe a trend line that went up and to the right, but what did that mean? It was often impossible to discern what the team was doing right (or wrong) and how they should respond to the trend.

eventually reverted to relying directly on the underlying metrics instead of the fitness function.

Combining them into a single, unifying indicator was a very clever idea that simply didn’t work.

Great Two-Pizza Team Leaders Proved to Be Rarities

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.

Bigger and Better Still—The Single-Threaded Leader

What was originally known as a two-pizza team leader (2PTL) evolved into what is now known as a single-threaded leader (STL). The STL extends the basic model of separable teams to deliver their key benefits at any scale the project demands. Today,

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

Separable, single-threaded teams have fewer organizational dependencies than conventional teams. They clearly demarcate the boundaries of what they own and where the interests of other teams begin and end.

Narratives and the Six-Pager

At Amazon, after a brief exchange of greetings and chitchat, everyone sits at the table, and the room goes completely silent. Silent, as in not a word. The reason for the silence? A six-page document that everyone must read before discussion begins.

Amazon relies far more on the written word to develop and communicate ideas than most companies, and this difference makes for a huge competitive advantage.

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.

The End of PowerPoint at S-Team Meetings

In the S-Team meeting, we would select between two and four S-Team goals and do a deep dive on their progress. The meeting was expensive: between preparation and attendance, it consumed at least half a day each week for the top leaders in the company.

each deep dive would begin with a presentation by the relevant team on the status of their work toward the goal. Typically, this involved an oral presentation by one or more of the team members backed up by PowerPoint slides. Too often, we found, the presentations did not serve the purpose for which they were intended. The format often made it difficult to evaluate the actual progress and prevented the presentations from proceeding as planned.

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

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.

PowerPoint can strip the discussion of important nuance.

Amazon audience of tightly scheduled, experienced executives was eager to get to the heart of the matter as quickly as possible.

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

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

real risk with using PowerPoint in the manner we did, however, was the effect it could have on decision-making. A dynamic presenter could lead a group to approve a dismal idea. A poorly organized presentation could confuse people, produce discussion that was rambling and unfocused, and rob good ideas of the serious consideration they deserved. A boring presentation could numb the brain so completely that people tuned out or started checking their email, thereby missing the good idea lurking beneath the droning voice and uninspiring visuals.

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.

Gradually, we settled on a standard format. Maximum length: six pages, no desperate tricks in formatting please. Appendices with further information or supporting detail could be attached, but would not be required reading in the meeting itself.

the public speaking skills of the presenter, and the graphics arts expertise behind their slide deck, have an undue—and highly variable—effect on how well their ideas are understood. No matter how much work a team invests in developing a proposal or business analysis, its ultimate success can therefore hinge upon factors irrelevant to the issue at hand.

Our Tenet: Ideas, Not Presenters, Matter Most

removing the natural variance in speaking skills and graphic design expertise that today plays too great a role in the success of presentations. The entire team can contribute to the crafting of a strong narrative, reviewing and revising it until it’s at its very best.

The time now spent upon crafting gorgeous, graphically elegant slide presentations can be recaptured and used for more important things.

the narrative document is infinitely portable and scalable. It is easy to circulate. Anyone can read it at any time. You don’t need handwritten notes or a vocal track recorded during the big presentation to understand its contents. Anyone can edit or make comments on the document, and they are easily shared in the cloud. The document serves as its own record.

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. If you take into account some of the other PowerPoint limitations discussed above, this multiplier only increases.

people read three times faster than the typical presenter can talk, meaning that they can absorb that much more information in a given time while reading a narrative than while listening to a PP presentation. A narrative therefore delivers much more information in a much shorter time.

Narratives also allow for nonlinear, interconnected arguments to unfold naturally—something that the rigid linearity of PP does not permit. Such interconnectedness defines many of our most important business opportunities. Moreover, better-informed people make higher-quality decisions, and can deliver better, more detailed feedback on the presenting teams’ tactical and strategic plans. If our executives are better informed, at a deeper level, on a wider array of important company initiatives, we will gain a substantial competitive advantage over executives elsewhere who rely on traditional low-bandwidth methods of communication (e.g., PP). The Presenters’ Advantage: Forces Greater Clarity of Thought We know that writing narratives will likely prove to be harder work than creating the PP presentations that they will replace; this is actually positive. The act of writing will force the writer to think and synthesize more deeply than they would in the act of crafting a PP deck; the idea on paper will be better thought out, especially after the author’s entire team has reviewed it and offered feedback. It’s a daunting task to get all the relevant facts and all one’s salient arguments into a coherent, understandable document—and it should be. 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.

The old essay-writing adage “State, support, conclude” forms the basis for putting a convincing argument forward. Successful narratives will connect the dots for the reader and thus create a persuasive argument, rather than presenting a disconnected stream of bullet points and graphics that leave the audience to do all the work.

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

Written narratives will convey our ideas in a deeper, stronger, more capable fashion while adding a key additional benefit: they will act as a forcing function that shapes sharper, more complete analysis. Six-page narratives are also incredibly inclusive communication, precisely because the interaction between the presenter and audience is zero during reading.

Q: Can we still use graphs or charts in our narratives? A: YES. Most complex issues derive key insights from data and we expect that some of that data may be best represented in the form of a chart or graph. However, we do not expect that graphics alone can make the compelling and complete case we expect from a true written narrative. Include them if you must, but don’t let graphics predominate.

The first is to call out one or more key tenets that our proposal relies upon—a foundational element of the reasoning that led us to make this recommendation. Tenets give the reader an anchor point from which to evaluate the rest. If the tenet itself is in dispute, it’s easier to address that directly rather than take on all the logical steps that derive from that position.

The second optional section, perhaps more commonly used, is the inclusion of an FAQ. Strong six-pagers don’t just make their case, they anticipate counterarguments, points of contention, or statements that might be easily misinterpreted. Adding the FAQ to address these saves time and gives the reader a useful focal point for checking the thoroughness of the authors’ thinking.

An Amazon quarterly business review, for instance, might be broken down like this instead: Introduction Tenets Accomplishments Misses Proposals for Next Period Headcount P&L FAQ Appendices (includes things like supporting data in the form of spreadsheets, tables and charts, mock-ups)

Discussions

When everyone has read the document, the presenter takes the floor. First-time presenters often start by saying, “Let me orally walk you through the document.” Resist that temptation; it will likely be a waste of time. The whole point of the written document is to clearly present the reasoning and to avoid the hazards of live presentation. The attendees have already walked themselves through the argument.

Some groups at Amazon go around the room, ask for high-level feedback, then pore over the document line by line.

Other groups ask a single individual to give all their feedback on the entire document, then ask the next person in the audience to do the same. Just pick a method that works for you—there’s

Then the discussion begins, which essentially means that the audience members ask questions of the presenting team. They seek clarification, probe intentions, offer insights, and suggest refinements or alternatives.

During the discussion stage, it’s also important that notes be taken on behalf of the entire audience, preferably by someone knowledgeable about the subject who is not the primary presenter. The presenter is generally too involved in answering questions to capture effective notes at the same time.

It’s vital that we capture and record the salient points of the ensuing discussion, as those comments become part of the output of the narrative process.

You are not just commenting on a document, you’re helping to shape an idea, and thereby becoming a key team member for that business.

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.

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

Silence in the discussion stage is the equivalent of agreement with what is presented, but it carries the same weight as a full-blown critique.

Working Backwards: Start with the Desired Customer Experience

Start with the customer and work backwards—harder than it sounds, but a clear path to innovating and delighting customers. A useful Working Backwards tool: writing the press release and FAQ before you build the product.

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 tried many different ideas, some of them seemingly crazy, like starting a project proposal by writing a user manual or a technical API guide, relying solely on mock-ups, and other approaches to visualizing the outcome of a project. I remember getting frantic calls from nontechnical product managers saying, “Colin, I’m supposed to meet with Jeff next week. Can you send me a good example of a user manual? Also, I’m supposed to write something called an API guide but have no idea what that is!” We were not committed to any of these experimental formats and stopped using them when we realized they were counterproductive.

In the end, what turned out to work best was relying on the core Amazon principle of customer obsession and a simple yet flexible way of writing narrative documents. These two elements form the 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.

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 requires a ton of work to think through the whole business and a ton more work to create and refine the visuals.

We didn’t have any mock-ups. We just wanted to sell Jeff on the opportunity, show him that these digital media businesses could be large, set a budget, and get the green light to start building the team. We would deal with the customer experience and other details once we got his go-ahead. But if Jeff wants to see mock-ups, you had better make mock-ups.

A few weeks later we were back with rough mock-ups in hand. Jeff listened carefully to our presentation and then began asking detailed questions about every button, word, link, and color.

We answered as we had before. We hadn’t figured out all that stuff! We just needed his basic approval so we could hire the team, start negotiating deals with media companies, and get something launched. That answer did not go over well. At all. Jeff wanted to know exactly what we were going to build and how it would be better for customers than the competition. He wanted us to agree on those details before we started hiring a team or establishing vendor relationships or building anything.

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. And he was quick to say so, often using strong language to make his point inescapably clear. Jeff wanted us to know that we couldn’t just charge down the first available and most convenient path to chase after this opportunity.

We went back to work. The deeper we dug, the clearer it became that digital media was going to be unlike any other Amazon business. The obvious difference was that we would not be shipping brown boxes to customers but rather delivering digital bits over wires. That was the least complicated part. There also had to be a great way for the customer to manage, read, listen to, or watch those bits once they had them. This would require custom apps and hardware.

Forget the spreadsheets and slides, he said. Instead, each team member would write a narrative document. In it, they would describe their best idea for a device or service for the digital media business.

The next meeting arrived, and we all showed up with our narratives. (As mentioned, ours was one of several teams involved in the early experimentation with narratives at the company. They were not yet official Amazon policy.) We distributed them and read them to ourselves and then discussed them, one after another. One proposed an e-book reader that would use new E Ink screen technology. Another described a new take on the MP3 player. Jeff wrote his own narrative about a device he called the Amazon Puck. It would sit on your countertop and could respond to voice commands like, “Puck. Please order a gallon of milk.” Puck would then place the order with Amazon.

The great revelation of this process was not any one of the product ideas. As we’ve described in chapter four, the breakthrough was the document itself. 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.

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.

After we started using the documents, our meetings changed. There was more meat and more detail to discuss, so the sessions were livelier and longer. We weren’t so focused on the pro forma P&L and projected market segment share. We talked at length about the service itself, the experience, and which products and services we thought would appeal most to the customer.

After a lot of trial and error, and incremental moves in this direction among many teams involved in the narrative experiment, Jeff then pushed the idea further. What if we thought of the product concept narrative as a press release? Usually, in a conventional organization, a press release is written at the end of the product development process. The engineers and product managers finish their work, then “throw it over the wall” to the marketing and sales people, who look at the product from the customer point of view, often for the first time. They’re the ones who write the press release, which describes the killer features and fantastic benefits and is designed to create buzz, capture attention, and, above all, get customers to leap out of their chairs to buy.

the two organizations had started the process by writing a press release, they would have had to agree on the features, cost, customer experience, and price. Then they could have worked backwards to figure out what to build, thereby surfacing the challenges they would face in product development and manufacturing.

The Kindle Press Release Kindle was the first product offered by the digital media group, and it, along with several AWS products, was among the first at Amazon to be created using the press release approach. Kindle was a breakthrough in multiple dimensions. It used an E Ink display. The customer could shop for, buy, and download books directly from the device—no need to connect to a PC or to Wi-Fi. Kindle offered more e-books than any other device or service available at the time and the price was lower. Today, that set of features sounds absolutely standard. In 2007, it was pioneering. 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.

When we wrote a Kindle press release and started working backwards, everything changed. We focused instead on what would be great for customers. An excellent screen for a great reading experience. An ordering process that would make buying and downloading books easy. A huge selection of titles. Low prices. We would never have had the breakthroughs necessary to achieve that customer experience were it not for the press release process, which forced the team to invent multiple solutions to customer problems. (We tell the whole Kindle story in chapter seven.)

we refined the press release document and added a second element: the FAQ, frequently asked questions, with, of course, answers. The FAQ section, as it developed, included both external and internal questions. External FAQs are the ones you would expect to hear from the press or customers.

Internal FAQs are the questions that your team and the executive leadership will

the FAQ section is where the writer shares the details of the plan from a consumer point of view and addresses the various risks and challenges from internal operations, technical, product, marketing, legal, business development, and financial points of view.

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. Customers are pitched new products constantly. Why will this new product be compelling enough for customers to take action and buy it? A common question asked by executives when reviewing the product features in the PR is “so what?” If the press release doesn’t describe a product that is meaningfully better (faster, easier, cheaper) than what is already out there, or results in some stepwise change in customer experience, then it isn’t worth building.

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.

Over time, we refined and normalized the specifications for the PR/FAQ. The press release (PR) portion is a few paragraphs, always less than one page. The frequently asked questions (FAQ) should be five pages or less. There are no awards for extra pages or more words. The goal isn’t to explain all the excellent work you have done but rather to share the distilled thinking that has come from that work.

restricting the length of the document is, a forcing function—we have seen that it develops better thinkers and communicators.

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.

The PR/FAQ review process can be stressful, no matter how constructive and unbiased the feedback. Gaps will be found! A PR/FAQ under serious consideration for implementation will typically require multiple drafts and meetings with the leadership. Senior managers, directors, and executive leaders who oversee the authors of PR/FAQs become skilled evaluators and contributors to the process.

Press Release Components

These are the key elements of the press release:

• One sentence under the title. “Blue Corp. announces the launch of Melinda, the smart mailbox.”
• 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. “Melinda is the physical mailbox designed to securely receive and keep safe all your e-commerce and grocery deliveries.”
• Summary Paragraph: Begin with the city, media outlet, and your proposed launch date. Give a summary of the product and the benefit. “PR Newswire, Atlanta, GA, November 5, 2019. Today Blue Corp. announced the launch of Melinda, a smart mailbox that ensures secure and properly chilled delivery and storage for your online purchases and groceries.”
• 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. “Today, 23 percent of online shoppers report having packages stolen from their front porch, and 19 percent complain of grocery deliveries being spoiled.”
• 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. “With Melinda, you no longer need to worry about getting your online purchases and deliveries stolen…”
• 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. “Melinda is a breakthrough in safety and convenience for online shoppers…”

FAQ Components

Unlike the PR, the FAQ section has a more free-form feel to it—there are no mandatory FAQs. The PR section does not typically include visuals, but it is more than appropriate to include tables, graphs, and charts in the FAQ. You must include things like your pro forma P&L for a new business or product. If you have high-quality mock-ups or wireframes, they can be included as an appendix.

Here are some of the typical areas to address:

• Consumer Needs and Total Addressable Market (TAM)
• Economics and P&L
• 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?

A common mistake among less-seasoned product managers is to not fully consider how third parties who have their own agendas and incentives will interact with their product idea, or what potential regulatory or legal issues might arise.

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.

team might identify a hard problem during a review that we did not know how to solve, and didn’t know if we could solve. Jeff would say something to the effect of, “We shouldn’t be afraid of taking on hard problems if solving them would unlock substantial value.”

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.

Manage Your Inputs, Not Your Outputs

The CEO, and companies in general, have very little ability to directly control output metrics. What’s really important is to focus on the “controllable input metrics,” the activities you directly control, which ultimately affect output metrics such as share price.

1. The Flywheel: Input Metrics Lead to Output Metrics and Back Again
2. Identify the Correct, Controllable Input Metrics

When we realized that the teams had chosen the wrong input metric—which was revealed via the WBR process—we changed the metric to reflect consumer demand instead. Over multiple WBR meetings, we asked ourselves, “If we work to change this selection metric, as currently defined, will it result in the desired output?” As we gathered more data and observed the business, this particular selection metric evolved over time from 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.

with the wrong input metrics or an input metric that is too crude, your efforts may not be rewarded with an improvement in your output metrics.

The WBR: Metrics at Work

At Amazon, the Weekly Business Review (WBR) is the place where metrics are put into action. We’ll talk first about how data presentation (mostly graphic) is designed to draw attention where it’s most needed. Second, we’ll describe the meeting itself, how it’s structured to maximize results, and some cautionary notes about how it can fail.

The deck represents a data-driven, end-to-end view of the business. While departments shown on org charts are simple and separate, business activities usually are not. The deck presents a consistent, end-to-end review of the business each week that is designed to follow the customer experience with Amazon.

It’s mostly charts, graphs, and data tables. With so many metrics to review, written narrative or explanatory notes would undercut the efficiency of the read-through.

Emerging patterns are a key point of focus. Individual data points can tell useful stories, especially when compared to other time periods. In the WBR, Amazon analyzes trend lines to highlight challenges as they emerge rather than waiting for them to be summed up in quarterly or yearly results.

Graphs plot results against comparable prior periods. Metrics are intended to trend better over time. Care is taken to ensure that prior periods are structured to provide apples-to-apples comparisons so as not to highlight false variances due to predictable things like holidays or weekends.

Graphs show two or more timelines, for example, trailing 6-week and trailing 12-month. Trend lines for the short term can magnify small but important issues that are hard to spot when averaged out over longer periods.

Anecdotes and exception reporting are woven into the deck. One trait of an Amazon WBR deck that people often remark upon is the liberal use of two tools: anecdotes and exception reporting—that is, the description of an element that falls outside some standard or usual situation.

A well-run WBR meeting is defined by intense customer focus, deep dives into complex challenges, and insistence on high standards and operational excellence.

We use consistent and familiar formatting to speed interpretation A good deck uses a consistent format throughout—the graph design, time periods covered, color palette, symbol set (for current year/prior year/goal), and the same number of charts on every page wherever possible.

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.

Our business owners own metrics and are prepared to explain variances Amazon business owners are responsible for tracking the success of their area as defined by their metrics. In the weekly review, the owners, not the finance team, are expected to provide a crisp explanation for variances against expectations.

We keep operational and strategic discussions separate

We try not to browbeat (it’s not the Inquisition) It’s okay to dig into a meaningful variation that needs more attention, and to point out when high standards have not been met. Still, success demands an environment where people don’t feel intimidated when talking about something that went wrong in their project

We make transitions easy We’ve attended many executive meetings where the most expensive team in the company wastes valuable time, for example, fumbling the handoff of the presentation from one person to the next because the second person’s dashboard doesn’t load easily, or what have you. To make these transitions quick and seamless, you have to put in the up-front work.

Introduction to applications within Amazon

The Amazon Fire Phone is an example of a well-executed process that produced, well, a dud. The launch of the Fire Phone was one of the largest new product initiatives the company had undertaken. The phone’s primary differentiator was a feature called “dynamic perspective,” a 3D effect produced by four cameras within the phone, along with a positioning gyroscope. More than a thousand people worked on the many elements required to create the phone’s 3D capability and a number of smaller innovations, as well as the more standard features and functions that would affect the customer experience.

Fire Phone launched in June 2014. In August 2015, it was discontinued. What happened? First, even with the PR/FAQ process, the Fire Phone did not solve a sufficiently important customer problem or create a notably wonderful customer experience.

Jeff himself was deeply involved in the development of the Fire Phone. He was effectively one of the authors of the PR/FAQ, along with project leaders Ian Freed and Cameron Janes. He and the team either believed or convinced themselves that they were creating a phone customers would love, but they were wrong. Even the best process can only improve the quality of your decision-making; no process will make the decision for you.

an interview after the Fire Phone was withdrawn, Jeff was asked about its failure and answered, “If you think that’s a big failure, we’re working on much bigger failures right now—and I am not kidding.”4 The magnitude of your inventions, and therefore your mistakes, needs to grow in lockstep with the growth of your organization.

Prime was a two-way door decision. If Prime’s particular combination of subscription, free shipping, and quick delivery had not worked, we’d have kept tinkering with the formula until we got it right. In fact, Prime was not our first go at solving the problem—it was preceded by another two-way door decision, Super Saver Shipping, which eventually morphed into Prime. The Fire Phone, on the other hand, was more of a one-way door decision: upon withdrawing it from the market, Amazon did not turn around and say, “Okay, that happened, now let’s try another phone.”

Kindle

If we had tried to figure out how to deliver digital media while also managing our online physical-media business, we could not have moved quickly enough. We would not have thought big enough about how to reinvent the customer experience as we did when we built our own e-reader device and service. The customer experience would undoubtedly have been a subpar mishmash of the physical and digital business approaches. We had to start from scratch.

Jeff made clear that people like the exec who’d baited him at the digital music conference wouldn’t drive our process. He recognized that building copycat versions of products like the iPod and the iTunes store was a nonstarter. And he had no interest in making a PR splash by announcing to the public that Amazon had arrived in the digital business. He chose the path of invention by looking beyond the music category, which led him to begin Amazon’s foray into digital by focusing on e-books and an e-reader device. In so doing, Jeff demonstrated his belief that true invention leads to greater long-term value for customers and shareholders.

team and I quickly learned that invention is a more challenging path than fast following. The roadmap for fast following is relatively clear—you study what your competitor has built and copy it. There is no roadmap for invention.

To win in digital, because those physical retail value adds were not advantages, we needed to identify other parts of the value chain where we could differentiate and serve customers well. Jeff told Steve that this meant moving out of the middle and venturing to either end of the value chain. On one end was content, where the value creators were book authors, filmmakers, TV producers, publishers, musicians, record companies, and movie studios. On the other end was distribution and consumption of content. In digital, that meant focusing on applications and devices consumers used to read, watch, or listen to content, as Apple had already done with iTunes and the iPod. We all took note of what Apple had achieved in digital music in a short period of time and sought to apply those learnings to our long-term product vision. Our core competencies did not extend to either end of the value chain.

did not let this get in the way. In one of our meetings, he said that a typical company that wanted to grow would take stock of its existing capabilities and ask, “What can we do next with our skill set?” He emphasized that Amazon’s approach was always to start from the customer and work backwards. We would figure out what the customers’ needs were and then ask ourselves, “Do we have the skills necessary to build something that meets those needs? If not, how can we build or acquire them?” Once we determined what was necessary to create value for our customers and to differentiate ourselves from our competitors, we didn’t let our lack of ability deter us from achieving this important end result—our own device.

So, although we knew nothing about building hardware, Jeff and Steve decided that the place to start was at the consumption end of the chain: hardware, specifically e-books. There were multiple reasons for this. One was that books were still the single largest category at Amazon and the one most associated with the company. Music was the first category to move to digital in the marketplace, but Apple had a big head start and our sessions did not produce a PR/FAQ for a music device or service idea that was sufficiently compelling. Video had not gone digital yet, which seemed like an opportunity, but it became apparent that there were a number of barriers to creating a great video experience at that time. These included getting the rights from the studios to offer their movies and TV shows digitally, the time it would take to download massive video files over the slow (at the time) internet, and uncertainty about how consumers would play these video files on their TVs. Based on these factors, we decided to make a big investment of people and funds in e-books and a reading device and establish much smaller teams to work on music and video.

The other reason for starting with books was that the e-book business as a whole was tiny; there was no good way to read e-books on a device other than a PC, and reading on a PC was definitely not a good experience.

The idea that Amazon, a pure e-commerce distributor of retail products made by others, would become a hardware company and make and sell its own reader device was controversial. Like nearly everyone at Amazon outside our Digital leadership team, I had a really hard time accepting that it was a good idea to make our own hardware when it seemed that nearly every leader in the company and on the board of directors was questioning it. Like everyone else, I thought it was super expensive (not adhering to the Frugality leadership principle!) and would fail. I now recognize that going through that process and seeing the outcome transformed my understanding of how innovation works.

We had worked through countless drafts of our PR/FAQ for an e-book store and device, and the end result was clear: we needed to build an e-book store that was deeply integrated with a reading device. This combination was the key to delivering a book-buying and reading experience that would delight customers. Through our research, we learned that relying on third parties, while operationally and financially less risky, was much riskier from the point of view of customer experience. If we start with the customer and work backwards, then the most logical conclusion is that we need to create our own devices.

Furthermore, outsourcing in this context offers a classic example of short-term decisions with devastating long-term implications. Practically every day, Amazon could tweak its offering to make things a little better. And so practically every day, the distance between itself and its competitors widened. Outsourcing turned out to be the more expensive path.

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.

Jeff saw this as an opportunity. He wanted the Kindle to be like the BlackBerry—no wires, never a need to connect to your PC. Not only did he want us to eliminate sideloading altogether, he wanted to build the bookstore right into the device so you could shop and read on the go. For this to work, he pushed hard for the Kindle to have a 3G modem so that it could connect to a wireless carrier network (Sprint was our first partner) and automatically download new e-books as soon as they were available. The feature was named Whispernet.

Whispernet was another incredibly controversial part of the Kindle project. It had never been done before. Wireless carriers jealously protected their relationships with cellular customers. Here we were, proposing to create a direct wireless relationship that eliminated the need for Kindle customers to set up an account with a carrier, and we didn’t plan to charge customers for the network access. Amazon would cover the cost. Jeff, who insisted that Kindle have this capability, instructed the team to find a way to absorb the expense within the overall Kindle product design. Luckily, that requirement wasn’t quite as onerous as it might sound, because e-book files are quite small and the connection cost was therefore modest. This essential feature, Whispernet, was not easy to develop. Establishing relationships with the wireless carriers was a big hurdle. Adding a 3G modem would make the Kindle a much more expensive device. Achieving the breakthrough required a ton of invention by the team, but it would add a great deal to the customer experience. With the ability to download any book almost instantly and never have to link up to a PC, the customer could become engrossed in their reading much faster and with less friction. 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.

Whispernet was another incredibly controversial part of the Kindle project. It had never been done before. Wireless carriers jealously protected their relationships with cellular customers. Here we were, proposing to create a direct wireless relationship that eliminated the need for Kindle customers to set up an account with a carrier, and we didn’t plan to charge customers for the network access. Amazon would cover the cost. Jeff, who insisted that Kindle have this capability, instructed the team to find a way to absorb the expense within the overall Kindle product design. Luckily, that requirement wasn’t quite as onerous as it might sound, because e-book files are quite small and the connection cost was therefore modest.

Prime

In mid-October 2004, several senior Amazon executives received an email from Jeff Bezos that read roughly as follows: We should not be satisfied with the growth of our retail business. This is a house-on-fire issue and we need to dramatically improve the customer experience around shipping. We need a shipping membership program. Let’s build and launch it by the end of the year. We were on the cusp of the always-frantic holiday retail season. Jeff’s directive had all the earmarks of what corporate denizens groaningly refer to as a “fire drill” or a “pet CEO project”—an urgent, all-hands-on-deck order to deliver on what seems like a rash decision. A pet project can blow the company off the course of its longer-term strategy and create even larger issues in its wake.

Amazon Prime provided a compelling, game-changing customer experience, and as a result it became the greatest driver of growth for the retail business. But Prime’s journey from idea to launch was an unusual one for Amazon. It did not have a single-threaded leader or team until very late in the process. There was no clear mission statement, and it did not follow the then-nascent Working Backwards process until well after the project was underway. Few Amazonians thought it was a good idea even when it launched.

There were two options: 1)  Stay the course. The company is still growing. Let’s maximize our return on this multiyear investment we just made to build our fulfillment centers and tweak them to improve along the way. The next batch of quarterly results will reflect that we’re moving in the right direction. 2)  Two-day shipping and eventually one-day and same-day shipping will become the norm. Therefore, while what we’ve built is good, it is not good enough. Buoyed by our “unshakeable conviction that the long-term interests of shareowners are perfectly aligned with the interests of customers,” we should embark on this new journey right now.

Option one would be the skills-forward path—that is, using the existing skills and assets of the company to drive business opportunities. Leaders at most companies would likely be praised for choosing this path. The danger is that while they stand atop this local optimum, someone else will figure out how to scale a higher peak they couldn’t see at the time due to risk aversion.

Back to that day in mid-October 2004: we got the answer in the form of Jeff’s email directing us to get it done. In 11 weeks. During the busy holiday season. To say that Jeff’s proclamation came as a complete surprise to many team members, particularly to those asked to drop what they were doing and shift immediately to this new, undefined program, would be an understatement. But they had not been part of the conversation and formulation and calculation that had been going on for several months. Jeff’s decision to launch a free shipping program was bold, but hardly sudden or rash. It was informed by the most basic Amazonian drive: customer obsession.

Amazon Prime—launched in February 2005—would prove to be one of the best decisions Amazon ever made. Not only did it secure Amazon’s survival, it became a key driver of its explosive growth over the following decade.

big bet on Prime, you have to understand why we’d come to seek radical ideas to fuel growth. Our third-quarter financial results released on October 21, 2004, showed that sales had grown by 29 percent year over year. Free cash flow had increased by 76 percent. Many corporations would look at such growth figures with envy, but a closer look at our financials at the time revealed a more concerning picture.

Need for Growth

To understand Amazon’s decision to place such a big bet on Prime, you have to understand why we’d come to seek radical ideas to fuel growth. Our third-quarter financial results released on October 21, 2004, showed that sales had grown by 29 percent year over year. Free cash flow had increased by 76 percent. Many corporations would look at such growth figures with envy, but a closer look at our financials at the time revealed a more concerning picture.

the rate of growth decreased from the prior year, across all lines of business.

In 2004, the U.S. retail industry was estimated to generate more than $3.6 trillion of sales, of which less than 2 percent was conducted online. Amazon’s growth rate was slowing, but the shift from offline to online commerce was accelerating. That meant one thing: if Amazon’s growth continued to decelerate, the company would become a smaller and smaller player in online commerce over time. We were determined to find a way to reverse this trend.

If we had been a small company, we might have cooked up a storewide promotion and launched it with a marketing blitz toward the end of the quarter. It might have made the financial results look better (at least on the revenue side) for the quarter, but such a one-off action wouldn’t have fixed the underlying problems.

A larger company might address its slowing-growth problem in a more dramatic way, perhaps by making an acquisition of another company, with the goal of creating a big jump in sales (though maybe not profit). But for Amazon at the time, there were few, if any, mergers or large acquisitions that made sense. All the e-tailers we might have bought were small, and their acquisition would not have moved our sales needle appreciably. Buying an offline retailer made no sense—although it might increase the number of customers, it would burden us with the brick-and-mortar costs and inefficiencies we wanted to avoid.

One action we did briefly consider was creating a national advertising campaign to build awareness for the Amazon brand. In 2002, we ran a long-term advertising test in Portland and Minneapolis. The campaign drove a bump-up in sales, but we ultimately decided not to fully move forward with it. The modest sales uplift was nowhere near enough to justify the $50 million per year we estimated we’d have to spend on an effective national marketing campaign. The better investment was to plow that money back into improving the customer experience.

Amazon customers cared about three main things that we could deliver for them: Price. Is the price low enough? Selection. Does Amazon have a wide range of products—ideally everything? Convenience. Is the product in stock, and can I get it quickly? Can I easily find or discover the product?

Shipping promotions drove significantly higher growth than any other type of promotion. The perceived value of free shipping was higher than straight discounting of product prices. Put another way, if the average discount of a free shipping promotion was 10 percent, we’d see significantly more demand lift (called elasticity) by offering free shipping than by discounting product prices by 10 percent. It wasn’t even close.

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.

Customer expectations are not static. They rise over time, which means you cannot rest on your laurels.

In 2000, Amazon had no large-scale loyalty program, which was unusual for an e-commerce company of its size. Jeff asked David Risher, Alan Brown (head of Marketing), and Jason Child (Finance) to create a loyalty program that would drive durable growth. The marketing and retail teams analyzed several variations of loyalty programs, including free standard shipping for orders over $25 (which was essentially Super Saver Shipping but without the three-to-five-day click-to-ship time), free shipping on all preorders (that is, an order placed before the item’s official first ship date), paying an annual fee for free standard shipping, or free two-day shipping. We also considered an alternate form of loyalty program that would include different combinations of purchases of our “owned inventory” (items we stocked in our fulfillment centers) and those of third-party items, where we would have to subsidize shipping costs or require third-party sellers to do so. We even evaluated rebates

None of the ideas made it very far because they could not meet the three essential criteria.

We worried that the membership programs that involved an annual fee for free standard shipping or for free two-day shipping would encourage customers to purchase fewer items per order. This would not generate enough money to cover shipping costs, which meant it would not be sustainable. Unsustainable growth at any cost was definitely not the customer behavior we were after. Review meetings often ended when someone asked, “Wouldn’t the money be better spent on lowering prices and improving In Stock for customers?” We knew these actions were effective at increasing customer sales, but we weren’t so sure that a subscription program would do the same.

This very nearly became one of those scenarios when a company takes the seductive but ultimately wrong path of staying the course, making a serious error of omission as a result.

The “institutional no” is a big reason why Amazon could have made an error of omission in this case. Jeff and other Amazon leaders often talk about the “institutional no” and its counterpart, the “institutional yes.” The institutional no refers to the tendency for well-meaning people within large organizations to say no to new ideas. The errors caused by the institutional no are typically errors of omission, that is, something a company doesn’t do versus something it does.

Moreover, the errors of omission caused by the institutional no can be notoriously tricky to spot. Most businesses don’t have the tools to evaluate the cost of not doing something. And when the cost is high, they only realize when it’s too late to change.

Walking the Store Most retail CEOs walk the store when they have a chance, and Jeff is no exception. The typical CEO will pay a visit to a retail outlet when they’re in the area—often unannounced, or even incognito—to do a bit of browsing and observe what’s going on. An online retail CEO can walk the store anytime, of course, and Jeff’s preferred walking-the-store time was early Saturday and Sunday mornings. It was not unusual for me to wake up at 7 a.m. on a weekend, check my email, and read five or six messages from Jeff to the relevant teams on issues he had found while walking the store that morning.

Greg Greeley was the point person in charge of responding. At one point he had over half a dozen different scenarios to analyze. In early October, Jeff said he wanted to see a comparison of all these alternatives by the end of the month. A few days later, in the middle of the month, Jeff sent the house-on-fire email and said rather than presenting the set of ideas in three weeks, we should select the best one and launch the program by the end of the year. I think at some point he had decided that it wasn’t the idea that was flawed, but the decision-making process, a process encumbered by institutional risk-aversion. The “October surprise” email arose out of his realization that you simply could not prove a priori that free shipping would work. You just had to try it.

After much back and forth, by the second half of November, there was general consensus that the best option was a paid yearly membership that would offer free two-day shipping. Now we needed to find a team to build it. What came next was a clear expression of another one of Amazon’s Leadership Principles in action, Have Backbone; Disagree and Commit: “Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.”

Jeff said he wanted to build a moat around our best customers. Prime would be a premium experience for convenience-oriented customers. Jeff H., Vijay, and Dorothy could recruit whoever they needed to the team, but it had to launch concurrently with the next earnings call. The teams involved were in a flat-out sprint with long hours for the duration of the project, which internally was called Futurama. It was only at this point in the process that the Futurama PR/FAQ was belatedly written and revised. While completing the project required heroic efforts from several dozen team members (including Charlie Ward, recently returned from his vacation), the implementation story is outside the scope of this book and has been covered in the press. The earnings call was even bumped out to February 2, 2005, to accommodate the project launch.

It’s also worth pointing out that other teams had created building blocks for other purposes that could be deployed for developing Prime—and without which we would not have been able to meet the aggressive schedule.

on February 2, 2005, less than four months after the notorious October email from Jeff, Amazon Prime launched. The truth is, it was not an overnight success as the Kindle had been. The first customers who joined were the heavy buyers who already spent more than $79/year on expedited shipping. So we were really just subsidizing their existing habits. Though we had created a game-changing online shopping experience, shifting consumer behavior takes time.

Amazon Prime is a great example of the tremendous value you can unlock by ruthlessly applying the principles of customer obsession and long-term thinking to a problem—in this case, increasing revenue growth. To do so, we had to accept the fact that the current logistics infrastructure we had painstakingly built over the years, though doing reasonably well at the time, wouldn’t cut it in the long run.

Prime Video

In retrospect, it is easy to see the mistakes. We had rushed Unbox out the door before it was ready. In the weeks leading up to launch, rumors had been swirling around Hollywood and in the press that Apple was close to launching a digital video service. 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. We had been decidedly un-Amazonian.

This is my self-assessment that I wrote in my performance review that year: Overall, my performance was dreadful in 2006. In Unbox, our launch was poorly received, partly due to DRM [digital rights management] and licensing issues that restrict content usage, and selection, partly due to bad product choices we made for consumers (erring on the side of quality over download speed) and partly due to engineering defects. In any case, I didn’t manage these issues appropriately and the result was a weak launch with weak consumer response and negative press reaction. Net my performance versus goals can be summarized by a poor execution percentage in terms of projects completed and the main project that is complete (Unbox Video) is not a compelling customer experience (yet) and the rate of sales is pitiful. I think a grade of ‘D’ for my performance vs. goals would be generous.

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

Jeff described a scene in which Hughes, played by Leonardo DiCaprio, visits one of his aircraft manufacturing facilities to check on the progress of his latest project—the Hughes H-1 Racer, a sleek single-passenger plane designed to set new speed records. Hughes examines the plane closely, running his fingers along the surface of the fuselage. His team watches anxiously. Hughes is not satisfied. “Not enough,” he says. “Not enough. These rivets have to be completely flush. I want no air resistance on the fuselage. She’s got to be cleaner. Cleaner! You understand?”

We needed DRM software for Unbox, but there was no way Apple would license FairPlay to us, and no way the studios could force Apple to do so. Unless we built our own DRM, we had to go with Microsoft’s Windows Media DRM, which only worked on Windows devices, and there not very well.

decades-old contracts between the motion picture studios and the major pay TV channels such as HBO, Showtime, and Starz—the “blackout window” clause. The clause stated that when a new movie became available on DVD from a studio, we had a clearly defined window—usually 60 to 90 days—during which we could digitally sell or rent the title. After that came the blackout window, a period usually lasting three years, during which the pay TV channels had the exclusive rights to air the movies, and we were not allowed to digitally rent or sell them on our service.

studios were nervous and uncertain about the new digital download services being offered by Amazon and Apple, which they referred to as transactional video on demand, or TVOD. Yes, they could see that TVOD was growing fast and held enormous promise, but the revenue stream was still just a trickle—tens of millions of dollars a year—and it looked like a risky bet, so they were reluctant to change their contracts.

it meant that we had a very short sales window for our digital movie service. Two to three months after the release of the DVD, then nothing for three years, the period of greatest demand. We knew that we had to change this if we expected video streaming to become a great customer experience and a big business for us in the long term. But I would quickly learn that this was not within our control.

Fast-forward ten years, and thanks to their short-term thinking, the studios were scrambling to launch their own streaming video services like Disney+, Warner’s HBO Max, and NBC’s Peacock in a bid to fight for their survival and compete with Amazon and Netflix.

At Amazon, our compensation wasn’t tied to financial results. As we mentioned in chapter one, the maximum base salary at Seattle headquarters was $160,000 per year, and there was no bonus system at all. Additional compensation was in Amazon stock. If you got a raise, it was completely in stock, which wouldn’t begin vesting for 18 to 24 months. My

In March 2007 we launched Unbox on TiVo,2 and just like that, we were delivering a customer experience we could be proud of, at least once you got it set up. You could browse and shop for movies and shows on the Amazon site, and they would be downloaded automatically to your TiVo. The download still took time, but it had a feature called progressive download. As soon as the runtime of the downloaded content exceeded the time it would take to download the rest of the movie, you could start watching. It wasn’t real streaming, but it did speed things up. Amazon customers who already owned a TiVo device were delighted and sang our praises. TiVo became our best source of growth for revenue and new customers.

A Massive Disruption Two months earlier, 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. In those days the Netflix streaming service offered a pretty paltry selection, about a thousand movies and TV shows, mostly classics like Casablanca, cult films, foreign titles, and a few TV series such as the original BBC series House of Cards—no recent releases or big hits. But they’d made significant breakthroughs that would stand them in good stead as they improved their content.

The other noteworthy feature of the Netflix streaming service was that it was free. Actually, as my mother used to say when trying to teach me good fiscal sense, “It isn’t free. It’s included.” It came at no extra cost with most of the Netflix DVD rental-by-mail subscription plans.

Another reason we didn’t take the Netflix streaming service seriously was that it had no immediate, perceptible impact on Unbox. But when Hulu launched in October 2007, the impact was perceptible. Unlike Netflix streaming, Hulu offered some of the most popular TV shows in the United States—the latest shows from Fox and NBC the day after they aired on TV. Not only that, Hulu was free (with advertising), and not the included-kind-of-free that my mom taught me about—just plain free.

We had been selling these same TV shows on Unbox for $2.99 an episode, which was cheaper than buying a DVD, and making them available the day after broadcast. Now, with Hulu, you could watch many of the same shows, just as soon, and for free. Suddenly our $2.99 was a lousy deal, and a bunch of our top-selling TV shows were not selling at all.

Connected TVs In 2008, further developments showed that the path to the living room had more twists and turns that would have to be negotiated. We decided it was time for Amazon to add streaming video to our download service and saw the shift as an opportunity to dump the name Unbox, which had accumulated a lot of negative baggage.4 We relaunched the service in September 2008 with the name Amazon Video On Demand (VOD).

But because the speed of internet connection varied from home to home, and because there were so many different kinds of hardware and software involved, the viewing experience varied from device to device and customer to customer. Some were delighted; some tore their hair out. The hair-tearers typically suffered from a phenomenon known as “rebuffering,” which is what happens when the downloading speed lags behind the viewing: the picture freezes, and you get to watch the “spinning wait cursor,” more commonly referred to as the “wheel of death.”

Gamers pounded on their consoles for hours every day but they needed to take a break now and again, so watching a movie or TV show was an obvious and easy value proposition for them. We wanted to make Amazon VOD available on game consoles, too. But our business development team had some bad news for us. Neither Microsoft nor Sony would allow us to put the Amazon streaming app on their gaming devices, because they had their own à la carte digital video stores and wanted to build those businesses. They did not ban Netflix, however, because it was a subscription service, and they did not see it as directly competitive.

Apple, for example, sold all their digital media through an application running on Macs and PCs (iTunes) rather than on their website. And, unlike Amazon, Apple had control over their own devices. The combination of application and device delivered a high-quality streaming (or download) and playback experience and therefore delivered tremendous value to the consumer.

was this insight into the value chain that led us to create Kindle. Since we didn’t do content creation via developing or publishing books (although we would do that later), we made the move to control consumption, that is, the reading experience. In digital movies and TV, we were still stuck in the aggregation role. The retail business input metrics of price and selection did not differentiate us in this digital business, and our output metrics—number of video buyers and revenue—showed that this strategy was a failure. So, beginning in 2010, we put our resources into a number of new initiatives designed to get us out of the middle: Prime Instant Video, Amazon Studios, and new Amazon devices—Fire Tablet, Fire Phone, Fire TV, and Echo/Alexa. We also made an acquisition that enabled us to increase our capabilities and expand our geographic reach.

Three of the ideas we pursued were for hardware devices. One was a universal remote control that would make it easy to play Amazon video on your TV. Another was for a puck-shaped device that was connected to your home AV system. It would learn the preferences of each member of the household through voice detection and commands, enabling personalized video playback for each customer. This was a variant on the puck idea first conceived by Jeff years earlier as a shopping device (mentioned in chapter five), and it would later morph again to become the Amazon Echo. A third idea was for a set-top device that was preloaded with the most popular movies and shows and would be updated wirelessly. We

In our fourth or fifth meeting with Jeff, it was painfully obvious that we were getting nowhere with hardware or subscription. A small group of the leaders of the digital video team sat around the table in his small conference room on the sixth floor of the Day One North building in South Lake Union. Just as we had in previous meetings, we reviewed a bunch of ideas, talked about movie genres, and considered pricing and budget options. At some point, Jeff came up with a simple idea: “Let’s make videos free for Prime members.”

This had not been on anybody’s list of ideas. How would that work? Jeff reminded us of how Netflix got started by offering Watch Now streaming videos to its DVD subscription service—free. I mean included. “It’s an ‘oh-by-the-way’ offering,” he said. When Netflix started, they didn’t have a great selection of movies and TV shows either, not good enough that customers would pay extra for them. Instead, Netflix gave their customers additional value as part of their existing subscription.

Netflix was essentially saying, “The service you pay for is great and, oh, by the way, here is something extra for you to watch.” As we spoke, three years later, most Netflix customers were exclusively streamers.

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.

as with most technology, those costs declined over time. The cost structure is very different from the DVD rental-by-mail business, where the costs—warehouses, wages, shipping, replacement discs—are variable.

We were less concerned about the poor initial selection because our time horizon for success was measured in years. We were confident that, given time, we could make the right investments and assemble a great selection of movies and TV series. If we did this well, customers would eventually be attracted to Prime, not only for the fast free shipping but also for the streaming videos included in the fee. The “oh-by-the-way” addition would become a “gotta-have” benefit.

in early 2011, the floor fell out from under our feet. The key studios—including Sony, Warner, and others—informed us that Netflix had entered the bidding for the same titles we wanted and had offered twice the money for them. Out of the blue, we found ourselves in a bidding war. Who won? The studios. Their fees skyrocketed while we duked it out with Netflix, all to win the eyes, ears, and hearts of UK and German customers.

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.

getting Amazon Studios off the ground was one of the fastest new business creation tasks I had during my time at Amazon. This is largely because of the particular and distinct nature of the entertainment industry. Unlike the software and hardware engineering talent pool, which is limited and in high demand, there is a large talent pool of producers, directors, actors, and craftspeople. A small percentage of them are full-time employees in any kind of organization.

Most are independent, freelance contractors. Engagements are relatively short term. Scripts too are in virtually endless supply, although, as we’d learned, the percentage of great ones is small.

Before House of Cards, most A-list Hollywood players wanted nothing to do with online productions. Such things were beneath them, just as appearing in advertising had once been seen as low class. But Spacey was willing to take that risk, and he and Netflix broke through the barrier.

AWS

in March 2002, we decided to take a chance and launch an experimental feature that changed the way we shared information with the affiliates. Instead of receiving a fully formed product display, the affiliates could choose to receive the product data in a text format called XML. The affiliates would then take that XML product data and write their own software code to incorporate it into their websites according to their own design standards. The goal was for us to get out of the design business so they could innovate without us holding them back.

We had to create new elements such as user manuals, technical specifications, and sample code all rolled into a software developer kit (SDK) to show them how the system worked. We also created a discussion board where developers could post details about their experience with the services and ask each other questions. We didn’t really know how our affiliates would react to this more complicated but also more powerful and flexible feature.

Literally hours after releasing this feature, I knew that we were onto something big and that our experiment would far exceed our expectations. On the discussion boards, affiliates were posting links to web pages they had created with this new service along with the code they used to do it. They were proud of what they had created and wanted to share it with others. They were enthusiastically answering questions posted by other affiliates, even before we could respond. And they immediately started suggesting new features that would make the service even better.

I told him the most interesting insight was not what Amazon was doing with web services; rather, it was what our affiliates were doing with them. I proceeded to show him some of the more interesting sites and applications, including some of the ones mentioned above, along with numbers showing the traffic and sales generated by them.

After we finished the virtual tour, Jeff commented that this adoption rate and level of innovation from a single feature was unusual and that we needed to double down on our activities in this area. I responded that we were looking at ways to roll it out to a wider audience with a much richer feature set in July, three months away. From that day, Jeff was an avid supporter.

Since we did not have much experience creating programs for software developers, we sought in-person feedback from heavy users of the service.

In July 2002, we launched the very first version of Amazon Web Services. If the product data XML we had sent to affiliates a few months earlier was the beta, AWS was the 1.0. It included some search and shopping capabilities and a full software development kit, and it was available to anyone, not just affiliates. Also, it was still free. For this one, we did issue a press release, in which Jeff said: We’re putting out a welcome mat for developers—this is an important beginning and new direction for us.… Developers can now incorporate Amazon.com content and features directly onto their own websites. We can’t wait to see how they’re going to surprise us.5

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. We just didn’t know how big it could be or how quickly developers would adopt it. Within a year, we had a pretty good idea—over 25,000 developers enrolled in the program6 and were constantly surprising us with what they built.

Though this program was called Amazon Web Services, it bears little resemblance to today’s AWS. In fact, the service we launched in 2002 was renamed the Amazon Product API and had a significant limitation—it had to be used to market Amazon products and therefore was solely focused

Though this program was called Amazon Web Services, it bears little resemblance to today’s AWS. In fact, the service we launched in 2002 was renamed the Amazon Product API and had a significant limitation—it had to be used to market Amazon products and therefore was solely focused on improving the Amazon retail ecosystem.

Also in 2001, we embarked on a project called the “3-Ring Binder,” which was an attempt to create and document a set of APIs that would allow partners to quickly add their product selection to the Amazon site and to create websites powered by Amazon’s technology, but at their own URLs, under their control. This project eventually allowed us to create websites for partners such as Target and other retailers. Additionally, we developed a program called Seller Central, which provided web services that Amazon’s third-party sellers could use to manage their businesses. The Amazon Associates Product API, Amazon Anywhere, the 3-Ring Binder, and Seller Central all reinforced our hypothesis that a seismic shift was happening in the way software was built.

Several other companies were offering web services–based developer programs at the time. Like the Amazon Product API, their programs were intended to enhance their own ecosystem. For example, eBay’s developer API provided developers with tools to build applications to buy and sell products on eBay. Google had a search API, which launched the same week as Amazon Product API. Amazon had a second web services program that Marketplace sellers could use to manage the products they sold on Amazon. These programs generated quite a bit of buzz in the developer community.

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.

Basically, the first part of the race consisted of many months of iterating on the Working Backwards PR/FAQ process and going through the Bar Raiser process one candidate at a time as fast as we could to start building out the teams.

the discussion moved away from a tiered subscription pricing strategy and toward a cost-following strategy. “Cost following” means that your pricing model is driven primarily by your costs, which are then passed on to your customer. This is what construction companies use, because building your customer’s gazebo out of redwood will cost you a lot more than building it out of pine.

Amazon was just starting to use the Working Backwards process in those days when we were developing this early version of AWS. And many teams were frustrated by how slow it was to do things this way. The software engineers in the PR/FAQ meeting where we discussed pricing were getting antsy. One of them pulled me aside afterward and said, “We’re software engineers, not pricing specialists with MBAs. We want to write software, not more Word documents.” Painstakingly following the Working Backwards process meant we didn’t even get to the rest of the PR/FAQ document in that meeting. And it meant the engineers now had to do a bunch of research, testing, and measurement on the relative costs of the service before the next meeting. I asked them to trust the process even though it seemed painful in the moment.

Conclusion

The questions that typically follow a presentation of the ideas in this book are, “How do I start? Where do I start?

• 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 argument for abandoning output metrics. Amazon does care a great deal about free cash flow per share.
• 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.
• Revise the compensation structure for leaders so that it encourages long-term commitment and long-term decision-making. Avoid making too many exceptions for “special cases.” Make sure that leaders in all areas of the company are compensated with the same basic approach.
• Articulate the core elements of the company’s culture, as Amazon did with long-term thinking, customer obsession, eagerness to invent, and operational excellence. Then build these into every process and discussion. Do not assume that simply stating them and displaying them will have any significant effect.
• Define a set of leadership principles. These must be developed with participation from many contributors. Don’t assign the task to a single group or outsource it to a consultant or service provider. Do it yourselves. Hash out the details. Revisit the principles from time to time and revise if and as necessary. Then, as with the aspects of the culture, bring the principles into every process, from hiring to product development.
• Depict your flywheel. What are the drivers of growth for your company? Make a picture of them that shows how they act upon the flywheel. Evaluate everything you do in light of its positive or negative effect on one or more drivers of the flywheel.