Pod Insights a16z Podcast Innovating While Scaling: Lessons from Amazon About this episode What can today’s startups learn from Amazon’s so-called “invention machine” and a culture of growth and innovation that led to several successful and diverse lines of products? As it scaled, how did Amazon define and adapt its culture and practices to promote innovation even as it got more complex and large? Longtime Amazon execs Colin Bryar and Bill Carr take us behind-the-scenes.
Transcript 12,285 words · 4 speakers
Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.
0:00 Speaker 00 What can today's startups learn from Amazon's so-called "invention machine" and the culture of growth and innovation there that led to several successful and diverse lines of products? As it scaled, how did Amazon define and adapt its culture and practices to promote innovation even as it got more complex and large? In this episode from February 2021, early Amazon execs Colin Bryar and Bill Carr go beyond the well-known artifacts of Amazon innovation, things like the memo or the press release before the product has even been built, and share the leadership principles, decision-making practices, and operational processes that helped Amazon continue to innovate and invent new products and learn from its mistakes, all while it scaled.
0:43 Speaker 00 It's all based on their book, Working Backwards: Insights, Stories, and Secrets From Inside Amazon, drawing upon the 27 years of combined experience they had of being in the room where it happened at Amazon.
0:57 Sonal? Hi, everyone. Welcome to the A60Z Podcast. I'm Sonal, and today I have another one of our special exclusive first looks at a new book episode. And it is both a very timely and evergreen topic because a new book coming out this week is titled Working Backwards: Insights, Stories, and Secrets From Inside Amazon. In it, authors Colin Breyer and Bill Carr, who between them have a combined 27 years of experience in the company, where Bill was Vice President of Digital Media, founded and led Amazon Music, Amazon Video, Amazon Studios for a decade, and where Colin started out in the software group, was a technical vice president, and then notably was one of Jeff Bezos's earliest shadows, a legendary program there.
1:41 Sonal? Fun fact, the first shadow before that, I believe, was Andy Jessey, President and CEO of Amazon Web Services, and now to be CEO of all of Amazon. The book actually shares the origin story of AWS, among other businesses there, which we touch on briefly. Though, as a reminder, none of the following is investment advice. Be sure to see a60z.com/disclosures for more information. But in any case, our focus today is really on what is the Amazon way? And can other companies really adopt? Certain best practices too. In fact, as fast growing companies establish and find their way, how do they define and scale their culture processes and more? We actually spend most of the episode digging in detail into two operational practices.
2:23 Sonal? In particular, the infamous memos instead of PowerPoints and working backwards from a press release and FAQs, given the presence of those two topics in tech folklore and lots of misunderstandings as well. So I actually probe for the origin stories, the specific details of how they do and don't work and other nuances. So organizations of all kinds can take what they want or need. Finally, we also debate within this episode, the trade offs of lean and minimum versus maximum viable products and whether the emphasis is on the wrong letter there, whether product managers have a role in companies organized like this and more topics throughout. But we start by very briefly discussing the foundational principles. And actually, the first question I want to start with, especially since I hate the why'd you write this book?
3:07 Sonal? Question, Colin, Bill, honestly, there's a tendency for folks telling these stories, these kind of narratives to do a sort of hindsight is 2020, not accounting for attrition data or the failure cases as well. So part of me is skeptical that startups can do what Amazon did. And what's most noticeable too, is that Amazon had not just one or two product lines, but literally entirely different, yet successful lines of businesses all under one roof. So what drives that? And can startups really relate to the Amazon story then?
3:38 Speaker 02 Well, one thing is that the businesses you you mentioned, they are substantially different. They require different expertise. There are different customer stats, AWS is B two B. There's streaming video. There's that e-commerce business, but they all have one thing in common. And that's what we talk about in the book and we call it the invention machine, which was the the process and principles that Amazon used to develop these businesses. And the ones that we talk about, they started off as ideas on a whiteboard or emails, which many people were skeptical we should even do. Some of them grew into household names, but they all started off very small and with just one or two people.
4:16 Speaker 03 I would first start by going back in time a little bit and place you sort of where Jeff Bezos was where all entrepreneurs start out. So at the beginning, Jeff worked out of a simple office building with a handful of employees and
4:31 Speaker 03 He would be hands-on for everything. The very first customer support emails like Jeff wrote or co-wrote. He could review the work and think about all the policies. He could direct the team and set the tone and the pace. Well, that works just fine when you're an early-stage company and, you know, there's fewer than 20 of you and you can all do a stand-up each morning and give me hands-on. But guess what? That completely breaks. Once you start to grow like a weed and you've found product-market fit, and suddenly you look around and realize you've got a team of 130, 200, 500, and you realize that there's all kinds of decisions and meetings happening around you. You can't be part of every decision.
5:13 Speaker 03 And so, to me, what's most remarkable, notable, is that Jeff sought to figure out ways to actually inject his lens of thinking into all those meetings, and then sought to create a bunch of processes that would reinforce the way he would think about the work or do the work itself.
5:34 Sonal? It's this idea of operationalizing the invention machine, as you guys are describing it. Some of those principles and processes at a high level. To quickly summarize, just that context for our listeners. They range from customer obsession, ownership, invent and simplify, "are right a lot" for leaders, "learn and be curious," "hire and develop the best," "insist on the highest standards," "think big," "bias for action," "frugality," "earn trust," "dive deep," "have backbone," "disagree and commit," "deliver results," which I love. And we don't have to unpack all of those because that will take like all day and it's a whole reason your whole book exists. I do want to ask about one before we go into some of the other practices, which is around leading. And the one that really intrigued me was number four. "Are right a lot." And you basically write that leaders are right a lot.
6:19 Sonal? They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs. And I love this because I always think to myself, yeah, damn it. Leaders should be right all the time. Their instincts should be damn good. Tell me more about that one because that one made me chuckle a bit.
6:34 Speaker 03 Yeah, this is, and just to be clear, of course, we did not write that. That is Amazon's words that Jeff and the S-Team being his direct reports painted. painstakingly reviewed to come up with that exact language to define that principle, as with all 14 others. And they sweated over the details of every word, every sentence. And this principle, Right-A-Lot, in some ways, it's very straightforward, which is that as you move up, an early-stage CEO, as they grow and progress, they need to be more in the mode of delegating important work and auditing work, but their most important job, frankly, is to make decisions. And many decisions will come to you, whether it's presented with a spreadsheet, a document, PowerPoint. There's all kinds of data that we presented to you with those decisions.
7:16 Speaker 03 But there are very, very few problems where the data gives you the answer. At the end of the day, you're going to have to use your judgment. What Right-A-Lot refers to is, number one, when those leaders are confronted with those decisions, that more often than not, they pick the right door. But the second part of the definition refers to, more importantly, how those leaders make decisions, which is, a lot of people think that leadership is about their very strong opinion, arguing their opinion and winning that argument. And what great leaders do, actually, is they can stake out a position,
7:57 Speaker 03 but they are willing to update, meaning change their mind on what is the right answer based on new information. And, you know, even Steve Jobs talked about this at Apple, where some product that they launched ended up being a mistake, and there was, one of his reports had been telling him all along, "We shouldn't do this, we shouldn't do this, we shouldn't do this." And then after it launched and it failed, he came back to that person and said, "Why didn't you talk me out of this?" And the guy said, "Wait a minute, I tried to talk you out of it. What are you talking about?" And he said, "Well, you didn't do a good enough job because you didn't present the evidence to me in a persuasive enough way to make me realize why your point of view was so important." And so it's thinking about it and framing it that way, about bringing forward the right data and the right information.
8:41 Speaker 03 And then it's also the job of leader to solicit that to make the best decision.
8:45 Sonal? Well, that is a perfect segue to a question I'm dying to ask you guys about, because so many companies, their culture is like the mission statement and the values that you shove in a drawer. And so people spend so much time talking about the words and the precision of what they want those principles or values to be, but not actually how to operationalize it. So in that vein, because your book really does outline how to operationalize that through the processes. And practices that you guys share. One of the ones that comes up all the time in Silicon Valley folklore is the infamous, no PowerPoints, write a memo. So let's tackle this one first because what you just shared, Bill, about convince me, share the evidence in a persuasive way. The point is to be effective and be heard, you have to do that well.
9:25 Sonal? So what is your best advice about how leaders and people in the group can share that information?
9:31 Speaker 02 So Amazon started experimenting with writing narratives in 2004. And it was a result of weekly meetings, four hours every week with the S-team, Jeff's direct reports where two to three teams would come in and give either updates on their business, it could be a decision that needed to be made, or investigating new areas to go into. And the business was growing fast and we realized that we're not making the right types of decisions. Some of the meetings would go over, we never really accomplished what we wanted to. I was Jeff's TA at the time. We had been looking at other ways to conduct meetings and we're big fans of Edward Tufti, who's professor emeritus at Yale. He came to Amazon to speak a couple of times.
10:16 Speaker 02 And after one particularly painful meeting, it was later on in the week, it was toward the end of the day, Jeff said, let's stop doing PowerPoints at these S-team meetings. It's the wrong tool for what we're trying to do. And let's switch over to narratives, which are really just now a six-page memos. One thing that is a little bit misunderstood is these ideas don't come out fully formed. They started as four-page memos. It ended up that six-page was about the right length for an hour meeting. But we did it because narratives convey about 10 times as much information. You know, the pixel density is about seven to nine times the pixel density. People read faster than people talk.
11:00 Speaker 02 And you can have multi-causal arguments in a narrative much better than a hierarchical PowerPoint. But we realized we just needed a better way to analyze complex situations and make better decisions. So we just experimented with this and the first ones were not good.
11:16 Sonal? Just to quote you guys, because this actually made me literally laugh out loud. You guys write, "The first few narratives were laughably poor when evaluated by today's standards. Some teams ignored the length limit, blah, blah, blah." And I was like, yes, people are not, I mean, we may be wired to be good storytellers, but writing is actually a hard skills. I do worry that it becomes a bit performative for the best writers, not just the best presenters. Because one of my colleagues, when I used to work at Xerox PARC, used to call this pissing on paper, which is like this idea of like, you know, how dogs piss around their territory. There's also a real time component where people who are performing in real time, like leaving comments in the middle of the meeting.
11:52 Speaker 02 So a common misconception is, well, now it's just the best writers instead of the best presenters that's going to win out in narratives. We haven't found that to be the case. It's really the best thinkers write the best narratives. And some of the best narratives I've ever read are by people whose first language is not English.
12:11 Speaker 03 Yeah, in fact, the best narratives, many of them are written by software development engineers who may not have even focused on their writing skills. A good narrative, it's a very data-based and fact-based document. And writing good narratives is way harder than making a good PowerPoint. And I think honestly, you know, a lot of companies don't do this just because it's hard. When Colin and I brought this to other companies, what tends to happen mostly is that the author will vomit out about 25 pages of just sort of raw data at you. Getting that person to then shape it and narrow it down to six pages of well-thought-out narrative is really hard.
12:46 Sonal? Yeah.
12:46 Speaker 03 And oh, by the way, if you spend 10 hours a day reading detailed narratives, like I got to tell you, it can be mentally exhausting. But when people muse like, how does Amazon do it? Like, how's it possible that they can effectively manage such diverse businesses? One of my number one arguments is that they use narratives to conduct meetings, not PowerPoint. And actually, a former colleague of mine, Derek Anderson, who is now the Chief Financial Officer at Snap. I think he made the observation once that Amazon has like a narrative information multiplier. It's a strategic advantage that the company has over other companies because their executives are like seven to eight times better informed about what's happening in their company.
13:31 Speaker 03 And they're able to give super granular, specific feedback to those teams.
13:38 Speaker 02 It allowed the S team to stay connected at a much deeper level. As Amazon started to move into more and more businesses, the span and control of the S team didn't grow by 100x. It's still a relatively small team. And they are just as involved when it was a small company as they are now when it's a large company. The other thing I'd add about narratives is it does remove a lot of bias from the process where you can have a charismatic speaker with a so-so or even a bad idea that convinces your company to do something that you should not do.
14:10 Sonal? Yep.
14:10 Speaker 02 You know, the converse is also true. If you have a shy engineer with a great idea, but it's a boring presentation, it's one way in which Amazon removes bias to make better decisions. And the idea floats to the top rather than how good of a talker the person is.
14:27 Speaker 03 And we could go on about this forever, but the other part is it actually is a great way to get your team more engaged from top to bottom, especially in a COVID time. The way that these meetings work is you share the document and you know, whether it's with G Suite or with Word, then everyone can then use the comment feature. And it doesn't matter whether the person making the comment is a C-level person or a fresh out of college individual contributor. All of those comments get seen and heard. And then when you get it to the discussion phase, all those people actually can then understand, you know, why we're making the decisions we're making. When you do a PowerPoint, you have to wait to get to the punchline.
15:12 Speaker 03 And while you're waiting, you're not sure like, well, what are we actually doing in this meeting with a narrative? You just take all that in. And so then you can have high quality discussion versus that interruption and disjointed conversation you have with a PowerPoint. And if you miss the meeting, you can just read that document. So there are so many ways in which the narrative method is superior to PowerPoint that, as you can tell, we could never go back.
15:37 Sonal? Okay. So how does one do meetings then, based on these memos? One of the things you guys said is that sometimes it's shocking because the first 20 minutes of a meeting would be silent. And that made me chuckle, by the way, because one of the co-founders of Rome, the note-taking app, was sharing that sometimes they have entire meetings that are silent because they're just sharing notes with each other in Rome.
15:56 Speaker 02 Yeah, so Amazon meetings with narratives, they are strange to the uninitiated. There'll be the chit chat before a meeting, you know, when they were in person or, you know, it's online, people are starting to come in. But then there's silence for about 20 minutes. And during those 20 minutes, people are just focused on reading. There's no sound. They're entering questions and sometimes the presenting team can answer the quick questions and write in the comments. So for that 20 minutes, really, there's a huge transfer of information that you can't see. And then the rest of the 40 minutes is really just high-quality Q and A and discussion on the questions that have already been entered or that come up.
16:38 Speaker 02 The six-page narrative is a forcing function to where you can cover that amount of information in a one-hour meeting.
16:45 Sonal? Tell me a little bit more about what needed to change in the specifics of meetings in terms of running them, because the premise of this conversation is not everyone starts out as Amazon and that startups can do these things. I'm trying to really tease apart, like, are we just replicating the meeting dynamic in the memo and then the same thing happens anyway? People would begin reading in the meeting, but then how would the decisions happen? Like, what happens next?
17:09 Speaker 03 There are a variety of different kinds of documents you'd review in a meeting. It could be an annual operating plan. It could be a monthly business review. It could be a PR FAQ about a new product. So the conversation, literally what you do, once people stop reading is you just go page by page. Or alternatively, if it's a smaller group, and let's say there's just 10 or 15, you could literally just go around the room and say, okay, Sonal, you're first. What questions and comments do you have on the document? And so you would get the feedback, questions and comments from all participants. And then the document itself would present some sort of specific proposal. It's asking for some budget amount. It's asking for, are we going to launch this new product?
17:52 Speaker 03 And at the end of the meeting, you are tying it up and wrapping it up and saying either, no, we agree that what you've written in this document, that plan works, approved, go ahead. Or you debate and discuss it. One of the things you might do at the end of the document is make a clear section after you've presented all the facts to say, what are the decisions we need to make today? And then list those out. Or what are the important parts of this plan where we need your feedback and input? Like, we're not sure whether we should go down path A or path B. A good document will clarify what are the decisions we're going to make.
18:27 Speaker 02 The one thing I would add is that a lot of first timers to narratives, right after the people read, they say, let me walk you through the narrative. And you stop that right away. You know, you've just had that 20 minutes of high fidelity, Ben, why dumb it down with the two-minute verbal walkthrough of the document? You want to get to that feedback loop as quickly as possible, just talking about the document.
18:52 Sonal? We didn't actually really say what goes in the memo. You observe that the memos can vary in form and format by function and purpose. But can you at least describe what goes in the memo specifically? Like, even the ingredients would help.
19:04 Speaker 02 Amazon has different types of memos for different purposes. So if it's some monthly or quarterly or annual review, there's the typical, what were the key wins? What did we do wrong? And what can we do better? And what are the key initiatives coming up for the next year? You can have appendices too. And the appendices are supplemental data that everyone's not required to read in the narrative meeting. But if you do need to go jump to it to answer a question, you can.
19:32 Speaker 03 It would include tables with like, here's a summary of our financial results from the prior year. Here's a table, the summary of our plan for the next year.
19:42 Speaker 02 They also work very well with design, which you may not think about at first. But if you're going over mockups, either UI mockups for an app or physical prototypes of some hardware or process that you're going to build, having a narrative actually helps set the stage to say, before we take a look at anything, here's what we're trying to accomplish with the user experience. Here are our goals. Here are the challenges that we're trying to solve. You know, I've been at mockup meetings where everyone thinks they're a UI expert, but if you don't have that before and they comment on, you know, three or four things where you should move this over here. But you don't do that if everyone's on the same page with reading a short narrative beforehand. Another thing that can be in a narrative that's really powerful,
20:25 Speaker 02 especially for something that's going on on an iterative basis, as if you're refining an idea over time, are tenants. And those are really, okay, what are the design criteria that we are not going to compromise on or that we're going to fall back on when we have to make tough decisions? I mean, that's front and center, usually the up in the beginning of the document. Before we go over Amazon's pricing policy, I want to remind you, here are the four tenants that we're following to make the following decisions. And, you know, to get to those tenants, it was difficult. It took, you know, several meetings adjusting to say, these are the correct. That's a good caching mechanism because if you're a manager at a company that uses narratives,
21:08 Speaker 02 you're going to be context switching and reviewing multiple ones every day. And sometimes we only meet with the team once a quarter and you want to be able to very quickly get up to speed.
21:18 Speaker 03 There's another important technique where you can actually add at the end of the document, a fact section for frequently asked questions. So you're actually anticipating the kinds of questions that the audience are going to ask you. And a talented senior leadership team is going to ask you hard probing questions about things like, well, you say in your plan that you're going to go do X, but it seems to me that there's an important hurdle here of you're going to need this important partnership. You have this important dependency. What gives you confidence that you can actually solve that problem? And you would answer it. Not only does that help reflect whether the author and the team have good mastery of the issues, but it also helps speed up the discussion and
22:00 Speaker 03 the decision making. A lot of my work leading Prime Video was making very expensive multi-year agreements with Motion Picture Studios to acquire their films and TV shows for the service. These were big numbers, a lot of money involved. If we're going to go spend that much money, we're going to go write up a deal memo that describes like, okay, we think we should acquire these films and TV shows. Here's what the package works. Here are the detailed metrics that show why we think this is a good investment, or why not in some cases. Because sometimes we would review it and say, we've looked at this deal and we're not going to do it, and why. And again, just because it's a Word document doesn't mean you can't put in a chart, a graph, some in appendix, put an Excel table.
22:43 Speaker 03 All those things can still be in there, but then the narrative needs to clearly state with a clear beginning, middle, and end. Here's what we're proposing to do, or not proposing to do, and why.
22:52 Sonal? Yeah, I think that the thing I found most compelling is how much this mimics how writers think, obviously. One of the things that I found when I first came to a non-media company and was working at one previously was, oh my God, I have to make so many fricking PowerPoints. And I hate it because it's a muscle that's not ideal for storytelling as much as people think it is. It's not. It really isn't. But the next, what I love about what you're saying there is that the FAQs is actually the equivalent of doing the inoculation technique, which is what really good op-ed editors will really build in. And that's not just because you're trying to inoculate the counterparty to the arguments they're going to make. Actually, what you're really saying there, and I want to pull this thread, is you now can have a better, deeper discussion because you've laid to
23:33 Sonal? rest all the common things that you can literally get out of the way in like a memo in 20 minutes.
23:38 Speaker 03 Yeah, I mean, in a good document, that all comes out.
23:41 Sonal? I want to actually go back to the tenants for a quick second and then pick up on a thread that you brought up. One of the things, Colin, you described it as a caching mechanism for the leaders where they you have to do a lot of context switching so they get to kind of revisit that cache when they have to get back into that context. Yes. But I was thinking about it from the point of view of the group in the room, not just the leader, and how it really sets the shared context for the room to have the most collaborative mindset possible while disagreeing within that framework. And in your book, you write that tenants give the reader an anchor point from which to evaluate the rest. But here's the best part. If the tenant itself is in dispute, it's easier to address that directly rather than take on all the logical steps that derive from that position. And sometimes
24:26 Sonal? you guys spent meetings after meetings just debating to get the tenants right, which I think is really great because it allows you to actually separate the thing that the tenant is and then what flows from that.
24:36 Speaker 03 Yes, I spent 15 years at Amazon and I've since gone on. And one of the things that shocked me was that certain topics get like recycled for debate constantly, right?
24:47 Sonal? Yes.
24:48 Speaker 03 And I was like, whoa, we don't, we don't do that. We didn't do that back at Amazon. Well, why is that? And one is the use of a tenant, which is that all that debate and discussion can land on a fundamental issue about like what this company should or should not do. And if you don't come to a common agreement on it, then you will be constantly, you will waste so much time with relitigating these issues. The second reason is that what the narrative process forces you to do is by actually putting down a piece of paper, not only the tenant, but then like here, so here's the specific plan, then you set the date for the meeting and everyone reads it and then you decide. And I realized that
25:30 Speaker 03 a lot of those things get relitigated. So it was one of the ways which Amazon was very effective, which people don't realize, as a management company.
25:38 Sonal? Yep. On that note, does it then serve an archiving function for new hires and onboarding? That you scale that tacit knowledge that's been made explicit? How does that work?
25:47 Speaker 03 Great point, because the other thing I also saw is like whenever you hired someone new in, within a matter of a week, they would want to go relitigate. They too would trip across, well, why don't we do blank? Or, and it's like, oh, my gosh. And you can just say, look, here's the tenant, here's the document, you know, take a look at this and then come back and, you know, talk to me.
26:09 Sonal? Right. And then when you do decide to relitigate, it's an actual intent versus an accidental every new hire repeating, recycling the conversation. Okay. So the other big Silicon Valley folklore, when people talk about best practices from Amazon, is this idea of working backwards from the press release. Now, I know that you guys talk about working backwards well beyond. It's a reason it's a title of your book, obviously. But I really want to probe specifically into the mechanisms of what that means. Because like, how does that happen? Is it just, oh, I write a press release for this thing I want to do. It's a product, it's an idea, it's a service. I really would love to hear what, where, how, and why. And also I'd love to hear the origin stories, if you have any specifics there as well.
26:48 Speaker 02 At its heart, the working backwards process is really starting from the customer perspective. And everything you do works backwards from that. The PR FAQ, the press release and FAQ, that is the tool that Amazon uses to achieve the perspective of starting from the customer. It's different than how a lot of companies develop ideas and products. A lot of companies use a skills forward approach. What are we good at? What are our core competencies? What are our competitors doing? How do we nudge into this adjacent market? How much market share can we get?
27:22 Speaker 03 When I was in business school and taught to think about like how you expand and grow, as Colin already described, you create a SWOT analysis.
27:30 Sonal? Was it strengths, weaknesses, opportunities, threats?
27:33 Speaker 03 Right. But there's no, there's no C, there was no customer.
27:36 Sonal? Right.
27:36 Speaker 02 Amazon has put in deliberate mechanisms to make sure that the customer is front and center from the very first iteration of an idea. So if anyone says, raises their hand and say, I have a great idea. The first thing that the manager or the person in group will say, that's great. Why don't you go write a working backwards document? And what that is, it's two things. It's a press release and then a frequently asked questions document. And the press release has to clearly explain to the customer what it is you're building, what's the problem you're trying to solve for the customer? And why does it make their life better? It can be something very small or it can be moving into a brand new industry. It's a fractal process, which is great.
28:20 Speaker 02 Another thing is these PR FAQ documents, it's an iterative process. First of all, most of the ideas that go through it don't make it out on the other side. And second is that it takes several, several iterations and feedback to refine before the project gets greenlit.
28:36 Speaker 03 In fact, the origin story of like how we got to the PR FAQ, or at least a part of it, both Colin and I were present for this because in 2004, I landed on a new role working as one of the founding members of the digital media team at Amazon. For perspective, at the end of 2003, 77% of all of Amazon's worldwide revenue was media products, but it was all physical media products. It was books, CDs, DVDs, VHS tapes. And the writing was on the wall that like this business is not here to last. There was, there were already a couple million iPods that were sold. Millions of people were using Napster to file sharing. Napster. It's pretty clear that like, okay, now that we have the internet, it's just a matter of time before people consume their media digitally.
29:21 Speaker 03 But we didn't know how. So what I did, pulling out my bag of tricks from business school, is marched into meetings with Jeff with like, here's our projections for, you know, how big the ebook business will be over the next 10 years. And here's our projected market share. And here's what the pro forma P and L looks like. And here's the kind of deals we'll make with publishers. And here's the competitive landscape. And I was so proud of all this work and he looks up at me and says, Bill, where are the mockups? And I didn't have any mockups at that point. I was doing, you know, like, oh, here's the projection. They'll get started and we'll start like working on like launching a better ebook store. And by where the mockups, what he meant was, well, you know, this is all super interesting, or not really actually is what he was saying.
30:06 Speaker 03 But what's more interesting is like, what is going to be the customer experience? And more to the point, as we started to debate and discuss different ideas, whether it be in digital music or ebooks, the discussion was about, well, why would we bother building like a Me Too versus what, you know, Apple's already got the iPod and iTunes? So what's in it for the customer to have just another, a knockoff of that service? Like, what can we build that actually creates real value for customers? Something new we should invent on their behalf. And we tried mockups for a little while, but frankly, there were sort of like so many questions and so many details we hadn't thought out. And Jeff one day said, okay, I got a better idea. Why don't we, everyone in this room, write up their idea for what they think we should go
30:49 Speaker 03 build in digital. We'll write those things up and we'll come back in a few days and we'll read those and we'll go from there. And this is before we'd done narratives. We had not, you know, figured out this PR FAQ concept yet. But once we did that, everything changed. And suddenly we were reading, one document was describing like a puck that would sit on your countertop and you would talk to the puck and could order groceries from the puck. I had described a document about, you know, what we might go do in digital music. Another one was describing an early version of, of what Kindle might become. But some of these documents were like eight pages long. We needed to get this to be, you know, more pithy and clear. And Jeff said, I know, let's write the press release for each one of these ideas instead.
31:32 Sonal? Ooh, neat.
31:33 Speaker 03 And he said, you know, we should write the press release because normally that comes last. And he said, you know, normally the engineering group and the product group, they go and they come up with the idea for the product. And then at the very end, when it's time to sell it, they chuck it over the wall to the marketing team and say, okay, figure out how to go sell this thing. And he said, but what if by the time that thing got to the marketing team, they said, yeah, well, the thing you built, for that really to work, we actually need that to have a price point of $99, but you've built it in such a way that it's costing us $150 to manufacture each one. So yeah, we're not going to be able to sell too many. In other words, if you had known upfront that you needed to hit a, hit a bomb of less than $99 to make this product go, then you would have designed the whole thing very differently
32:17 Speaker 03 and understood the constraints. It might have a whole lot of, there might be vaporware concept, there might be concepts that you don't know how you're going to solve, maybe business model problems. But then in the FAQ, then that defines, okay, what are the hard problems we're going to have to go tackle to make this exciting product a reality. So we switched to that method and it was halting progress. And have we not really taken that approach? Like we would have not ended up with what turned out to be a breakthrough product, which was the Kindle.
32:46 Sonal? That's fantastic. So a couple of questions to just quickly probe on a few nuances. First of all, I know what you're really saying is, Flip the perspective from inward out to outward in, which I think is really interesting because that's something I constantly think about content, like oriented in the value to the reader. But what would you say on the flip side to the crowd that often says that part of the problem with, quote, "working backwards," well, then you're not really inventing what they don't know what they want. And how does one write a press release for the startups out there thinking, oh, well, you know, we're creating a new category. This is not something that exists. Tell me more about how you might address that crowd with this PR FAQ approach.
33:21 Speaker 03 I would submit that, in fact, that's what this process is actually designed for. In 2004, when we started on digital media, the way eBooks were, you could only read them on your PC. There were no offline readers and tablets and devices in those days. They were priced way too high, like the same price as the hardcover book. The eBooks had existed for four or five years before the Kindle launched in 2007, but it was a tiny, tiny business. And it was a tiny business because no one had imagined, well, what do I need to create? What's the new thing I need to build to make eBooks work? We defined what would be the ideal reading device, everything from it would be always connected to the internet, which, by the way, devices weren't that way back in 2007,
34:06 Speaker 03 that you wouldn't have to create some separate account or link your account to some mobile carrier, that when you got it out of the box, it already knew who you were. And so if you'd actually bought a bunch of eBooks online, they were magically already uploaded onto your device. All of those kinds of things would be described in the FAQ section to say, yes, here's hard problem one, and here's how we're going to solve this problem. Or we don't know how we're going to solve this problem yet, but here's our path for how we're going to go work on that.
34:36 Speaker 02 Yeah, I would just say there are two very real use cases where Amazon used the working backwards process to create something from scratch. With AWS, cloud computing didn't exist. And as we're working through the Kindle issues, you talk about context switching. An hour later, we'd go to another conference room and we'd be with Andy Jassy, who's the CEO of Web Services, and we'd be reviewing Word documents about what would eventually become cloud computing. And it took us about two years to come up with, what are we actually trying to create? And the first two were centered around storage and compute eventually. And where the press release, one area where it really helped
35:19 Speaker 02 crystallize everyone's thinking is, we came up with saying that we want people in a college dorm room to have the same access as an Amazon developer to world-class infrastructure.
35:31 Sonal? Wow.
35:32 Speaker 02 And that was just a powerful metaphor about, okay, so what are we creating? And what is this infrastructure that we really need? And starting from the customer experience, we had many, many small teams throughout the company, just screaming at Jeff, at the infrastructure team, "I've built my service, it's taken me too long to deploy it and get it out and ready for customers." And that's where it started off as provisioning, but it kind of morphed through this working backwards process to compute. And then in terms of storage, there's a whole bunch of different types of storage. It narrowed down to simple storage service was the very first thing that we would build out from that.
36:12 Sonal? I love that example because it really emphasizes this point that when you start with the PR FAQ, you're essentially starting with the differentiation, because you're really thinking in terms of the value, because there's a million options for people to pick from. So that's when you go from provision to compute, because you're thinking, if the customer is this kid in the dorm room having access to, and we often talk about the power, like actually Marc Andreessen in his original 2011 Why Software is Eating the World op-ed, points to the power of This movement like, you know, AWS has been huge in bringing, we even have this op ed about why every company is a fintech company. We actually call it the AWS moment in fintech.
36:54 Sonal? It's quite amazing, the impact that AWS has had on the industry and there's no question about that. But that precise point of starting with the PR FAQ to take what could have just been like, oh, here's some storage and here's how to provision what the services you need to here's how to create an entirely new business. That's a whole different game.
37:12 Speaker 03 The other thing that's really important to note where the PR FAQ process is misunderstood or in conflict with the startup community today, sort of a lean and agile approach.
37:23 Sonal? I want to hear about this. Love it. Have some fights, Bill.
37:26 Speaker 03 All right. All right. So here, let me tell you what the problem is with the lean and agile approach.
37:32 Sonal? I love Eric Ries for the record, but I, he's, he himself is a first, and he's actually said it on this podcast, that sometimes people get a little culty and follow the letters of the rule instead of the principles of it. I actually personally, I'm a big believer, having worked at Xerox PARC, in the maximum viable product sometimes, instead of the minimum viable product.
37:50 Speaker 03 Yeah, it's really, actually, it's the V part. The problem is, is that people focus on the M, the minimum, and they don't focus on the viable. So what is the definition of viable?
38:04 Sonal? Yeah. What is the definition? What would you say it is?
38:06 Speaker 03 To me, the definition is like, oh, if I go build this thing, I have created a, insert size of business here, 100 million, billion dollar business. I have enabled, if, if I'm right, then this opens the path for like something really big. And I see instead happening, okay, I've got a sprint, I've got a couple of weeks, what can I get done in a couple of weeks? Or, oh, what can I launch quickly to sort of test and learn? Right? Where then you've created completely different constraints. And oh, by the way, if your whole dev team thinks of their whole roadmap and it breaks into these little chunks
38:50 Speaker 03 of how do I, you know, iterate quickly, test and learn? Then you're tend, you're going to launch a lot of small things where the actual size of the viable business on the other side of it might be like sized in like the $1 million range or $2 million range or like the actual potential good outcome is very, very small. Now, there are plenty of places where this approach is totally applicable. Search, where you're like, how do I test and learn with like changes to the algorithm or changes to the logic of a new AI model? But if you're thinking about, I'm starting from scratch and trying to create a new business. The problem with these, this, the MVP approach where the viable part isn't really thought out and mapped out is that people haven't really thought through like, well, what could
39:35 Speaker 03 this really become and why might this not work? And in many cases, they could have actually, if they'd instead spent more time upfront in the planning process, thought much bigger about what does the customer really need? Or wow, I really created some significant value versus frankly, these little incremental changes don't really even move the needle at all.
39:57 Sonal? People don't do press releases for incremental releases. They do press releases for big advancement.
40:01 Speaker 03 That's, that's actually, that's actually an excellent point. If you, if you parachute into a new company and you look at their product roadmap and there's not one thing on there you'd write a press release about, then like you've got a problem.
40:12 Sonal? Yeah.
40:13 Speaker 02 To me viable means you read the press release of what you're trying to build and you want to buy or use the product. If it's not something that you want to buy or use, it's not viable.
40:24 Sonal? Yeah, I mean, I would also push back on the definition of viable because what I heard from Bill, and Bill, you should correct me if I'm wrong on this. Colin, when you say like that, obviously the customer is going to want to use it, but to me viable is not just that it's something a customer would use because I think there's a lot of dumb things customers would use, quite frankly. I heard it more as the enabling conditions to really make something bigger. And then also to address a deeper, more underlying opportunity sometimes instead of the surface opportunity, because not to get all jingo-ish on this, but I of course think of Clayton Christensen's jobs to be done framework. And it's sort of about like, what is the underlying job to be done that is being fulfilled for this person? So that's how I heard the viable.
41:08 Sonal? What does it take to make this happen? Whether minimum or maximum. And then also not only thinking about the product, but all the enabling conditions to get to addressing the deeper opportunity.
41:21 Speaker 02 Another way where I've seen that the MVP process being misused, because it can be useful, is that the process itself becomes the goal.
41:31 Sonal? Yes.
41:32 Speaker 02 Because I'm supposed to launch every two weeks, or I have an MVP. So this MVP card is go to the front of the line and get whatever resources I want because I'm doing an MVP. So don't let the process itself become the end goal. And then don't let the MVP get in the way of understanding your customers. Because, you know, some people actually forget the customer problems that they're trying to solve.
41:58 Sonal? Which is the whole point of doing an MVP in the first place. I mean, the whole point is to be able to get that feedback so quickly. Because the whole reason that that idea came about was that you don't want to have that very long delay in the feedback loop.
42:10 Speaker 02 Yes, and if you've watered down the feature set so much just to conform with what the process is, it's a shallow, pathetic version of what you're actually trying to test. And so you say nothing here when you never really gave it your best shot.
42:25 Sonal? What's really interesting is you actually, in your book, outline the total addressable market or TAM. And I found that to be very interesting, especially in connection to the discussion about how to think about the biggest possible market for this product working backwards.
42:40 Speaker 03 Yeah, we spilled a fair amount of ink on the TAM part in the book because people with less experience sort of get this part wrong. To not only think about how many people have this problem, but like, how big is the need? And for how many consumers is this problem really big enough that they're willing to spend money to do something about it? How much would they be willing to spend? And you know, how many of these consumers actually have the characteristics or capabilities to actually make use of this product? And a lot of people don't really step through that clearly.
43:14 Speaker 02 The thing is that you want to ask all of the hard questions upfront. And as we talked about, this is an iterative process. So in the review meetings, you know, if there are a couple of questions that you you don't know the answer to, you just append those to the document and say, great, let's come back in two weeks, however long it's going to take. The FAQ, you can basically break it up into two different components. One is an external FAQ that you're explaining, how does this product work? How much does it cost? Why should I use this service versus what's out there on the market? Or why do I need to change my behavior? And then the internal FAQs, what are the things that we need to go organize and solve in order to make this product or feature a reality?
43:59 Speaker 02 And then, like you touched on, how big is this opportunity? You know, what is the total addressable market? Then you can size up the opportunity and that'll tell you whether it's worth doing or how much to invest in it. Because one of the things that you ask when you go through the working backwards process is, is this big enough to be worth doing? So it may be a good idea, but it just may not have the impact and scope on your customers or the organization to make a difference, to be worth devoting resources to.
44:30 Speaker 03 When we were figuring out in digital media and AWS, what are we going to go build? And you parachuted into either one of those teams and said, heck, hey, guys, how's it going? And we said, oh my God, we're so frustrated because we just want to go and build this thing and get it out there. But Jeff, you know, is insisting that we, you know, go through this PR FAQ process and figure this all out in advance. And I was among the people who found this frustrating. And it was only in hindsight that I realized like how smart Jeff was to slow us down. And we co-opted this Marine Scout Sniper Sting, which is that slow is smooth and smooth is fast. Or measure twice, cut once. Or sometimes Jeff would refer to himself as the chief slowdown officer
45:15 Speaker 03 when teams were sort of itchy to go pull the trigger and build and launch something. What I came to appreciate in retrospect is that to build, to actually create value. You really have to take the time and think big. That's what the PR FAQ process does. And if everyone can go write PR FAQs and you've got 30 or 40 different ones to review, then I'm here to tell you that the best ideas are going to bubble to the top pretty clearly based on this process. Whereas the MVP lean process really is just about cranking stuff out rather than first filtering, thinking through, refining what to do.
45:56 Sonal? What to do.
45:57 Speaker 03 People confuse speed and activity with effectiveness.
46:03 Sonal? Yeah, exactly. What I find so fascinating about that, by the way, is just coming back to where we started, is how the 14 leadership principles balance each other. Because you described Jeff in this context, and a lot of these processes as ways to slow things down upfront. But then you also have principle number 10, or whatever number it was, for bias for action at the same time. You think of this as a whole system. And it's really interesting because it resonates to me with Ben Horowitz's book on culture, because he describes like the value system of the samurai warriors, where they would have something that was like Bushido, where there'd be something that was incredibly kind and generous, and then something that was incredibly vengeful in the same like framework. It's very interesting how those motions are a kind of opposite, but yet in balance.
46:48 Speaker 02 Yeah, they do work together. We started off the conversation about the "I write a lot" principle. Well, the one right below that is learn and be curious. And the one right above it on the list is invent and simplify. And you need to do both of those in order to be right a lot. The one thing I would add, a lot of people say, well, Amazon, they've either have so much money or so much time, they can afford to do all these things. Long-term thinking doesn't necessarily mean it takes longer to get to your end goal. You know, Amazon built $100 billion business faster than any company. AWS got to $10 billion in revenue from zero faster than Amazon, the retail business, did.
47:32 Speaker 02 So sometimes to slow down, to move fast, even with small organizations, you're more than likely will get to where you want to be quicker. If you take some of these steps, typically what you're doing is you're doing off path, distracting activities that by the way are taking away from your bottleneck resources, which are typically software engineering resources at a lot of organizations.
47:56 Sonal? Yes, exactly.
47:57 Speaker 02 That are meant to build up long term value.
47:59 Speaker 03 Yeah. And just to pick the AWS thing is so remarkable. Think about that for a minute because we just told you, I mean, what was it called 18 months, 24 months? How many months from the from go before the team even wrote the first line of code?
48:11 Speaker 02 I mean, it was at least 18 months and I did have software engineers after some of the meetings come to me and say, Hey, can you remind Jeff that our job is to write software code, not not documents? And they were itching to go. It took a while to figure out what we should build. And that time was very well spent writing Word documents versus writing C code.
48:36 Speaker 03 And not only that, it's empirical fact that it was well spent because the company set the record for the fastest company to a revenue milestone by spending the first 18 to 24 months planning.
48:48 Speaker 02 And you talk about distractions. We did not know at that time what other people were doing. You know, web services were no secret. There were other companies who, in by their own right, should have gotten there first. We didn't know if someone would come out with a set of developer APIs at that point in time.
49:06 Sonal? I know. That scares me thinking about that, actually, like almost two years like planning, like that's.
49:14 Speaker 03 Think how scared they were.
49:15 Speaker 02 But Jeff had the fortitude to say, it's not ready yet. This is not what we want to build.
49:21 Speaker 03 It's not viable.
49:22 Speaker 02 You know, talk about what makes Amazon special. You can read these principles. Sticking to them is sometimes quite challenging, either when things are going really, really well. Or when they're not going well, or when there's uncertainty. These are not just posters on the wall. They're woven into the DNA of everyone who's been in Amazon for any length of period of time.
49:43 Sonal? I'm just struck at all the parallels and all the things you guys are saying because essentially every business today is a creative business. What really strikes me is I'm not going to make a comparison between podcasts and AWS, but I will say that I talk to a lot of podcasters for how to make their podcast stand out, differentiate, like how to do editorial strategy comes up a lot. And one of the things I constantly say is if you can't be first or leading, then you have to be very differentiated. It's really interesting when you talk about the bottleneck resources. I think of things in terms of opportunity cost and return on energy, or what I call ROE. And similarly, you have to pick which things you're going to do for the greatest possible hits, or you'll never punch above your weight or be heard above the noise, which I think is so fascinating.
50:26 Sonal? We had Jeff Lawson from Twilio on the podcast recently and he's like, you know, we need to give them problems, not just like specs and things to work on. It's when you describe that they're like, uh, we're spending, you know, 18 months writing planning documents that is treating software developers as creative.
50:42 Speaker 02 But it also creates alignment for the teams then who will go out and build. Cause sometimes it requires more than one team. If they're not aligned on what the problem is, they're going to solve different problems and those components aren't going to fit.
50:57 Sonal? Right. I want to switch into talking about some specificities, some advice for startups.
51:01 Speaker 02 One tool you can use for startups, and I've actually done this at other companies. If you're trying to figure out what to build, you can write competing press releases with different takes.
51:11 Sonal? Oh, I love that.
51:12 Speaker 03 Right.
51:13 Speaker 02 The problem. And then it becomes pretty apparent when you've got two or three or four different approaches that we really need solution A, or, or I'm going to take the first part of this solution and combine it with a great idea that came up in the second one. And this is actually what we want to build. So it's a lightweight way to crystallize your thinking and also get alignment.
51:36 Speaker 03 Yes. Think about how inexpensive it is to write a one-page press release versus how expensive it is to build mockups. To Colin's point, when you read them all as a group, like the best ones are going to be clear.
51:48 Sonal? You know, again, this is where I just can't get over how creative the book is in terms of its application to all kinds of creative fields, companies, big and small. Because to me, both the memo strategy, the PR FAQ, and then this idea that you both shared of being able to write competing press release and then harness kind of the wisdom of the group. It's actually about the power of narrative for really helping instantiate things that you know when you know. I think a lot about how tools change our thinking and vice versa. And you guys are essentially describing these practices for how that plays out in organizations, especially as they scale. On this note, you have a section in your book, the subhead is better coordination was the wrong answer, because that's one of the common myths that people have as a scale is we need
52:33 Sonal? to coordinate better. And in fact, it creates layers and layers of crap to deal with. People create entirely new roles, like dedicated chiefs of staff, just to like, you know, create stitching and seeming between teams. And it's just the most ridiculous thing I've ever seen and heard. And I just want to hear more from you guys, especially because a lot of listeners, and we're talking about what happens when you scale and grow very quickly, you guys really did see this phase at Amazon.
52:57 Speaker 02 Yeah, this is a case where Amazon faced the same question that a lot of growing organizations do. We're adding more people. It's just, it seems like it's taking longer to get things done, but came up with a different answer. Some companies would say, let's build coordination tools, let's collaborate better. And Jeff said, I'd love to eliminate coordination altogether. Now, in practice, you can't eliminate it completely. So you break up into loosely coupled teams. And this was a hard, hard problem to solve because it required to change the way we built Amazon technology wise, decouple it into what's now services based architecture.
53:39 Speaker 02 That was hard to do back then in, you know, 2000, 2001, especially as you're growing super fast. But then there's also the organizational component too, about how do decisions get made? It was a multi-year effort, to be quite honest, but if you're going to grow 10x. And 100X, we're not going to spend any time building. We're going to spend all of our time coordinating. So nip it in the bud. And Jeff wanted Amazon to be a place where builders can build.
54:08 Speaker 03 So the ironic thing is that we started off with the process that was the conventionally, except the traditional wisdom was brought in what we called NPI, New Project Initiatives. It was horrible. I mean, basically, it was another example of the process becoming a thing where you had to come up with like, what's your new project initiatives? You had to write it all up. You had to project what are the financials behind it, most of which were totally wrong and guesses, like almost all pro forma P&Ls are, and then put it in front of the big committee and try to take it upstairs. Not only was this process a massive waste of time, but then you'd have these frustrating business reviews with a team saying, yeah, we really need to go build X, Y, and Z. And Jeff and his team saying, yeah, I agree. Go build X, Y, and Z.
54:53 Speaker 03 But they say, well, I can't because I need Brows to do this and I need the team that works on the checkout, the order pipeline, and they already have like these four other projects they're working on. So I'm just sitting here in line and I can't go build it. And so you've de-empowered your teams. The senior management, they become like referees of between teams, who's going to go do what? And frankly, it's not much fun. So this was a huge breakthrough for the company was breaking down, not only of course breaking down the code into APIs, but then breaking down the teams into single-threaded focus teams.
55:32 Speaker 02 There's some roles that don't actually fit too well in this type of paradigm. So for instance, like a chief product officer doesn't really fit in this role because if you ostensibly are responsible for making every product decision in the company, from what's going on in the warehouse to what should the, how should the apps be built, to how can we decrease delivery time, there's no one person who can be obsessed with all of those details. Right. And so that role typically doesn't fit as you separate into these small, separable, single-threaded teams. The fallacy is as your company grows, the chief product officer isn't really doing that anyway because they can't get that much high-quality information to make all of those
56:17 Speaker 02 important decisions. You do want that the teams closest to the customers making those types of decisions anyway.
56:24 Sonal? I call that bare metal decision making, like who's the closest to the metal of the thing? And that's what I think is super valuable about what you just said. And you're essentially describing these small units as like every team is its own mini
56:36 Speaker 03 That's right.
56:36 Sonal? GM of every mini unit is the leader. And then every product, you're like so close to the core in that decision making framework.
56:43 Speaker 03 That's right. The idea is for each one to be like a self-contained unit. And in search, that's all engineers. But in some other business, like my digital video business, it was like a combination of engineering and marketing people and people working in the studio. So, but you have all the resources you need. You don't have these dependencies that basically slow you down.
57:06 Speaker 02 During this timeframe where we were making the transition, we were using narratives. And one of the questions that we actually required was for the teams to put in what things that are not under your control that you wish you had under your control? And how are you going to organize and create AI so that can happen? Again, this is work that's below the tip of the iceberg of where Amazon really put a lot of effort into how can you still grow and be as nimble and agile as we were when we started out? And it's not easy, but you know, it only gets harder. So you may as well start now.
57:44 Speaker 03 Yeah. And don't take away from this that Amazon was some Nirvana world where you never had to worry about coordination with other teams. It was just that we worked so hard to minimize the degree to which we did.
57:55 Sonal? I'm very fascinated by how organizations evolve in general to be effective. And when you think of any large company, it becomes a complex system. And you're essentially describing how modular self-contained units can thrive in these complex systems. It's a lot like evolution.
58:10 Speaker 03 And these pieces all fit together because then we have to loop back to like, oh, the reason that Amazon could do that is because those teams wrote narratives in PR FAQ. So they made it abundantly clear. If Jeff wanted to see what is this team doing? Oh, here you go. Read this document and in two hours, you knew exactly what they were doing.
58:27 Sonal? Right. He makes him the chief ecosystem officer, essentially not just the chief slowdown officer. Okay, so Colin, so a question I have for you, it's really unique that you were able to shadow Jeff Bezos and be his shadow. And, you know, I don't want to make this about the glorification of Jeff Bezos. I'm so not interested in that because I think there's just plenty of narratives out there. What I am interested in, however, is this question of what it takes for a CEO and a leader like that to evolve and what you saw in shadowing him on that front and then also the act of shadowing and that itself as a mechanism for learning mentorship, apprenticeship, if you will. I'm very fascinated by this this whole thing.
59:05 Speaker 02 Sure. So, I mean, the my role as Jeff's shadow was primarily two, two parts. One was just to make him more effective CEO on a daily basis, making sure that the right issues are surfaced, that the people coming into the meetings, we cover the right topics and have enough information to make the right decisions on afterwards that it gets followed up on. So you're kind of bookending the day. But then the second and more important part, the longer term part was it was a training role. And the way Jeff put it is, I want us to be able to model each other and, you know, know how we would think in different situations. One of the enlightening things that I realized during my time with Jeff is what he chose
59:48 Speaker 02 to work on during the two years I was his shadow or technical advisor. And it wasn't the biggest businesses at Amazon. About half of the time were spent on what would become AWS and digital. And those businesses had revenue of effectively zero for the, you know, those two years. And he told me more than once, you want your top leaders and your most impactful people working on your biggest opportunities. And that may be different from what your biggest current set of activities are. How Jeff changed during that time and just to become a better CEO.
1:00:29 Speaker 02 One thing he said is he learned how to become a better operator, becoming more operationally efficient. Fortunately, that is a teachable and a learnable skill. And Jeff had some great people at Amazon, like Jeff Wilkie, who's a great operator. He's the CEO of the consumer business. And now in his own right, he is a great operator and insists on the highest standards is one of Amazon's leadership principles. He holds people accountable, himself included, by the way. And I would say that I also learned that sticking to these core principles is harder than it sounds, but the time when you need them most is the times when it's easiest to ignore them.
1:01:11 Speaker 02 So for instance, Amazon Prime, he made the call that, hey, we're going to go launch this shipping project in the holiday season. And it was not very popular at the time, but when he explained his thinking that customers were basically giving us a B minus on our three to five day shipping, even though we had just gotten reasonably competent and spent a couple hundred million dollars doing that, Jeff looked at it long term and said, well, we're becoming a smaller and smaller share of the overall e-commerce industry, so we've got to make the change now. And so it wasn't that Jeff had this insight that comes once in a generation for Amazon Prime.
1:01:55 Speaker 02 He just stuck with the leadership principles and took them to their logical conclusion when it was tough to do in the face of the holiday season of what our quarterly results were.
1:02:04 Sonal? By the way, for the listeners, because we don't obviously have time to go into the whole book, but you know, half of the book, the first half is about the principles and these practices and mechanisms. But the other half is actually showing through these very detailed case studies and examples that you both participated in or witnessed or oversaw firsthand in this invention machine at work. And that includes the Kindle story, the AWS story, Prime Video, and what you just mentioned, Colin, which is Prime. And what's really interesting in that Prime section is that not only that Jeff had the wherewithal to push through. But what's really interesting in the prime program story is that it's all the iterations involved to actually get it to what it is today because there was like a 1.0 and then, you know, the loyalty program it later became. So I think that's a really
1:02:47 Sonal? great part of the book for those that want to learn more. And Bill, anything to add there on what you saw in the evolution?
1:02:52 Speaker 03 I do. In fact, Jeff, I remember Jeff, at least more than once, talking about the way a leader needs to evolve as the company grows. And I think about this frequently, which is that he said, at the beginning, the leader needs to really focus on what? Then they really need to focus on how? And then eventually their focus really just becomes who?
1:03:16 Sonal? Wow.
1:03:17 Speaker 03 What is, you know, what is our business? What's our product? What are we building? What are the details of that? Right? How is what processes? How do we do the work? What is the filter, the lens through which we make decisions? And then who, of course, is who are my leaders? Who have I? How have I making sure that I assemble the right team? And in doing so, how do I delegate responsibility to those people so that they can carry out those details? That is a classic and challenging transition for any entrepreneur owner who starts off being in control of every detail and that they have to slowly let go of those details. And then they have to figure out how they put in place the right mechanisms
1:03:59 Speaker 03 to be able to properly audit the work of the teams. And that's really what, you know, that's what we tried to describe in the book is actually this management science, frankly, that Jeff and the team developed to really solve this problem.
1:04:10 Sonal? Working Backwards: Insights, Stories, and Secrets from Inside Amazon by Colin Breyer and Bill Carr. Thank you so much, you guys, for joining the A6 and Z podcast.
1:04:20 Speaker 03 Thank you. Thanks, Tony.
Previous When Gross Margins Matter Next Stories of Startup Survival Mode Page updated October 26, 2026 · transcript and summary are machine-generated
