Amazon Narratives: Memos, Working Backwards from Release, More

with @billcarr89 @cbryar @smc90 When you hear stories about Amazon's famous "invention machine", we often hear about things like: Memos, six pages exactly and no powerpoints at al! Or, the idea of "work backwards from the press release". But what's lost is the how, as well as the broader narrative of how all companies and leaders, not just Amazon and Bezos, can define their ways as they scale. After all, Amazon was once a small startup, too. So in this episode -- the very first podcast for the new book Working Backwards: Insights, Stories, and Secrets from Inside Amazon -- the authors share firsthand observations and experiences from being in "the room" where it happens, from AWS, Kindle, and Prime to more importantly, the leadership principles, decision making practices, and operational processes that got Amazon there. Can other startups do the same?

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Sonal?

  Hi, everyone. Welcome to the A6 and Z 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 the Technical Vice President, and then notably was one

• 0:41Sonal?

  of Jeff Bezos's earliest shadows, a legendary program there. Fun fact, the first shadow before that, I believe, was Andy Jesse, 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 a6andz.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?

• 1:22Sonal?

  We actually spend most of the episode digging in detail into two operational practices, 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

• 2:06Sonal?

  principles. And actually, the first question I want to start with, especially since I hate the "why'd you write this book?" question, Colin, Bill, honestly, there's a tendency for folks telling these stories, these kind of narratives, to do a sort of hindsight as 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?

• 2:41Speaker 01

  Well, one thing is that the businesses you you mentioned, they are substantially different. They require different expertise. There are different customer sets. AWS is B2B. There's streaming video. There's the 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.

• 3:20Speaker 02

  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 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,

• 4:05Speaker 02

  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. And so to me, what's most remarkable and 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.

• 4:37Sonal?

  Is 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, to set 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.

• 5:21Sonal?

  And you basically write that leaders are right a lot, 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.

• 5:37Speaker 02

  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, 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 that's presented with a spreadsheet, a document, PowerPoint, there's all kinds of data that we presented to you with those decisions.

• 6:20Speaker 02

  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.

• 6:56Speaker 02

  And what great leaders do actually is they can stake out a position, but they're willing to update, I mean, 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, it 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, what are you, 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.

• 7:39Speaker 02

  And so it's thinking about it and framing it that way, about bringing forward the right data and the right information. And then it's also the job of leader to solicit that to make the best decision.

• 7:49Sonal?

  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. So what is your best advice about how leaders and people in the group can share that information?

• 8:34Speaker 01

  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 were big fans of Edward Tufti, who's professor emeritus at Yale.

• 9:17Speaker 01

  He came to Amazon to speak a couple of times. 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.

• 10:01Speaker 01

  People read faster than people talk. 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.

• 10:20Sonal?

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

• 10:56Speaker 01

  So a common misconception is, well, now it's just the best writers instead of the best presenters that kind of 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.

• 11:15Speaker 02

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

• 11:50Sonal?

  Yeah.

• 11:50Speaker 02

  I know, 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.

• 12:35Speaker 02

  And they're able to give. Super granular, specific feedback to those teams.

• 12:41Speaker 01

  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.

• 13:14Sonal?

  Yep.

• 13:14Speaker 01

  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.

• 13:31Speaker 02

  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.

• 14:16Speaker 02

  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.

• 14:41Sonal?

  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:00Speaker 01

  Yeah, so Amazon meetings with narratives, they are strange to the uninitiated. It'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 right 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.

• 15:42Speaker 01

  The six-page narrative is a forcing function to where you can cover that amount of information in a one-hour meeting.

• 15:48Sonal?

  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?

• 16:13Speaker 02

  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, you know, 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?

• 16:55Speaker 02

  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.

• 17:32Speaker 01

  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, with 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.

• 17:56Sonal?

  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.

• 18:08Speaker 01

  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.

• 18:37Speaker 02

  It would include tables with like, here's a summary of our financial results from the prior year. Here's a table of the summary of our plan for the next year.

• 18:45Speaker 01

  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, well, we 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,

• 19:29Speaker 01

  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? And 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 just to say, these are the correct set. That's a good caching mechanism because if you're a manager at a company that uses narratives,

• 20:12Speaker 01

  you're going to be context switching and reviewing multiple ones every day. And sometimes you may only meet with the team once a quarter and you want to be able to very quickly get up to speed.

• 20:21Speaker 02

  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, or you have this important dependency. What gives you confidence that you're going to 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

• 21:03Speaker 02

  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.

• 21:47Speaker 02

  All those things can still be in there, but then the narrative needs to clearly state with a clear beginning, a middle, and end. Here's what we're proposing to do, or not proposing to do, and why.

• 21:55Sonal?

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

• 22:37Sonal?

  rest all the common things that you can literally get out of the way in like a memo in 20 minutes.

• 22:42Speaker 02

  Yeah, I mean, in a good document, that all comes out.

• 22:44Sonal?

  I want to actually go back to the tenets 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 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

• 23:25Sonal?

  take on all the logical steps that derive from that position. And sometimes 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.

• 23:40Speaker 02

  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?

• 23:51Sonal?

  Yes.

• 23:52Speaker 02

  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 of 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 on a piece of paper, not only the tenant, but then like here's, 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 a lot of those things get relitigated.

• 24:36Speaker 02

  So it was one of the ways which Amazon was very effective, which people don't realize as a management company.

• 24:42Sonal?

  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?

• 24:50Speaker 02

  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, they too would trip across, well, why don't we do blank? Or why are we doing? 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.

• 25:12Sonal?

  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.

• 25:52Speaker 01

  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?

• 26:26Speaker 02

  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.

• 26:34Sonal?

  Was it strengths, weaknesses, opportunities, threats?

• 26:36Speaker 02

  Right. But there's no C, there was no customer.

• 26:40Sonal?

  Right.

• 26:40Speaker 01

  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.

• 27:23Speaker 01

  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.

• 27:40Speaker 02

  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.

• 28:07Speaker 02

  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.

• 28:17Sonal?

  Napster.

• 28:18Speaker 02

  Right. 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. 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 all get started and we'll start like working on like launching a better ebook store.

• 29:02Speaker 02

  And by where are the mockups? What he meant was, well, you know, this is all super interesting, or not really, actually, is what he was saying. 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 that we hadn't thought out.

• 29:45Speaker 02

  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 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, I think, Q 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 described a document about what we might go do in digital music. Another one was describing an early version of what Kindle might become. But some of these documents were like eight pages long. We needed to get this to be more

• 30:29Speaker 02

  pithy and clear. And Jeff said, I know, let's write the press release for each one of these ideas instead.

• 30:36Sonal?

  Ooh, neat.

• 30:37Speaker 02

  And he said, we should write the press release because normally that comes last. And he said, 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 bomb of less than $99 to make this product go, then you would have designed the whole thing very differently

• 31:21Speaker 02

  and understood the constraints. It might have a whole lot of, there might be vaporware concepts, 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.

• 31:49Sonal?

  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.

• 32:25Speaker 02

  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,

• 33:10Speaker 02

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

• 33:40Speaker 01

  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 were working through the Kindle issues, you talk about contact 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 crystallize everyone's thinking

• 34:25Speaker 01

  is we came up with the saying that we want people in a college dorm room to have the same access as an Amazon developer to world-class infrastructure. 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 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.

• 35:10Speaker 01

  It narrowed down to simple storage service was the very first thing. And then we would build out from that.

• 35:16Sonal?

  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, you know, 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. It's quite amazing, the impact that AWS has had on the industry.

• 36:01Sonal?

  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 the services you need to here is how to create an entirely new business. That's a whole different game.

• 36:15Speaker 02

  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.

• 36:26Sonal?

  I want to hear about this. Love it. Have some fights, Bill.

• 36:30Speaker 02

  All right. All right. So here, let me tell you what the problem is with the lean and agile approach.

• 36:36Sonal?

  I love Eric Reese for the record, but 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 am a big believer, having worked at Xerox PARC, in the maximum viable product sometimes, instead of the minimum viable product.

• 36:54Speaker 02

  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?

• 37:08Sonal?

  Yeah, what is the definition? What would you say it is?

• 37:10Speaker 02

  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 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 break it into these little chunks of how do I,

• 37:54Speaker 02

  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.

• 38:19Speaker 02

  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, I'm trying to create a new business. The problem with 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 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've really created some significant value versus frankly, these little incremental changes don't really even move the needle at all.

• 39:01Sonal?

  People don't do press releases for incremental releases. They do press releases for big advancements.

• 39:05Speaker 02

  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.

• 39:16Speaker 01

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

• 39:28Sonal?

  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.

• 40:12Sonal?

  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.

• 40:25Speaker 01

  Another way where I've seen the MVP process being Misused because it can be useful is that the process itself becomes the goal.

• 40:35Sonal?

  Yes.

• 40:35Speaker 01

  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:02Sonal?

  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.

• 41:13Speaker 01

  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.

• 41:29Sonal?

  What's really interesting is you actually, in your book, outlined 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.

• 41:44Speaker 02

  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.

• 42:18Speaker 01

  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. And 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:03Speaker 01

  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.

• 43:34Speaker 02

  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, 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 is insisting that we go through this PR FAQ process and figure this all out in advance. 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.

• 44:19Speaker 02

  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:00Sonal?

  What to do.

• 45:01Speaker 02

  People confuse. Speed and activity with effectiveness.

• 45:07Sonal?

  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 kind of opposite, but yet in balance.

• 45:52Speaker 01

  Yeah, they do work together. We started off the conversation about the "are right 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. So sometimes to

• 46:37Speaker 01

  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:00Sonal?

  Yes, exactly.

• 47:00Speaker 01

  That are meant to build up long-term value.

• 47:03Speaker 02

  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?

• 47:15Speaker 01

  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.

• 47:39Speaker 02

  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.

• 47:51Speaker 01

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

• 48:10Sonal?

  I know. That scares me thinking about that, actually. Like almost two years, like planning, like that's scary.

• 48:17Speaker 02

  Think how scared they were.

• 48:19Speaker 01

  But Jeff had the fortitude to say, it's not ready yet. This is not what we want to build.

• 48:24Speaker 02

  It's not viable.

• 48:26Speaker 01

  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 at Amazon for any length of period of time.

• 48:46Sonal?

  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,

• 49:28Sonal?

  which I think is so fascinating. 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.

• 49:46Speaker 01

  But it also creates alignment for the teams that who will go out and build, because sometimes it requires more than one team. If they're not aligned on what the problem is, they're gonna solve different problems and those components aren't gonna fit.

• 50:00Sonal?

  Right. I want to switch into talking about some specificities, some advice for startups.

• 50:05Speaker 01

  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

• 50:14Sonal?

  Oh, I love that.

• 50:16Speaker 01

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

• 50:40Speaker 02

  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 gonna be clear.

• 50:51Sonal?

  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 they

• 51:35Sonal?

  scale is we need 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 seaming 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:01Speaker 01

  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.

• 52:43Speaker 01

  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 going to, we're not going to spend any time building. We're going to spend all of our time coordinating. So, you know, nip it in the bud. And Jeff wanted Amazon to be a place where builders can build.

• 53:12Speaker 02

  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, it was horrible. I mean, basically, it was another example of the process becoming a thing where, where you had to come up with like, what's your new project initiative? 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 PNLs are. And then put it in front of a 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. You know, go build X, Y, and Z.

• 53:56Speaker 02

  But they say, well, I can't because I need Browse 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, you know, not only of course, breaking down the code into APIs, but then breaking down the teams into single-threaded focus teams.

• 54:36Speaker 01

  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 essentially 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, you know, decrease delivery time? There's no one person who can be obsessed with all of those details.

• 55:03Sonal?

  Right.

• 55:03Speaker 01

  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 important decisions. You do want that the teams closest to the customers making those types of decisions anyway.

• 55:27Sonal?

  Yep. 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,

• 55:40Speaker 02

  That's right.

• 55:40Sonal?

  GM of every mini unit is a leader. And then every product, you're like so close to the core in that decision-making framework.

• 55:46Speaker 02

  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 of the resources you need. You don't have these dependencies that basically slow you down.

• 56:10Speaker 01

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

• 56:48Speaker 02

  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.

• 56:59Sonal?

  Yeah, 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.

• 57:14Speaker 02

  And these pieces all fit together because then we have to look back to like, oh, the reason that Amazon could do that is because those teams wrote narratives and PR FAQ. So they made it abundantly clear. If Jeff wanted to see what is this team doing? Oh, here you go. You read this document and in two hours you knew exactly what they were doing.

• 57:30Sonal?

  Right, he makes him the chief ecosystem officer, essentially, not just a 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.

• 58:09Speaker 01

  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, how we would think in different situations. One of the enlightening things that I realized during my time with Jeff is what he chose to work on

• 58:53Speaker 01

  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. One thing he said is he learned how to become a better operator, becoming more operationally

• 59:38Speaker 01

  efficient. Fortunately, that is a teachable and a learnable skill. And Jeff had some great people at Amazon, like Jeff Wilkie, you know, 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 you know, insist on high, 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 are, is the times when it's easiest to ignore them. So for instance, Amazon Prime, he made the call that, hey, we're going to go launch this shipping project in the holiday season.

• 1:00:23Speaker 01

  And it was not very popular at the time, but when he explained his thinking that, you know, 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, you know, 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. 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:01:09Sonal?

  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. Cause there was like a 1.0 and then, you know, the loyalty program it later became. So I think that's a really great part of the book for those that want to learn more. And Bill, anything to add

• 1:01:54Sonal?

  there on what you saw in the evolution?

• 1:01:56Speaker 02

  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:02:20Sonal?

  Wow.

• 1:02:21Speaker 02

  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, 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, 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 to be able to properly audit the work of the

• 1:03:05Speaker 02

  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:03:14Sonal?

  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:03:24Speaker 02

  Thank you. Thanks, Sonal.

• 1:03:25Sonal?

  Bill and Colin, this has been so much fun. I just want to say thank you so much for taking the time.

• 1:03:29Speaker 02

  Kudos to you, because what was really noticeable, Sonal, compared to our other podcasts is the