Working Backwards

Leadership

Jeff read his team’s response to the columnist, seemed to read it a second time, and then said, “That’s perfect.” After that, apparently satisfied that customer service had now internalized the core principles he insisted upon, he checked in far less frequently.

This is how all management should be. First verify that they’ve completely absorbed your brain, expectations, and quality bar. Only then step away.

During the first critical years, Jeff could transmit the strength and clarity of his message directly to the small leadership team through daily and weekly interactions; he could be present for decisions big and small; and he could formulate and apply principles like customer obsession, innovation, frugality, personal ownership, bias for action, and high standards.

This is how leaders are forged. A visionary, typically the founder, works closely with a trusted group of early employees. These early employees then download the brain of the founder over time and go on to become execs and leaders within the company.

What distinguishes Amazon is that its Leadership Principles are deeply ingrained in every significant process and function at the company. In many cases, the principles dictate a way of thinking or doing work that is different from the way that most companies operate. As a result, newly hired Amazonians go through a challenging multimonth period of learning and adapting to these new methods. Because these processes and practices are embedded in every meeting, document, decision, interview, and performance discussion, following them becomes second nature over time. And any employee who violates them draws attention to themselves like a person loudly scratching their fingernails across a chalkboard.

I think we need to normalize this multi-month adjustment period. Ray Dalio said something very similar - most employees take up to two years to adjust to Bridgewater’s level of radical transparency. Around 30% do not stay with the company due to this adjustment period.¹

When I (Bill) first read through the long list of competencies as a new hire in 1999, I recall feeling a mix of inspiration and intimidation thanks to the combination of super-high standards applied across such a breadth of disciplines. I thought, “I will have to work harder and smarter than I have ever worked if I am to live up to these.”

I hope to found a company whose core values incite this type of reaction from an employee. Just wow.

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

If you practice what you preach every day, you don’t need to memorize anything.

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

Bezos always thinks about incentives - this is the main takeaway. Too many leaders just wish they could fight against human nature. Instead, use it to work to your advantage. Design a system around that.

…people already had good intentions when the problems cropped up in the first place. Amazon realized early on that if you don’t change the underlying condition that created a problem, you should expect the problem to recur.

Exactly.

“performance” in performance-based compensation must refer to the company’s overall performance, that is, the best interests of shareholders, which in turn are perfectly aligned with the best interests of customers. Accordingly, the compensation of Amazon S-Team members and all senior leaders is heavily weighted toward equity earned over a period of several years. The maximum salary itself is set well below that of industry peers in the United States. When we were there, the maximum base salary for any employee was $160,000…

Over and over, Bezos demonstrates how long-term he’s thinking.

…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. But on the positive side, Amazon’s approach reinforces the kind of culture it seeks to develop. Sometimes it is okay to lose people who have a short-term focus while retaining those who are in it for the long term.

Loudly declare what you stand for; if people leave, let them.

Hiring

According to Sequoia Capital, the average startup in Silicon Valley spends 990 hours to hire 12 software engineers! That’s more than 80 hours per hire, and all that time taken away from a team that’s already understaffed and working on deadline only adds to the urgency to staff up. 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 in. If you just pick people who have known characteristics, who already feel familiar, they seem likely to work out. The fact that they sometimes do succeed only makes matters worse, as it reinforces the notion that your process is good enough.

This 80 hours per engineer hired astonished me, but then I ran the math on Motion’s numbers and it came out to 83 hours per hire. Absolutely wild. I then had to make a bunch of changes, and since then our numbers have come way down, fortunately.

Seemingly overnight, the new employees can vastly outnumber their predecessors, and this dynamic can permanently redefine the corporate culture. Brent Gleeson, a leadership coach and Navy SEAL combat veteran, writes, “Organizational culture comes about in one of two ways. It’s either decisively defined, nurtured and protected from the inception of the organization; or—more typically—it comes about haphazardly as a collective sum of the beliefs, experiences and behaviors of those on the team. Either way, you will have a culture. For better or worse.”

Too many organizations have an accidental culture. Be intentional. Think deeply about what you want the company to stand for and make it a reality.

Many would ask if exceptions could be made. But of course, this was part of the problem—hiring almost always felt urgent. We know of no instances where managers were allowed to take shortcuts.

When you feel the most urgency, that is when you must refuse to raise the bar the most.

In general, my feeling on this section is Amazon runs a tight ship with a lot of common sense principles.

• Write down your feedback immediately after the interview, while it is still fresh
• You don’t get to see the other members’ feedback, to avoid bias
• Ask them questions plus or minus 1 level from the level to which they are interviewing
• Keep the candidate on track, don’t let them take long, winding detours
• Have debrief meetings

I’m sure at one point, these were revolutionary, but now nearly every company I have ever worked for incorporates some version of this.

Every résumé received from a female applicant automatically led to a phone screen. It’s important to say that this solution did not lower the hiring bar, nor did it favor unqualified candidates on the basis of gender. If the candidate did not pass the phone screen, they would not move forward to the next step in the process. This technique made it clear that when a candidate’s name implied the gender as female, an unconscious bias had been affecting the résumé screening. The result was that well-qualified female candidates were apparently being rejected too early in the process.

Not a surprise to anyone who’s worked in the tech industry for any period of time.

Focus

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

Absolutely vital to make sure each person within a company is only doing one thing at a time, so that each thing is done really well. That’s the only way you can compound and start addressing other problems.

The answer lies in an 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.

Yup.

Microservices

We had to coordinate every small step with each team because a single mistake on our part could affect their work or, even more catastrophically, could introduce a bug that would take the whole website down. Similarly, we had to dedicate our own time to reviewing their changes in this part of the code to ensure that our own functions were not impacted.

Why Amazon had to move to microservices. Honestly I still think this is the right call. If you’re building a whole suite of products, like AWS, then microservices is the right way to go. The cost of coordination is simply too high between that many people. Administration costs are huge.

The database was named acb, short for amazon.com books. If acb were ever to go down, the majority of the company’s operations would stop—no shopping, no orders, no fulfillment—until we could roll back the change and restart. As a vital safeguard, a steering group had been set up to review every proposed change to acb, approve the proposal (or reject it), and then figure out the best time to implement it.

It’s still called the books table to this day! Even though most orders aren’t books.

The variations in technical dependencies are endless, but each one binds teams more tightly together, turning a rapid sprint into a stumbling sack race where only the most coordinated will cross the finish line.

Yup, decoupling changes is essential to unlock speed.

You’d have to figure out who you needed to talk to, whether their office was in your building, and who they reported to. Maybe you’d track them down yourself, but more often you’d have to ask your manager, who in turn would ask their managers or their peers—and every step took time.

Life before Slack, lol. But still the point stands.

Too much of any kind of dependency not only slows down the pace of innovation but also creates a dispiriting second-order effect: disempowered teams. When a team is tasked with solving a particular problem and is judged by their solution, they should expect to have the tools and authority to complete the job. Their success should be a source of team pride. But Amazon’s tightly coupled software architecture and org structure too often made owners heavily dependent on outside teams, over whom they had little influence. Few teams were fully in control of their own destiny…

This is precisely why I hate big company lifers. They slice up the problem into five or ten discrete pieces and make teams responsible for each piece. The problem is the empty space between each slice is large enough to fill an ocean, and somehow even if every single team delivers their specific piece, the problem isn’t solved. Add to the fact that inevitably each team will be dependent on others to unblock them, it just leads to total disempowerment.

Where was it written in stone that every project had to involve so many separate entities? It wasn’t just that we had had the wrong solution in mind; rather, we’d been trying to solve the wrong problem altogether. We didn’t yet have the new solution, but we finally grasped the true identity of our problem: the ever-expanding cost of coordination among teams.

I worship at the church of Bezos.

Morale is, in a sense, an output metric, whereas freedom to invent and build is an input metric. If you clear the impediment to building, morale takes care of itself.

I love this. No more focusing on morale - only the freedom you’re giving your ICs.

Fitness Functions

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

Amazon does this concept of ‘fitness functions’ which is what every team is graded against. The key though is that every fitness function has a ‘yin’ and a ‘yang’ - in other words, you have to watch out for the unintended consequences. It’s hard to choose the goal. Great thought should be put into that. Figuring out how to get there is a responsibility of the team.

We questioned every metric from every angle, probing how those data would be collected and how the results would be used to drive the team accurately toward its goals. These meetings clearly established expectations and confirmed the team’s readiness. Just as importantly, they also built up trust between Jeff and the new team, reinforcing their autonomy—and therefore their velocity.

This is vital. Many things become useless once they’re measured. Some things are only trailing indicators. Choosing a leading indicator that doesn’t become meaningless as you measure it is not easy.

[T]eams spent an inordinate amount of time struggling with how to construct the most meaningful fitness function.

Good! It’s not easy. It should be hard. Think about it carefully.

[S]ome of these overly complicated functions combined seven or more metrics, a few of which were composite numbers built from their own submetrics.

A good fitness function is rooted in simplicity.

[W]e realized that as long as we did the up-front work to agree on the specific metrics for a team, and we agreed on specific goals for each input metric, that was sufficient to ensure the team would move in the right direction.

Ultimately it’s a way to disseminate the leaderships’ brain amongst the entire company. Why does the exec team value a particular metric? What value does it bring to the business? This is a forcing function to make every single person in the company grok and ultimately get behind the mission.

Written Memos

When authors learned that we were serious about a page limit, some squeezed as much as text onto a page as possible, using tiny fonts, reducing the width of the margins, and single-spacing the text.

Brevity is proof that you have put sufficient thought into your ideas.

Tufte estimates that 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.

Reading is more efficient! It’s also more permanent and searchable!

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.

Narratives allow for lazy thinking. Do not shield your thoughts behind eloquent speech or charisma. Let their brilliance be their only defense.

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.

Yup.

We know that people read complex information at the rough average of three minutes per page, which in turn defines the functional length of a written narrative as about six pages for a 60-minute meeting.

Business writing should be concise. I wish I could interrupt every English department in every university and replace their curriculum with a plain writing course.

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.

Get used to the silence. Just read!

[Bezos] 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.

Speed reading is not something to be lauded. Truly think critically about every single sentence that’s presented.

Working Backwards

Most of Amazon’s major products and initiatives since 2004 have one very Amazonian thing in common—they were created through a process called Working Backwards. [sic] [S]tart by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build.

This is the heart of the book and especially important for engineering teams. Most engineers start from the technology. They think about the current limitations and capabilities and let that constrain their thinking. Customers don’t care about technical limitations! Even if your customers are engineers! They want their problems solved, period. So you must start with the customer experience first.

…the company will never be driven to master new skills and develop new competencies, hire new kinds of leaders, or create different types of organizations. Amazon’s Working Backwards process—starting with customer needs, not corporate needs or competencies—often demands that, in Jeff’s words, we “exercise new muscles, never mind how uncomfortable and awkward-feeling those first steps might be.”

This is a cautionary tale about starting from technology / current capabilities first. If you do this, you will forever be limited by what you are capable of today. The market does not care what you can currently do.

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.

It’s very natural. You spend all day thinking about how to make your business succeed. The great irony is that it will succeed by focusing on other people’s success.

[D]uring our time with Amazon, most PR/FAQs never made it to a stage where they were launched as actual products. What this means is that a product manager will put in a lot of time exploring product ideas that never get to market. 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.

The cheapest time to kill a feature is before a single line of code has been written! Product should be thinking up all sorts of crazy ideas all the time. That’s the job. Then ruthlessly validate those ideas, and only when there is sufficient conviction, start building. However, this is probably one of the biggest things that has changed with AI. If the cost of prototyping is so cheap, I wonder if it’s even worth thinking through and writing such a detailed doc? AI cannot think for you, but the market (in some sense) can give you a lot of instant feedback.

The Working Backwards process is all about starting from the customer perspective and following a step-by-step process where you question assumptions relentlessly until you have a complete understanding of what you want to build. It’s about seeking truth. Sometimes the Working Backwards process can uncover some surprising truths. Some companies, in a rush to get a project to market, ignore that truth and keep building according to the original plan. In their attachment to the modest gains of that plan, they motivate the team to pursue it aggressively, only to realize much later that there was a much bigger gain to be had if they’d taken the time to question their own assumptions. The cost of changing course in the PR/FAQ writing stage is much lower than after you’ve launched and have an operating business to manage. The Working Backwards process tends to save you from the expensive proposition of making a significant course change after you’ve launched your product.

Working backwards is slower - but that’s the point. Slow is smooth, and smooth is fast. By carefully thinking about the various pitfalls ahead of time, you will ultimately end up going faster in the long run.

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

This can and will be uncomfortable for many people! That’s okay. Get them used to it.

…the extra time we spent slowing down to uncover the necessary truths was ultimately a faster path to a large and successful business.

It seems faster to just immediately start coding. But there’s a good reason experienced developers pause and think deeply about a problem.

Truth Seeking

Jeff and CFO Warren Jenson—who was succeeded in 2002 by Tom Szkutak—stated explicitly how critical it was for the finance team to uncover and report the unbiased truth. Jeff, Warren, and Tom all insisted that, regardless of whether the business was going well or poorly, the finance team should “have no skin in the game other than to call it like they see it,” based on what the data revealed. This truth-seeking mentality permeated the entire finance team and was critical because it ensured that company leaders would have unvarnished, unbiased information available to them as they made important decisions. Having an independent person or team involved with measurement can help you seek out and eliminate biases in your data.

Truth seeking is the primary job of a startup!

“When you encounter a problem, the probability you’re actually looking at the actual root cause of the problem in the initial 24 hours is pretty close to zero, because it turns out that behind every issue there’s a very interesting story.” In the end, if you stick with identifying the true root causes of variation and eliminating them, you’ll have a predictable, in-control process that you can optimize.

Every anecdote is important. It’s revealing a far more fundamental problem in the business than what actually appears. It’s vital to actaully go deep enough to solve the root cause - that’s the only way to guarantee the fire won’t surface in the future.

[T]he owners, not the finance team, are expected to provide a crisp explanation for variances against expectations. As a result, business owners quickly become adept at spotting trends.

If you’re the owner of a business, you should be the expert. You should know exactly what’s going on more than anyone. Outsourcing that to a finance team would be insane.

[S]uccess demands an environment where people don’t feel intimidated when talking about something that went wrong in their area. Some Amazon teams were better at exemplifying this than others were, and, quite honestly, it’s an area where the company could improve.

High performing teams can readily and obviously admit failures. The truth is what will drive you to improve.

Data and anecdotes make a powerful combination when they’re in sync, and they are a valuable check on one another when they are not.

Don’t blindly believe data without validating with anecdotes. Similarly, don’t exclusively trust anecdotes either. They are both signs of a deeper trend - one that bears investigation. The biggest failure mode of most data scientists is that they immediately believe the first pass of whatever data they find. The data is almost always flawed. Investigate it! Interrogate it. Data is guilty until proven innocent. Spot check 5% of the instances yourself and make sure it’s right.

Failure Is a Feature

[A]fter 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.” The magnitude of your inventions, and therefore your mistakes, needs to grow in lockstep with the growth of your organization. If it doesn’t, your inventions will likely not be big enough to move the needle.

I talk about this in the product market fit essay - but failures are necessary as the company scales. It is vital to take outsized risk to continue to produce outsized returns.

Kindle

Invention is not the solution to every problem. For instance, when Amazon started, the company did not create its own computer hardware. On the flip side, when we were planning our e-book business, we decided to get into the hardware game with Kindle. The reason: invention works well where differentiation matters. In the company’s early days, the hardware that powered Amazon’s data centers was not the point of differentiation with the customer—creating a compelling book-buying online experience was.

This is the key - find your company’s area of differentiation, and only innovate on things where you can provide unique value!

…what was true yesterday may not be true today. In fact, today Amazon does make some computer hardware to power its data centers.

Remember that the area in which you can differentiate relative to the market may change! Once Amazon launches AWS, of course they should launch their own hardware. But before that, why bother?

His next comment could reasonably be construed as either a matter-of-fact statement, an attempt to elicit an angry retort, or an attempt to goad Jeff into making a bad business decision by acting impulsively. He said, “Amazon has a decent chance of being the last place to buy CDs. The business will be high-margin but small. You’ll be able to charge a premium for CDs, since they’ll be hard to find.” Jeff did not take the bait. We were their guests and the rest of the meeting was uneventful. But we all knew that being the exclusive seller of antique CDs did not sound like an appealing business model. While it is tempting to suggest the meeting impacted Jeff’s thinking, only Jeff can speak to that. What we can say is what Jeff did and did not do afterward. What he didn’t do (and what many companies would have done) is to kick off an all-hands-on-deck project to combat this competitive threat, issue a press release claiming how Amazon’s new service would win the day, and race to build a copycat digital music service. Instead, Jeff took time to process what he learned from the meeting and formed a plan. A few months later, he appointed a single-threaded leader—Steve Kessel—to run Digital, who would report directly to him so that they could work together to formulate a vision and a plan for digital media. In other words, his first action was not a “what” decision, it was a “who” and “how” decision.

The “his” in this paragraph is Steve Jobs, egging on Amazon to try and match him in the iPod game! A bunch of people were pressuring Amazon for a me-too product. Wisely, Bezos realizes there is no differentiation if they try and match that. They need to go in a different direction entirely.

You can’t outsource a customized, integrated, end-to-end experience. 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…

If only American manufacturing knew this in the 70s…

We’d known the Kindle would take time and money to develop, but by the middle of 2005, it became clear that it was taking much longer and consuming more funds than we had anticipated. Sometime in 2005, a subset of the S-Team met with members of the finance team to review the company’s consolidated OP1. There was a heated discussion about the surprising ramp-up in expenses across many areas, particularly with Kindle. At some point in the debate, someone asked Jeff point blank: “How much more money are you willing to invest in Kindle?” Jeff calmly turned to our CFO, Tom Szkutak, smiled, shrugged his shoulders, and asked the rhetorical question, “How much money do we have?”

Iconic Bezos moment. Proof that he does not care about Wall Street expectations or profits. Cash flow and long term orientation is everything. The Kindle, of course, would go on to be the single greatest product Amazon ever made.

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.

Again - the customer experience comes first. If customers want to instantly download books to their Kindle, then that’s what we need to allow. A prime example of working backwards.

As Jeff often mentions, customers are divinely discontented, and “yesterday’s ‘wow’ quickly becomes today’s ‘ordinary.’

This is why there is always a new opportunity.

Prime

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.

Every company - even the greatest ones, hit a period of plateau. I talk about this multiple S-curve phenomenon in my why are startups hard talk. The remarkable thing about Bezos is that every single time they hit one of these moments, he leans into the harsh truth and they power through.

Jeff insisted on this path, which resulted in Amazon Prime. Now, this may be one of those moments when you’re thinking, “But we don’t have a Jeff.” The good news is that you don’t need a Jeff to make this type of decision. You only need to ruthlessly stick to the simple-to-understand (but sometimes hard-to-follow) principles and process that insist on customer obsession, encourage thinking long term, value innovation, and stay connected to the details. None of us, including Jeff, knew exactly what we would end up building; it’s more like we stuck with the process and surrendered to where it was taking us.

Precisely this. This line of thinking - customer obsession and long-term thinking - gave birth one of the most successful products of all time. And yes, it did solve Amazon’s growth problem.

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.

Just to show how dire the situation truly was. This was an all hands on deck, five alarm fire.

Cue the well-worn scenes of C-suite drama: Faced with financial trouble, the CEO calls an emergency meeting of top brass. He leaps to his feet, slams his fists on the table, and, with reddening face, bellows, “We need to grow revenue faster! We need more urgency about driving revenue! I want each group to develop and launch an end-of-quarter marketing promotion, so we can hit our numbers.” I have to admit that in the late 1990s, a few years before the Prime discussions started, we had a few scenes that looked a bit like that as we grappled with our growth concerns.

These types of situations are normal for every company. Would you rather have the CEO who over-reacts to every growth slowdown and visciously accelerates his way through? Or the one who calms everyone and declares that everything is fine?

Jeff exhibits discomfort when presented with an either/or proposition in which both results are mediocre. Viewed through the Customer Obsession and Insist on the Highest Standards leadership principles, the only answer to the question, “Which would you rather have, ‘slow and free’ or ‘fast and expensive’?” is “fast and free.”

The greatest always want to have their cake and eat it, too. The job is to figure out an innovative solution.

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.

Remember that if they don’t do something, it’s very likely Amazon dies. There is just no way to ‘measure’ that!

Jeff would likely have been making just such an error of omission if his October 2004 email had read, “Let’s wait to introduce free shipping and just focus on making this 2004 holiday season our best ever!” If he had stopped pressing the teams for more free shipping ideas, there would no doubt have been a sigh of relief. We would have looked at each other and said thank goodness we made the right call to pause. Instead of marking a turning point in Amazon’s history, that mid-October day might have been remarkable in another way. It might have been the moment we made a disastrous mistake, even if we didn’t realize it until years later.

They had to be aggressive. There are times when you simply cannot wait for all the data. You must act with conviction and urgency.

Since we couldn’t offer lower prices, Jeff felt we should do the next best thing: offer free next-day shipping.

Instantly, Amazon’s growth problems are solved.

Jeff sent an email to the relevant category leaders and S-Team members with his suggestion to offer free shipping on selected items. When he sent a team an idea, it did not need to be implemented, but it definitely needed to be evaluated and that evaluation needed to be communicated back to him. As Jeff Holden, a former SVP and S-Team member, once told Jeff, “You have enough ideas to crush the company.” (Jeff responded with his distinctive laugh.)

At least he has a sense of humor about it.

Self Assessments

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.

I really like how brutal and harsh Amazon execs are in their own self assessments. If we had to over correct in one direction, I’d rather people over corrected this way. Take your fuck ups seriously, and think about how you’d learn from this mistake.

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

Jensen is very similar - the business can absorb a lot of mistakes. If you’re earnestly trying to get better, you are smart, and you fit the culture, then why would I get rid of you?

AWS

After the launch, as we monitored the response, we had another surprise. 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.

The myth that Amazon created AWS purely to profit from the extra hardware needs in preparation for the holiday shopping season is just that - a myth. They legitimately launched AWS because they saw an opportunity. And then developers internal to Amazon validated that need!

…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. The one thing all these programs had in common was that their ultimate goal was to have their parties build new software that would in some way accrue benefit to their core business—such as Amazon affiliate sales, more eBay transactions, more Google searches, and more Amazon Marketplace seller transactions. All of us, leaders and developers from these companies, were looking at similar data and trends. We ran into each other at developer conferences, participated on panels together, and shared customers who were using our developer programs. We were all swimming in the same primordial soup. Yet it was Amazon who took the first step in web services and said, “Why don’t we build a set of tools that any developer can use to build anything they want, even if it has nothing to do with our core business?”

The more I read about eBay the more clear it is how badly they fumbled on just about everything. They really should have been the next Amazon + Yahoo + so much more. Yikes.

We’d both noticed the same thing—a phenomenon that Amazon would later refer to as “undifferentiated heavy lifting,” that is, the tasks that we could do for companies that would enable them to focus on what made them unique. This was an opportunity.

Amazon’s needs are felt by nearly everyone. The same insight would give birth to Stripe.

[W]e had acquired a core competency only a few companies could match. We had the capability to store massive amounts of data, perform computations on that data, and then quickly and reliably deliver the results to end users, be they humans or computers. [sic] We also knew our unique capabilities would not be unique for very long, which provided a sense of urgency. (The first company to offer a robust set of general-purpose web services wouldn’t be guaranteed to win in the long run, but the head start sure would help.)

I really appreciate the sense of urgency they had in this, despite how successful Amazon already was at the time.

It wasn’t unusual for a senior leader like Andy Jassy to choose to start a new business from scratch rather than to assume leadership of an established business. Just as it wasn’t unusual for Steve Kessel and Bill to move from Amazon’s then-largest business to one of its smallest, or for Colin and team to take a chance with releasing a new but controversial web service.

I really like this for a company like Amazon or DataDog or Stripe. Eat what you kill - go get a brand new division and get a greenfield opportunity. Make your own destiny.

---

This book is a must read. Bezos is one of the most brilliant and principled business operators of all time. I will never stop reading about him, but this one is especially good since it’s told from the perspective of execs who worked with him.