It isn't a surprising statement to say that Amazon has leveraged unique business practices and leadership perspectives over the years — ones that have enabled it to launch successful product after successful product, from AWS and the Kindle, to Prime and a studio that produces films.
You've likely read about Jeff Bezos' "two pizza rule." Or heard about how Amazon leaders spend the first 30 minutes of a meeting reading six-page memos in complete silence. With the constant coverage of the company's trajectory, there seems to be an endless appetite for more details like these — the ones that promise to spill the secrets behind the success.
Colin Bryar and Bill Carr have plenty of insider tales to tell. Bryar joined Amazon in 1998, as the Director for Amazon Associates and Amazon Web Services Programs. He also spent two invaluable years as Jeff Bezos' technical advisor or "shadow," and later served as the COO for IMDb.com. Carr started a year after Bryar and went on to launch and run the Prime Video, Amazon Studios, and Amazon Music businesses before he left the company in 2014.
But while their brand-new book, "Working Backwards," certainly stacks up striking stories about working with Jeff Bezos, developing the Kindle and the early days of AWS, they'll be the first to tell you that Amazon's success can't be traced back to any one particular habit or practice. Rather, it's about the system Bezos and the leadership team engineered to run the company — the invention machine, as they call it.
"The businesses Amazon is in are very different, but I find that most people fail to focus on what they have in common," says Bryar. "They were all built and operated using the same process. Whether it's Prime or AWS, they all started from ideas on a whiteboard. They've grown very large, but they've all come out of Amazon's invention machine."
Here's how Bryar and Carr describe the cogs:
14 leadership principles, including "Have backbone" and "Dive deep."
Four cultural pillars: long-term thinking, customer obsession, the spirit of invention, and pride in operational excellence.
Five very specific processes: how Amazon hires, how they organize into single-threaded teams, how they communicate using narratives, how they use the working backwards process for product development, and then finally, how they measure and operate the business by focusing on input metrics.
The book goes into granular detail in each of these areas, mapping out a manual for any founder or startup leader to consult as they look to bend the shape of their own company's trajectory. With "Working Backwards" hot off the press — and almost prescient in its timeliness, given last week's announcement about Bezos stepping down — we were grateful that Bryar and Carr made time to sit down with us and share several tactic-laden takeaways from their book as a preview.
In this exclusive interview, this duo of former Amazon executives unpack the invention machine and offer up six lessons worthy of study by any startup. Bryar and Carr take care to not just share the fascinating origin stories behind Amazon's practices and products, but to also draw the connection to what other companies can learn from them — whether it's their insights on why innovation can't be a part-time job or their warnings against the perils of taking a "skills-forward" approach to exploring adjacent business opportunities. We get into what it means to be a great operator, the importance of mechanisms over intentions, and how to stay truly customer-obsessed.
LESSON #1: SLOW DOWN TO INNOVATE
In our conversation with Bryar and Carr, we mostly focused on how Amazon has launched so many horizontal products and businesses that end up getting to meaningful scale — even though they're seemingly unrelated.
As any founder will tell you, expanding outside your core business is exceptionally hard. Companies tend to focus on a singular product for many years, and if they do launch ancillary products or services, they don't always make an outsized impact on the bottom line.
"More so than most companies, Amazon thinks about creating value for customers, focusing specifically on how they can create unique and distinct products. Many companies get tripped up and think about innovation as something where they need to come up with ideas, quickly get them out and test them, in the sort of agile method of iterating quickly," says Carr.
But time and time again in Amazon's story, they went in the opposite direction. "Take AWS. It reached $10 billion in revenue in less than four years. But what's remarkable is that they didn't get there by forming a team, writing a lot of code, and then testing and iterating. In fact, it took more than 18 months before the engineers actually started to write code. Instead, they spent that time thinking deeply about the customers they were trying to serve and forming a clear vision for what AWS should be," he says.
"Around 2004, 2005, we had an inkling that there was a new paradigm in how engineers would build and deploy software, but we didn't quite know how to expose it to the outside world," adds Bryar. It wasn't until after countless drafts and iterations through the PR/FAQ process (more on that later) with Bezos and now-incoming CEO Andy Jassy that the product started coming to life.
Many companies think you have to go fast to go fast, but Amazon went slow to go fast.
"Moving fast isn't about moving quickly, throwing stuff over the fence, or launching it in an app to see how it sticks. Stopping to think about the value you're trying to create for the customer and the problem you're trying to solve is essential, especially when you're moving into a brand-new area," says Bryar.
LESSON #2: BRAINSTORM AROUND THE CUSTOMER'S NEEDS, NOT YOUR SKILL-SET
But even with that mindset in place, there's still the question of where to build your next business — unsurprisingly, this is also an area where Amazon diverged from the norm.
"Most companies take a skills-forward approach saying, 'Hey, we're good at e-commerce,' or 'We're good at retail,' essentially looking for adjacent businesses to build that leverage the strengths they already have," says Carr. "Frankly, I was taught this when I was in business school. But Amazon succeeded by taking a contrarian approach."
Carr's own experience spinning up their digital media efforts serves as a prime example. "It was the beginning of 2004. At that time, Amazon had over $5 billion in revenue, which was certainly a big number. But the bad news was that 77% of all of Amazon's global revenue was for physical media products — books, CDs, DVDs, VHS tapes. The writing was on the wall," he says. "More than a million iPods had been sold, and Napster had proven the trend of sharing songs and creating playlists was here to stay. So Bezos pulled me and my boss, Steve Kessel, off of the physical media business — which was then the largest in the company — and told us to go figure out how to build a digital media business, something neither Steve nor I knew anything about."
Like the AWS process, Carr and Kessel spent more than 18 months coming up with different product ideas. "We had probably more than 50 different ideas. The standard approach would have been for us to go build our own knockoff, iPod and iTunes competitors. But we intentionally did not focus on that because we wanted to invent something new on behalf of customers to create real value," says Carr.
Instead, they were drawn to another idea: ebooks. "It was sort of a nothing business at that time. You could only read an ebook on your PC or your Mac. The prices were high, and there was a pitiful selection — maybe 15,000 ebooks available as opposed to the hundreds of thousands of books in print. Put simply, there was no good reason for people to buy and use ebooks back in 2004. But we tried to envision, well, what would change that? And through an iterative process, we came up with the idea for the Kindle."
Here's where the skill-set comes in. "When we came up with that idea, several things were true. First, we had never built a hardware device as a company. We sold tons of electronics as an e-commerce retailer, but we certainly had no capability to build one. And I remember questioning our wisdom at one point, like why on earth would we go build our own device? But instead of taking a skills-forward approach, we said 'What would be the product that, if we could create it, customers would love it?" says Carr.
Design around customer obsession first and foremost — then you can seek out and develop the skills you need to get there.
"Second, we didn't outsource it to an OEM or ODM to design and build this for us. Instead, we hired up Greg Zehr from Palm to build up that team." Carr notes that this approach set them on a windier, longer path — the Kindle didn't launch until 2007, more than three years after they had started working on digital media.
"So much time was spent on those details that would delight customers, like when you opened up your Kindle, and it was already associated with your account, so any ebooks that you had bought were already downloaded. Or the fact that the device was always connected to the internet, so there was one way to shop, download and start reading on one device. These were all breakthroughs at that time," he says.
With any new idea that you're developing, the customer should be front and center in everyone's mind — don't move on until you get that right.
LESSON #3: STAY FLEXIBLE ON THE DETAILS, BUT DON'T LET INNOVATION BECOME A PART-TIME JOB.
The development of Amazon Prime took a different path. "We created Prime to solve a very specific customer problem — they didn't like paying for shipping. That wasn't a hard one to figure out," laughs Carr. "The hard part was how we could afford to construct a program that would enable us to do that, since shipping costs real money."
The team experimented with various free shipping promotions. "The one that stuck the longest was called 'Super Saver Shipping.' You got free shipping on Amazon for many years by placing an order for $25 or more. The trade-off was that the items would be delivered to you more slowly," he says. "But we still ran into two issues: lower-priced items didn't qualify, and people don't really like having to wait for stuff. We had to work through many different business models and ideas before we landed on the one that became Prime. In this case, many people contributed, but Bezos was the person who finally came up with that idea and pushed for us to go do it."
Amazon has an attitude of being stubborn on the vision but flexible on the details.
The story of how Fulfillment by Amazon came to be offers a cautionary lesson about getting too flexible, though. "Enabling merchants to outsource warehousing and fulfillment of the items that they sell on Amazon and other retail sites is a huge business for the company — and I think it was apparent to many of us what this could be," says Carr. "But for a number of years, this project that we called self-service or fulfillment just bounced around the company."
For anyone who's worked at a mid-to-large-sized organization, this is a familiar tune. "It was always on a long list of initiatives to do, but it was never actively worked on," says Carr. "That is until Jeff Wilke — now the outgoing CEO of Amazon's consumer business — assigned one of his strongest VP lieutenants to drop what was a very large role in the operations organization and completely focus on it. Then we were able to identify the resources we needed, hire and develop the right team, and finalize the product — building and launching that program in only a matter of months."
The key lesson here? "Good ideas can get trapped inside big companies because they're not staffed to succeed. The challenge at any established company is that the demands of your core business will always soak up all of the bandwidth of your leaders." This is where Amazon's solution of single-threaded leadership, or having a leader and team work on one thing and nothing else, comes in. "It gives them the appropriate focus to ensure they can devote time and attention to make the business a success," says Carr.
To quote Amazon's David Limp, the best way to ensure that you failed to invent something is by making it somebody's part-time job.
LESSON #4: BUILD BY WORKING BACKWARDS.
As Bryar and Carr have alluded to, those 18-month voyages of discovery for the ideas around the Kindle and AWS were anchored in the concept of working backwards, more specifically the Press Release/Frequently Asked Questions document (PR/FAQ).
"Going back to when Kessel and I were developing our plans for digital media, we both had MBAs, so we pulled out our MBA toolkit, and did what you're supposed to do — look at industry analyses on the projected sizes of market segments in future years, come up with some projection for what our market share will be, and build a pro forma P&L, factoring in fixed and variable costs," says Carr.
"We put all of that together, took it into Bezos, and said, 'Here's what the business will look like. We're ready to go ahead and get started hiring out the team and negotiating rights agreements with publishing houses, record companies, and studios. And Bezos just looked up from all these spreadsheets and said, 'Where are the mockups?' By that, he meant, what would the website experience look like? How would customers actually buy and interact with these digital media products? We had not done any of that work yet — so we went back to the drawing board and came back with some mockups. But that didn't go very well either," Carr laughs.
"Frankly, we hadn't thought through all the details. We weren't thinking big enough about what we were going to do. We saw it as an extension of our physical retail business, and we hadn't factored in how digital media was different. Our role as an aggregator in digital media wouldn't confer much value to consumers — we hadn't really unlocked any of the problems to make that digital media useful and valuable. There were all these problems: bandwidth was bad, streaming didn't exist, there weren't many devices. By asking us for mockups and challenging our assumptions, Bezos forced us to push out to the ends of the value chain and think much bigger."
Press releases before products.
But instead of doing yet another round of mockups, they took a different approach. "Working with a designer to come up with a good mockup takes so much time — you end up spending more time building the mockup than actually thinking through all the issues and details of the customer experience. So, in the end, it was much more effective to just write it all down in a Word document, describing the customer experience we were going to create and clearly articulating the problem we were trying to solve. We probably spent four hours going through 12 different product ideas, but now we were actually getting somewhere," he says.
Your process for finding new product ideas should come down to this: What helps you make the right decision to take the next step and figure out if A) this is the customer problem you want to solve, and B) this is the customer experience that solves that problem?
It was during this process that the practice of starting with the press release was born. "After a few of these meetings, Bezos landed on the idea that to make the process better, we should just write the press release now," says Carr. "That normally happens at the end of the process, months or even years after the product and engineering teams have already made decisions that will affect how the product is sold and marketed. Instead of tossing it over the wall to marketing, Bezos said we should start at the end and work backwards."
There are considerable advantages to this approach, says Bryar. "You can write these press releases very quickly and form a meeting to review lots of them. Over time, the best ideas float to the top — it's quite apparent which ideas have staying power and which ones don't. If they're well written, they are easier to judge than a bunch of spreadsheets and financial projections that, quite frankly, have high error bars."
But of course, not every press release sees the light of day — many wind up sitting on the shelf. "The questions to think through are, is it big enough to move the needle? And not just next quarter, but long-term?" says Bryar.
If you can't describe something that sounds compelling and that people really want and need in a one-page press release, then there's no point in building it.
Spot the potential potholes early on.
Now to the FAQs. "Those are designed to help address the challenges that will undoubtedly crop up for a product that doesn't yet exist. What solutions do I need to come up with to actually build it?" says Carr. "The FAQ can be many pages long for a complex project. The thinking is that by iterating on it with the senior leadership team, when they give the green light, everyone is operating from the same basis of understanding the risks. So when a project fails, they're not going to blame the team unless there are issues of execution."
Often, the FAQ section spikes out serious concerns that can derail a project. "There are times where you read the PR, and the product sounds great, but there are considerable challenges or constraints in how to pull it off. For example, enabling every little local retailer in the U.S. to go online is a cool idea. But when it comes to sourcing real-time, accurate inventory information from lots of small and medium-sized businesses, there's no known, scalable solution to that problem," says Carr. "Another hurdle is that sometimes the technology may not be ready yet. In the very early days before the Kindle was really taking shape, display technologies weren't available in high production volumes," Bryar adds.
"Of course, the PR/FAQ work isn't all that's going on. With AWS, for example, there was engineering work required for some of the things that the team had to invent, specifically, in terms of how to get a network effect when it scales. There was a lot of research that the current CTO, Werner Vogels, had brought into Amazon, and the technology was finally ready to match that, but it took a while to solve," says Bryar.
"While we wanted to build a simple storage service, many of those early meetings were about, how is it going to scale? How is it going to fail? What types of failures are acceptable, and what types aren't? Can you predict the reliability in advance? Those are very, very hard engineering problems, and you don't just solve those by writing a couple of extra paragraphs in your press release."
But as Bryar notes, there's an upside in uncovering these hurdles before you go too far down the road. "It's a lot cheaper to answer these questions at this point than later on in the project when you've started building, and some of the paths that you may have wanted to explore are blocked off because of either design choices you made or the partners you built with," he says.
Carr concurs. "The PR/FAQ exposes the key assumptions and risks. We've all seen when a team has a good answer and a solid plan for how they're going to overcome a hurdle versus a team that is either dismissive or hasn't put much thought into it. It's similar to how VCs look at pitches they're evaluating — they know the difference between those two things," he says. "And just like in venture capital, you don't ever really know whether it's going to work or not, but at least the senior leadership has a common understanding of what the problem is, how they're going to solve, and the real challenges."
Of course, just as with startups, not every idea has the legs to go the distance. "It very well may not succeed. And then you make the decision: Do we want to go for iteration number two? Or do we want to stop and move on? The Fire Phone is a good example — there was no Fire Phone 2," says Bryar. "But with the digital media business example, I can tell you that if those first iterations didn't take off, we would have stuck with it — otherwise, a good chunk of our business was going to go away. And it better be Amazon that was going to cannibalize that business than a third party."
Ultimately, these business decisions are complicated. These processes and frameworks that Amazon has put in place are designed to stack the odds in your favor, but at the end of the day, it's not a true experiment if you know that it's going to work beforehand.
LESSON #5: INTENTIONS DON'T WORK, MECHANISMS DO.
When asked about his biggest takeaways from working as Bezos' "shadow" for two years, Bryar makes this observation: "Most people are actually trying pretty darn hard, and they have good intentions. So when we ran into an issue or a problem, Bezos would always ask, 'Do we have a mechanism in place so it doesn't happen again? Because if this high-performing or well-intentioned person tripped up, there's probably a process that we need to fix.' This gets back to the idea that customer obsession can't just be a poster on the wall — it won't happen on its own."
There's an old adage at Amazon: Good intentions don't work, mechanisms do.
This focus brings out a unique facet in the company culture, Carr says. "In my experience, senior leaders usually don't actively seek out problems and defects. You have to intentionally create processes and incentives to cultivate the culture that will go against that grain."
Here, Bryar and Carr share are a few examples of mechanisms Amazon has put in place to keep customer obsession front and center:
Correction of errors report. "Whether it's a technical glitch or an error in the analog world, teams are responsible for coming up with this report. It's a very clinical study about what happened," says Bryar. "We use the five whys approach from Toyota to keep going down to the next level of detail until you've identified all of the root causes because it's usually not just one thing that caused an error. Then those teams have the responsibility to fix what they've identified. It's not fun to talk about how you caused an outage on this portion of the app, but it's an essential process."
Voice of the customer. "This one is sharing anecdotes to look at a particularly gruesome experience that happened with the customer, usually at weekly business reviews. Sometimes it's reading the actual customer feedback on what happened. These problems don't often bubble up to leadership. They're painful to hear, but it reinforces the connection that you have to your customers' lives," says Bryar.
The Andon cord. "This one was also borrowed from Toyota. If someone working on an assembly line encounters the same problem on multiple cars, they can pull a cord which stops the entire production line, and they don't restart until they figure out what the problem is," says Carr. "Bezos encountered this by sitting in with a customer support rep. A call came in from a customer with an issue on a specific item, and very quickly, the support rep said, 'Oh, based on this item, I know what the problem is going to be.' After the call, Bezos asked how they knew what the problem was going to be. And they said that they'd seen the same problem over and over again, it was some defect from the manufacturer. So Bezos then gave the reps the power to 'pull the Andon cord,' — meaning the item is no longer available to sell on the detail page until the issue is fixed."
Mechanisms are also vital when managing through a multi-customer problem. "In my role, I had business partners at the motion picture studios and record companies, and I was responsible for making sure that we had productive relationships. So many times, they would come to me with a specific ask that I felt wasn't in the best interest of our customers. And a big part of my job was to say no to them and make them quite unhappy," says Carr. "I remember one partner saying, 'Bill, I really respect you and Amazon, but it would be nice if from time to time when I asked you for something that you could just do it for me as a favor.' But it was my job to fight for the end consumer first."
Bryar points to another example. "Be crystal clear on what types of problems and issues you're trying to adjudicate. Very early on, when we were only selling books, publishers didn't want negative customer reviews. One called Bezos up and said, 'You do realize you're in the business of selling books. Why are you telling people not to buy a book?' After thinking about it, he said, we aren't really in the business of selling books — Amazon is in the business of allowing customers to make informed purchase decisions. And if in some cases that means you steer a customer away from making a purchase that they would later regret, that's beneficial for Amazon in the long haul."
LESSON #6: GREAT OPERATORS DIVE INTO THE DETAILS
"There are some things that you can learn and teach. And then there are some things that you can't — you can't teach someone to be smarter. But you can teach someone how to be a better operator," says Bryar. "Once you learn what types of metrics you need to look at and see operational excellence in an action, then you can pattern match throughout your career."
Measure the metrics that matter.
"Just think of a business as a process. It can be a complicated process, but essentially, it spits up outputs like revenue and profit, numbers of customers, and growth rates. To be a good operator, you can't just focus on those output metrics — you need to identify the controllable input metrics. A lot of people say that Amazon doesn't really care about profit or growth. I think that the data say otherwise, but what is true is that the main focus is on those input metrics," says Bryar.
"If you do the things you have control over right, it's going to yield the desired result in your output metrics. The best operators I've seen very clearly understand that if they push these buttons or turn these levers in the right way, they're going to get the results they want. They understand that process through and through."
These input metrics are usually customer-related. "Is the customer experience getting better this week than it was last week? That's harder to figure out than it sounds. So you monitor 10 or 20 different things, you experiment a little bit," says Bryar. "Measure them day in and day out — a great operator always instruments, so they know exactly what's happening. If you don't measure something, it's going to go wrong."
He shares some sample input metrics that Amazon closely monitors. "For the retail business, what are the prices down to the product level, compared to what's out there on the market? How many new items were added? How many are in stock and ready to ship via Amazon Prime? What is the average delivery time? What was the number of orders? How many promises did we miss? What was the number of defects?" he says.
"Another great input metric that doesn't see the light of day is that Amazon pays a huge amount of attention to inventory record accuracy. If I have an item, is it actually on the aisle bin and shelf that I say it's on? This is hugely important — if someone goes to pick that order and it's not there, you've missed that customer promise."
The bulk of these input metrics should describe how the customer used the product or service, Bryar notes. "It's like you're a sole proprietor in a coffee shop. You get to see how long the lines are. You get to see if people think the coffee's too hot. You have to recreate those metrics, especially as your business grows and there are more and more proxies between you and the customer."
Constantly maintain your connection to your ability to say, "I know what my customer experienced last week."
Diving into the details ≠ micromanagement.
"To codify Amazon's leadership principles, Robin Andrulevich interviewed different leaders of the company," says Carr. "One of her role models was Jeff Wilkie. At that time, he was the SVP of worldwide operations of the company. And from observing him and how he operated, Andrulevich came up with the principle of 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,'" he says.
"What separates an average from a great operator is that the best ones really dive into these metrics in great detail and tear them apart. They're skeptical about whether that metric is really measuring what you mean it to measure. They're constantly devising new metrics based on their observations and problems or defects that occur," says Carr. "Those are actually the best times to dig into the metrics. Why didn't I have the right metrics upstream to detect that this customer problem would happen? And what new metrics do I need to develop to prevent this from happening again?'
It's not by luck that Amazon delights so many customers — there is an inordinate amount of operational rigor happening behind the scenes.
Bryar shares an example of just how deep Amazon leaders dive. "Take the annual planning process in 2010. The leadership team sets what they call S-team goals, which are important enough for them to monitor. There were 452 of them that year, and they were very, very detailed goals. How much selection are we going to add for this category? Are we going to bring down the latency of this AWS service, from X to Y? That was the level of detail that Bezos and his direct reports got to," he says.
Some may argue that this practice of diving deep into these input metrics' reedy waters borders on micromanagement. "You can't send someone on their way and say, 'Come talk to me again in 12 months, and we'll see how it all worked out.' You need a process to review and audit progress. In contrast, my definition of micromanagement is when your manager is looking over your shoulder and trying to do your work for you," says Carr.
Bryar agrees. "As some organizations grow, the leaders think, 'My job is just to focus on the big picture.' At Amazon, leaders are expected to know what's happening with their business at an incredible level of detail. So deep diving isn't micromanaging — it's staying on top of the details of your business."
You can't get to a place where you don't know if your business was better this week than it was last week or this quarter over last quarter — otherwise, it will continue to get worse, undetected.
This article is a lightly-edited summary of Colin Bryar’s and Bill Carr’s appearance on our new podcast, "In Depth." If you haven't listened to our show yet, be sure to check it out here.
Cover photo by Getty Images / picture alliance.