Review: Working Backwards by Colin Bryar and Bill Carr

The first half of this book does a great job of teaching some of the principles that made Amazon successful. There are a ton of deep insights in there and they are worth reading for just about every leader (of course, not everything will apply to every company: not everyone works for a hypergrowth, VC-backed company, that now has over 1 million employees). The second half of the book has stories of how these principles were used when building out specific Amazon products, which was moderately interesting, but had a bit too much of a “rah rah rah, look how great we are” marketing message, so I’d recommend skipping it.

Here are some of my key takeaways:

1. Good intentions don’t work. Mechanisms do.

As a company, you can’t rely on good intensions—e.g., “try harder” or “next time, remember to…“—as a way to solve problems. Most people already have good intentions: they are already trying hard and doing their best to remember things, but intent and personal desire just aren’t enough. To really fix problems, you need to put in place mechanisms: that is, you need to create or modify the systems and processes within which people work. This book goes through some of the key mechanisms they use at Amazon, some of which I’ll cover below.

2. The bar raiser.

Most people aren’t particularly good at interviewing. Moreover, we’re all subject to various biases, such as an urgency bias, where you might be tempted to compromise on a candidate in the interest of filling an important role sooner. Making the wrong hire is extremely costly to an organization: they slow down team members; they take up management time; they do inferior work; and eventually, you have to let them go. Therefore, you’re almost always better off leaving a role unfilled for a longer time than taking a risk on a rush hire.

One of the mechanisms Amazon uses to deal with hiring problems like this is to include a “Bar Raiser” in every interview loop. The job of the Bar Raiser is to ensure that every hire “raises the bar”: that is, they are better in at least one important way than the other members of the team they’d be joining. This way, with each hire, the team gets stronger and stronger. The Bar Raiser has the ability to veto any hire, overriding everyone else’s decision, including the hiring manager, if they feel a hire doesn’t raise the bar. To minimize the Bar Raiser’s bias, the Bar Raiser can never be the hiring manager, and is typically someone completely outside of the immediate team doing the hiring. Moreover, the Bar Raiser is never punished because a role went unfilled for a longer period of time.

3. Single-threaded teams

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

Amazon only takes on a new initiative if they can assign a dedicated team to work on that initiative—and nothing else. Inventing something new is hard enough even if you dedicate 100% of your time to it; if you try to split your time across multiple initiatives, you’re all but certain to fail.

In addition to having each team focus on just one thing, Amazon also designs teams to be able to work completely autonomously from each other. That is, rather than trying to find optimal ways to coordinate and communicate between teams, they try to eliminate the need for any communication or collaboration entirely. Therefore, each team must have clear, unambiguous ownership of specific features or functionality which they can build and deploy with minimal reliance on others: i.e., with little to no coordination or approvals from other teams. This allows each team to go extremely quickly.

Their first attempt at this was to organize around “two-pizza teams,” enforcing that teams could not be larger than the number of people you could feed with two pizzas. This led to two issues. One issue was that two-pizza teams were originally designed around a single manager that everyone, regardless of role, would report to; it turned out that “general managers” who had expertise to manage every single discipline on their team (e.g., engineering, design, sales, marketing) were extremely difficult to find. The second issue was that some initiatives needed more people than you could feed with two pizzas; in fact, it turned out that the success of a team was less tied to its size and more tied to whether the leader had the appropriate skills, authority, and experience to get the job done.

Therefore, the second attempt was to move to “single-threaded teams,” where each team focuses on just a single thing and is part of a matrix reporting structure, where each person on the team has a solid line reporting relationship to a manager in their own discipline / vertical (e.g., Engineers reporting to Engineering Managers), and a dotted line relationship to the leader of single-threaded team.

4. Written narratives instead of slide decks

Amazon does not allow presentations or slide decks in meetings or product review sessions. Instead, they require written narratives (typically 6 pages in length). They start each meeting with ~20 minutes of silence while everyone reads the narrative, and then everyone goes around the room and provides feedback. The author of the narrative never presents: they just listen and gather feedback.

This is based on a few tenets. One of these tenets is that it is the ideas, not the presenter, that should matter most. With a presentation, the skills of the speaker often have a disproportionate impact, with great speakers sometimes able to sell crappy ideas, and weaker speakers sometimes failing to sell great ideas. With a written narrative, it is the ideas and reasoning that take center stage. Another tenet is that a slide deck is a far less effective medium than a written narrative for complex decisions: that is, decisions that are important (“one way doors”) and involve lots of interconnected ideas, nuances, and data to explore. For these sorts of discussions, instead of a slide deck with sparse words, bullet points, and pretty images, what you really want is prose, data, numbers, and charts in a written format that makes it easier to contextualize, compare, narrate, go back and forth, and so on.

The format for a written narratives will vary based on what you’re discussing, but there are two sections that are particularly useful to include in almost every written narrative:

• Central tenets: right at the front, define the foundational elements of the reasoning that led to the recommendations in the document. If the central tenets are in dispute, it’s easier to address those directly in one place, than to debate in a dozen places all the steps/recommendations that logically followed from those central tenets. Example tenets: speed and quality are always important, but when forced to choose between the two, we will always prioritize quality; when forced to choose between building something convenient for customers or something convenient for ourselves, we always choose the former.

• FAQ: a strong written narrative not only makes its case, it also anticipates counterarguments, points of contention, and anything else that is likely to be misunderstood.

5. Working backwards: write the press release first

Whenever working on a new initiative, Amazon requires that you write the press release first: before any product has been built, before the initiative has even been approved, you write up a press release to announce what you have in mind. This is a key part of the idea of “working backwards” for which the book is named: writing the press release first ensures that, right up front, you think through things from the customer perspective. This includes forcing you to think through:

• The “so what?”: why should a customer care about what you’re building?
• The value proposition: how is what you’re building better than what’s out there?
• The messaging: how do you convey what your product is and how its better in a way that’s clear and compelling?
• The customer experience: how will customers use what you’re building?
• The must-haves: which features make the press release? These are the must-haves to build right away; everything else is a nice-to-have.

You write this all up, share it with the team for feedback, and iterate on the press release over and over to refine it until you are sure that what you have is worth building (and possible to build). It’s not uncommon to go through 10+ iterations of the press release before starting on a product. In fact, most product ideas never make it past this press release stage. This is a feature, not a bug: iterating on the press release is much faster than iterating on the real product, and it allows you to go through many options quickly, prioritizing only the ones you think will have the biggest benefits for your customers and company.

The key ingredients of a press release include:

• Heading: name the product in a way customers will understand. One sentence.
• Sub-heading: describe the product and its benefits in a way customers will understand. One sentence.
• Summary paragraph: the proposed launch date and location, plus a summary of the product and its benefits.
• Problem paragraph: the problem the product solves, as seen from the customer’s perspective.
• Solution paragraph(s): how the product simply & effectively solves the customer’s problem.
• Quotes: a quote from a company spokesperson and a quote from a hypothetical customer describing the benefits they are getting from the product.
• Getting started: describe how to get started, including links to where to get more info and purchase.
• External FAQ: answers to questions you anticipate from customers and the press, such as more details on how the product works, how much it costs, where to buy it etc.
• Internal FAQ: answers to questions you anticipate from the team reviewing the press release, such as TAM, economics, P&L, dependencies, feasibility, and so on.

6. Metrics

Amazon groups metrics into two categories:

• Input metrics: leading indicators that Amazon can control directly, such as selection (how many items they have in their product catalog), price (how much each item costs), and convenience (if the product is in stock or how long it takes to ship it).
• Output metrics: lagging indicators that Amazon cannot control directly, such as orders, revenue, profit, and stock price.

Both types of metrics are important. However, you should focus most of your energy on optimizing input metrics, because:

• Input metrics are those that you can influence directly.
• If you influence input metrics correctly, they lead to the output metrics you want.
• Input metrics are leading indicators, so they are better predictors of the future, and let you identify issues far earlier than output metrics, which are lagging indicators.
• Input metrics typically describe things that customers care about: e.g., product availability, prices, shipping. Output metrics typically describe things that the company cares about (e.g., revenue, profit, etc), but customers don’t care about those at all. Amazon’s belief is that the long-term interests of the company and its shareholders are perfectly aligned with the interests of the customers, so you’re better off focusing on the metrics aligned to customer success.

The key question is which input metrics should you optimize for? That is, which input metrics that, as you modify them, best lead to the outputs you desire? It can take a lot of trial and error to figure this out. Here’s an example from Amazon:

• Number of detail pages: they started with this as an input metric.
• Number of detail page views: they realized that detail pages no one looks at aren’t as valuable.
• Percentage of detail page views where products were in stock: detail pages people look at, but can’t buy from, aren’t as valuable.
• Percentage of detail page views where products were in stock and available for 2-day shipping: this ended up being the most valuable metric to optimize for.

Picking the right input metrics to focus on can have a profound impact. When Amazon was focused solely on “number of detail pages,” they spent a lot of time adding more and more items to their inventory, which drove up Amazon’s costs, but didn’t have as much of an impact on sales. The shift to “number of detail page views,” got the team to dig through customer search history, find out what customers were actually looking for, and focus their efforts on stocking those specific items, which had a far bigger impact on sales. And finally, the focus on keeping things in stock and available for rapid shipping ensured the team was adding items to their inventory that would drive sales immediately. This may sound simple in retrospect, but it’s very easy to pick the wrong metric, and miss these sorts of insights entirely.

Rating: 5 stars