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

Working backwards from the desired customer experience.

Leadership principles

The first section is about Amazon’s leadership principles.

Hiring people

Hire missionaries, not mercenaries.

Rushing, the lack of written notes, and discussing the candidate before writing things down has led to bad hiring decisions. Amazon instituted the bar raiser process for consistent hiring.

Organizing teams

Amazon has a concept of separable, single-threaded leadership to untangle dependencies so that teams can work independently. Unencumbered by competing responsibilities, a single person owns a single major initiative and heads a separable, mostly autonomous team to deliver its goals.

As a company grows, it’s slowed down by necessary coordination to manage dependencies. Dependencies can be technical or organizational.

Initially, Amazon had the NPI (New Product Introduction) process. One would write a proposal that would be vetted and prioritized by a leadership committee. There were several outcomes, of which the worst was that one’s project wasn’t prioritized, but one’s team had to support another group that had its proposal accepted. The process was a morale killer.

Over a few iterations, Amazon launched the two-pizza team model to solve the coordination problem:

• Fewer than ten people (you can feed a team with two pizzas).
• Autonomous, no need to coordinate with other teams to accomplish what the team needs. Interaction with other teams is through technical APIs (microservices).
• A well-defined fitness function is a weighted average of select metrics relevant for that team.
• Fully responsible for the business outcome.
• Led by a multi-disciplined (cross-functional) leader who knows how to hire required team members and has excellent business judgment and technical expertise.
• Be self-funding; the team’s work pays for itself
• Approved by the S-team in advance (S-team = executives close to Jeff Bezos).

While the idea generally worked, there were several aspects where the model didn’t work as planned, so it had to be updated. For example:

• Two-pizza teams work best in product development. Legal, retail, and similar aren’t the best areas to apply it because those teams had fewer dependencies from the start.
• Fitness functions. People were spending too much time coming up with the right metrics. Some functions were so complex (too many first-order and derived metrics) that it was impossible to discern what the team was doing to move the function causally, and how they should respond to the trend. Amazon decided to go back to observing fewer distinct first-order metrics.
• It was extremely hard to find exceptional multi-disciplinary leaders for many teams, so Amazon opted for teams whose members reported to a functional manager (for example, a UX designer reports to a UX design manager).
• The small size wasn’t a good predictor of the team’s success; the leader was. The size limit wasn’t enforced anymore, and the name changed from “two-pizza team” to “single-threaded leaders (STL) and teams” underscoring their focus on one effort.

(Note: Two years after the book was published, the Prime Video team published a blog post stating that “the move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.” Different problems require different technical solutions; one-size-fits-all never works.)

If an effort is someone’s side project, it won’t succeed. One has to own it and be fully responsible for it.

Be stubborn on the vision but flexible on the details.

Communicating: Narratives and the Six-Pager

Book reference: The Cognitive Style of PowerPoint by Edward Tufte

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

Tufte recommended going from presentations to high-definition handouts where people can contextualize, review out of order, and go deep.

Jeff Bezos also stated that the narrative is harder to write, and people need to put more thought into writing than creating flashy or text-sparse slides. At some point, Amazon switched to a six-page narrative document for communicating new ideas and proposals. Meetings and discussions were often one hour long, and the first twenty minutes were devoted to reading the document (three minutes per page times six pages roughly equal that first chunk of the meeting).

The format of the six-pager:

• Executive summary
• Proposed action
• What problem we’re solving
• Tenets (principles)
• Supportive information and evidence
• FAQ

Stated benefits:

• Presentation skills are not a factor; more focus on the idea presented
• No time spent on graphic design
• No need for additional notes or a different set of slides with more text; the six-pager stands on its own
• The act of writing forces the writer to think more deeply (I agree with this sentiment)
• More information density in docs as compared to presentations (spatial layout of information)

Operational notes:

• Appendices of six-pagers can go for longer than six pages, but they are only for reference.
• No need to go through the doc orally at the beginning of the discussion; everyone has to read the doc.
• Notes taken during discussions become a part of the narrative.

Working backwards

PRFAQ (Press Release / Frequently Asked Questions): The idea is to start with a press release that describes the benefits to the customers and then work backwards from there.

“Where are the mockups?” Jeff was asking this question before he would approve an investment because he wanted to know, and teams to think through, what would be the customer experience before the teams started to build anything.

Format of the PRFAQ:

• Heading: one sentence
• Subheading: one sentence, who is the customer, and what benefits they’ll gain from using the product
• Summary paragraph: city, media outlet, launch date, a summary of the product and the benefit
• Problem paragraph: what is the problem being solved as viewed from the customer’s perspective
• Solution paragraph(s): what will your product do, example customer quotes, where they can get more information
• FAQ (optional and free-form)

Internal sections of the PRFAQ (sections that can’t be published externally):

• Customers and addressable market
• P&L (profit and loss), upfront investments
• Dependencies (internal and external, 3rd parties)
• Feasibility (technical, UX, legal, organizational, and similar)

Metrics

Input (controllable) and output (uncontrollable) metrics. One should focus on input metrics. Input metrics measure things that, if done right, bring the desired results in your output metrics.

Examples of input metrics: selection, price, and convenience. Examples of output metrics: orders, revenue, profit (can’t be directly manipulated sustainably in the long-term)

DMAIC from Six Sigma (Define Measure Analyze Improve Control)

Define

Identify the correct and controllable input metrics.

There was an example where a team wanted to have a lot of items in the catalog. Initially, the team started to track how many product details pages they created, but this resulted in some items having dozens, or even hundreds, of unnecessary pages that nobody opened. The evolution of the metric progressed like this:

1. Detail pages
2. Detail pages that were viewed by customers
3. Detail pages that were viewed by customers and items immediately ready for the 2-day shipping (this metric was named fast-track in stock)

The new metric resulted in stocking items that are in demand and that can be delivered fast and not stocking items nobody wanted.

Measure

Beware of human biases that can skew the numbers. Can a team who doesn’t have skin in the game report your metrics?

Here is an example of how easy it is to make a mistake when measuring. Suppose some items are out of stock for most of the day, and you usually get a shipment in the evening just before you measure how many of your items are out of stock. In that case, your metric will show that you’re in stock for those items, even though that’s not what the customers will experience.

Analyze

What is driving your metrics? What are anomalies and outliers?

Using 5 Whys by Toyota Production System to get to the root cause of a problem.

Improve

Improve the metric when you spot a problem.

Control

Ensuring your processes operate normally and things are not degrading over time. When things happen through a repeatable process, it’s often automated.

Metrics are reviewed weekly with leaders of multiple teams. Sometimes the meeting would get a bit rough (the authors said this is one of the things Amazon could have done better).

Trends are usually caught later in the output metrics than they could have been in the input metrics. For example, revenue can still show growth and YoY growth can show slowing down, but it’s all the result of a slower customer acquisition (input metric) that was visible much earlier.

Numerical data become more powerful when combined with real-life customer stories (anecdotes). Anecdotes are commonly labeled as edge cases, but at Amazon, they knew that if something happened once, it would happen again. The anecdotes were also indicators of bigger problems that were not noticed until then.

Stories

The second part of the book tells how four successful Amazon products came to life using the tools and principles described in the first part of the book. The products are:

1. Kindle
2. Prime
3. Prime Video
4. AWS