Amazon Narratives — Memos, Working Backwards From Release, More

When you hear stories about Amazon’s “invention machine” — which led to a company with not just one or two products but several successful diverse lines of business — we often hear about things like: Memos, six pages exactly and no powerpoints at all!; or, the idea of just “work backwards from the press release”; and other such “best practices”… But what’s often lost in hearing about these is the context and the details behind them — the what, the how (as well as their origin stories) — not to mention how they all fit together. Knowing this can give us insight into  how all companies and leaders, not just Amazon and Bezos, can define their cultures and ways especially as they scale. After all, Amazon was once a small startup, too.

So in this a16z Podcast with Sonal Chokshi — the very first podcast for the new book Working Backwards: Insights, Stories, and Secrets from Inside Amazon (out February 9) — authors Colin Bryar and Bill Carr share not only how Amazon did it, but how other companies can do it, too, drawing on their combined 27 years of firsthand observations and experiences from being in “the room” where it happens. Bill was vice president of digital media, founded and led Amazon Music, Amazon Video, Amazon Studios; and Colin started out in the software group, was a technical vice president, and then, notably, was one of Jeff Bezos’ earliest shadows — the shadow before him was in fact Andy Jassy, president and CEO of Amazon Web Services (soon to be CEO of Amazon).

The two share not only the early inside stories behind (ultimately) big business moves like AWS, Kindle, Prime — but more importantly, the leadership principles, decision making practices, AND operational processes that got them there. Because “working backwards” is much, much more than being obsessed with your customers, or having company values like “are right a lot”, “insist on the highest standards”, “think big”, “bias for action”, and more. The discussion also touches on hot-topic debates like to lean-MVP-or-not-to-be; the internal API economy; do you even need a chief product officer; and if you need less, not more, coordination as you grow. Can startups really be like Amazon? Yes: and it comes down to how leaders, organizations, and people at all levels decide, build, invent… using the power of narratives and more.

Show Notes

• The early days of Amazon and the development of the company’s 14 principles [3:18], including one that says leaders should be “right a lot” [6:53]
• Amazon’s use of written narratives over PowerPoints [9:05], and how meetings are conducted using narratives [15:55]
• The tenets that guide Amazon’s decision-making [24:00]
• Working backwards from a press release [26:28], using AWS as a case study [34:56]
• Discussion of lean startup principles [37:31], and how Amazon’s core principles balance each other [46:21]
• Advice for startups, including reducing coordination and centralization [51:16]
• Lessons learned from shadowing Jeff Bezos [58:50]

Transcript

Sonal: Hi, everyone. Welcome to the a16z 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 the new book, coming out this week, is titled “Working Backwards: Insights, Stories, and Secrets from Inside Amazon.”

In it, authors Colin Bryar 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’ earliest shadows, a legendary program there. Fun fact: the first shadow before that, I believe, was Andy Jassy, 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 a16z.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 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 tradeoffs of lean and minimum vs. 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.

Amazon’s early days

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” question) — Colin, Bill, honestly, there’s a tendency for folks telling these stories, these kind of narratives, to do a sort of hindsight is 20/20, 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 notable, too, is that Amazon had not just one or two or three product lines, but literally entirely different yet successful lines of business under one roof. So, what drives that? And can startups really relate to the Amazon story then?

Colin: Well, one thing is that the businesses you mentioned, they are substantially different. They require different expertise, they’re 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 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.

Bill: I would first start by going back in time a little bit, and place you sort of where Jeff Bezos was and 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 you can be hands-on. But guess what? That completely breaks once you start to grow like a weed, and you found product-market fit, and suddenly you’ve looked 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.

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, 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 I will take, like, all day, and it’s the 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 #4, “are right a lot.” 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, dammit, a leader should be right all the time. Their instinct should be damn good.” Tell me more about that one, because that one made me chuckle a bit.

Bill: 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. 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 will be presented to you with those decisions, 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 — but they are willing to update (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 it 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 to you out of it. 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.” 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 a leader to solicit that to make the best decision.

Narratives over PowerPoints

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’ve 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.” 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?

Colin: 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 2-3 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 were 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 [technical advisor] at the time. We had been looking at other ways to conduct meetings, and we were big fans of Edward Tufte, who’s professor emeritus at Yale, 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 memo. One thing that is a little bit misunderstood is these ideas don’t come out fully formed. They started out 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, 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.

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 skill. 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, you know, how dogs piss around their territory. There’s also a real-time component, where people are performing in real time, like, leaving comments in the middle of the meeting.

Colin: So, a common misconception is, well, now it’s just the best writers instead of the best presenters that’s gonna win out in narratives. We haven’t found that to be the case. It’s really the best thinkers [who] write the best narratives. And some of the best narratives I’ve ever read are by people whose first language is not English.

Bill: 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, 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. And oh, by the way, if you spend 10 hours a day reading detailed narratives, I’ve got to tell you, it can be mentally exhausting.

But when people muse, like, how does Amazon do it? Like, how is 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 <Sonal: love this> their executives are, like, 7-8 times better informed about what’s happening in their company, and they’re able to give super granular, specific feedback to those teams.

Colin: 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. 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.

Bill: 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 those comments get seen and heard.

And then when you get into 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, 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 missed 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 can never go back.

How narrative meetings work

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 cofounders of Roam, 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 Roam.

Colin: Yeah, so Amazon meetings with narratives, they are strange to the uninitiated. It’ll be chit-chat before meeting when they were in-person or 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&A and discussion on the questions that have already been entered or that come up. The six-page narrative is a forcing function to where you can cover that amount of information in a one-hour meeting.

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?

Bill: 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 gonna launch this new product? 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, you know, 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 gonna make.

Colin: The one thing I would add is that a lot of first-timers to narratives, right after 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 bandwidth — why dumb it down with a two-minute verbal walkthrough of the document? You wanna get to that feedback loop as quickly as possible, just talking about the document.

Sonal: We didn’t actually really say what goes in the memo. You observed 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.

Colin: 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.

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

Colin: 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 a process that you’re gonna 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 mock-up meetings where everyone thinks they’re a UI expert, but if you don’t have that <Sonal: Yeah, oh god> before and the comments 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 — especially for something that’s going on on an iterative basis, as if you’re refining an idea over time — are tenets. And those are really — okay, what are the design criteria that we are not gonna compromise on, or that we’re gonna fall back on when we have to make tough decisions. And that’s front and center, usually up in the beginning of the document. “Before we go over Amazon’s pricing policy, I want to remind you, here are the four tenets that we’re following to make the following decisions.”

And you know, to get to those tenets, it was difficult. It took 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, you’re gonna be context-switching and reviewing multiple ones every day. And sometimes you may only meet with the team once a quarter, and you wanna be able to very quickly get up to speed.

Bill: There’s another important technique where you can actually add at the end of the document an FAQ section, for frequently asked questions. So, you’re actually anticipating the kinds of questions the audience are gonna ask you. And a talented senior leadership team is gonna ask you hard, probing questions about things like, “Well, you say in your plan that you’re gonna go do X, but it seems to me that there’s an important hurdle here of — you’re gonna need this important partnership, <Yup> you’re gonna — you have this important dependency. What gives you confidence that you’re gonna — actually can 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 the decision-making.

A lot of my work leading — you know, 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, lot of money involved. If we’re gonna go spend that much money, we’re gonna 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 is worth, 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 gonna 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 independent input, an Excel table — all those things can still be in there, but then the narrative needs to clearly state with a clear beginning, middle, and end, like, here’s what we’re proposing to do, we’re not proposing to do, and why.

Sonal: Yeah, I think that the thing I find 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 freaking 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 then 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 gonna make — it actually, what you’re really saying there, and I wanna pull this thread, is — you now can have a better, deeper discussion, because you’ve laid to rest all the common things that you can literally get out of the way in, like, a memo in 20 minutes.

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

Amazon’s guiding tenets

Sonal: I wanna 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 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.

Colin: 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’s — 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 “tenets give the reader an anchor point from which to evaluate the rest” — but here’s the best part. “If the tenet 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 you guys spent meeting after meeting just debating to get the tenets right — which I think is really great, because it allows you to actually separate the thing that the tenet is, and then what flows from that.

Bill: 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? <Sonal: Yes. Yes, exactly> And I was like, whoa, we don’t do that. We didn’t do that back at Amazon. Well, why is that? And one is the use of a tenet, 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’ll 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 tenet, but then, like, 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. So, it was one of the ways [in] which Amazon was very effective, which people don’t realize, as a management company.

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?

Bill: Yeah, great point, because the other thing I also saw was whenever you hired someone new in — within a matter of a week, they would want to go relitigate. They too, <Sonal: Yeah, totally, it’s exhausting> would trip across, well why don’t we do blank? Or why don’t we — and it’s like, oh my gosh — and you can just say, “Look, here’s the tenet, here’s the document. You know, take a look at this, and then come back and, you know, talk to me.”

Starting with the press release

Sonal: Right. And then when you do decide to relitigate, it’s an actual intent <right> versus an accidental, every-new-hire-repeating-recycling <Bill: Right> 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 the reason it’s the 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 wrote a press release for this thing I wanna 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.

Colin: 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?

Bill: 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.

Sonal: What is it, the strengths, weaknesses, opportunities, threats, right? Right.

Bill: Right. But there’s no “C”, there was no customer.

Sonal: Right.

Colin: 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 says, “I have a great idea,” the first thing that the manager or the person in the 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 you know, it could be moving into a brand new industry. It’s a fractal process, which is great.

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 green-lit.

Bill: 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. That — there were already a couple of million iPods that were sold. Millions of people were using Napster to file-share.

Sonal: Napster, right.

Bill: Right? It’s pretty clear that, like, okay — now that we have the internet, it’s just a matter of time before people, you know, consume their media digitally. But we didn’t know how. So, what I did — pulling out my bag of tricks from business school — is [I] marched into meetings with Jeff where, like, here’s our projections for how big the e-book business will be over the next 10 years. And here’s our projected market share. And, here’s what the pro forma P&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 mock-ups?” And I didn’t have any mock-ups at that point. I was doing, you know, like, “Oh, here’s the projection — I’ll get started and we’ll start working on launching, you know, a better e-book store.” And, by “Where are the mockups?” what he meant was, this is all super interesting — or not really actually, is what he was saying — but what’s more interesting is like what is gonna 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 e-books — 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 have 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, like, so many questions and so many details that 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 the 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 FAQ concept, yet. But once we did that, everything changed. And suddenly we were reading, you know, one document was describing, like, a puck that would sit on your countertop, and you can talk to the puck, and could order groceries from the puck. I described the document about, you know, 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, you know, more pithy and clear. And Jeff said, “I know. Let’s write the press release for each one of these ideas instead.” <Sonal: Ooh, neat> And he said, you know, we should read 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 you 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 gonna be able to sell too many.” In other words, if you had known upfront that you needed to hit a BOM [bill of materials] of less than $99 to make this product go, then you would have designed the whole thing very differently 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 gonna solve. Maybe business model problems — but then in the FAQ, then that defines, okay, what are the hard problems we’re gonna have to go tackle to make this exciting product a reality?

So, we switched to that method, and it was halting progress, and had we not really taken that approach, we would have not ended up with what turned out to be a breakthrough product, which was the Kindle.

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, orient it 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 “working backwards” [is], “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.

Bill: 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 e-books were, you could only read them on your PC. There were no, like, offline readers and tablets and devices in those days. They were priced way too high — like, the same price as the hardcover book. The e-books 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 e-books work?

We defined what would be the ideal reading device — everything from, you would be always connected to the internet (which by the way, devices weren’t that way back in 2007). 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 had actually bought a bunch of e-books online, they were magically already uploaded onto your device. All 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 gonna solve this problem” — or, “we don’t know how we’re gonna solve this problem yet, but here’s our path for how we’re gonna go work on that.”

Colin: 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, you know, 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 you know, the first two were centered around storage and compute, eventually. And the press release — one area where it really helped to crystallize everyone’s thinking 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 <Sonal: Wow…> was just a powerful metaphor about, okay, so what are we creating — and, you know, 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. It narrowed down to simple storage service, was the very first thing, and then we would build out from that.

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” — 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 the services you need,” to here is how to create an entirely new business, that’s a whole different game.

Lean startup concepts

Bill: The other thing that’s really important to note, where the PR FAQ process is misunderstood, or, in conflict with the startup community today, is the lean and agile approach.

Sonal: I wanna hear about this. Love it. Cause some fights, Bill.

Bill: Here, let me tell you what the problem is with the lean and agile approach.

Sonal: I love Eric Ries, for the record. He himself is the first — and he’s actually said it on this podcast, that sometimes people get a little cult-y 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.

Bill: Yeah, it’s really — actually it’s the v part. The problem is that people focus on the m, the minimum, and they don’t focus on the viable. So, what is the definition of viable?

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

Bill: 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 with their whole roadmap, and breaks it into these little chunks of how do I you know iterate quickly, test, and learn, then you’re gonna launch a lot of small things where the actual size of the viable business on the other side of it might be sized in the one-million dollar range or two-million dollar 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, or 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 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 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 that don’t really even move the needle at all.

Sonal: People don’t do press releases for incremental releases, they do press releases for big advancements.

Bill: That’s actually an excellent point. 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.

Sonal: Yeah.

Colin: 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 wanna buy or use, it’s not viable.

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 gonna wanna use it, but, to me viable is not just that it’s something a customer would use <Bill: Right!> 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 — 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.

Bill: Yeah.

Colin: Another way where I’ve seen that MVP process being misused — because it can be useful — is that the process itself becomes the goal. And 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.

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 wanna have that very long delay in the feedback loop.

Colin: 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.

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.

Bill: 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.

Colin: The thing is that you wanna 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 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 gonna 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.

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.

Bill: When we were figuring out in digital media and AWS what are we gonna go build, and you parachuted into either of those teams and said, like, “Hey guys, how’s it going?” and we said, “Oh my god, we’re so frustrated, because we just wanna go and build this thing and get it out there, but Jeff, you know, is insisting that we 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 the marine scout sniper saying, 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” when teams were sort of itchy to 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 gonna 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…

Sonal: What to do.

Bill: …what to do. Yeah, people confuse speed and activity, with effectiveness.

Principles in balance

Sonal: Yeah, exactly. What I find so fascinating about that, by the way, just coming back to where we started, is how the 14 leadership principles balance each other. Because you describe Jeff in this context, and a lot of these processes as ways to slow things down up front — but then you also have principle #10 (or whatever number it was), for bias for action at the same time. You think of it as a whole system. And it’s really interesting, because it resonates to me with Ben’s — 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.

Colin: 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 — you know, a lot of people say, well, Amazon, they 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 a $100 billion business faster than any company. AWS got to 10 billion dollars in revenue from zero, faster than Amazon the retail business did.

So, sometimes, to slow down to move fast — even with smaller organizations, [you] 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 <Sonal: Yes, exactly> — that are meant to build up long-term value.

Bill: Yeah, and just to — the AWS thing is so remarkable. Think about that for a minute, because we just told you — I mean, what was it, Colin, 18 months, 24 months? How many months from go, before the team even wrote the first line of code?

Colin: 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 documents?” and they were, you know, 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.

Bill: 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-24 months planning.

Colin: 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.

Sonal: I know. That scares me thinking about that, actually. Like, almost two years planning, like, that scares me.

Bill: Think how scared they were.

Colin: But Jeff had the fortitude to say it’s not ready yet. This is not what we want to build.

Bill: It’s not viable.

Colin: 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.

Sonal: I’m just struck at all the parallels in all the things you guys are saying — because, essentially, every business today is a creative business. What really strikes me is — I’m not gonna make a comparison between podcasts and AWS, but I will say that I talk to a lot of podcasters [about] 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 gonna 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;

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 — and so when you describe that they’re like, “Uh, we’re spending, you know, 18 months writing planning documents,” that is treating software developers as creatives. 

Colin: It also creates alignment for the teams then 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.

Advice for startups

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

Colin: 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 on the problem. <Sonal: Oh, I love that> <Bill: Right> And then, it becomes pretty apparent when you’ve got two or three or four different approaches that, we really need solution A. 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.

Bill: 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.

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 they 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 wanna 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.

Colin: Yeah, this is a case where Amazon faced the same question that a lot of growing organizations do — we’re adding more people, it just 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, to decouple it into what’s now services-based architecture. 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 gonna go grow 10X and 100X, we’re not gonna spend any time building — we’re gonna 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.

Bill: So, the ironic thing is that we started off with the process that was the conventionally accepted traditional wisdom — it 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 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 P&Ls 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 the team saying, “Yeah we really need to go build X, Y, and Z,” and Jeff and the S team saying, “Yeah, I agree, you know go build X, Y, and Z,” — but they’d say, “Well I can’t, because I need browse to do this. And I need the team that works on the checkout — order pipeline, and they already have 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 gonna 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.

Colin: There are 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. And so, that role typically doesn’t fit as you separate into these small, separable, single-threaded teams. The fallacy is [that] as your company grows, that Chief Products 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 the teams closest to the customers making those types of decisions anyway.

Sonal: 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 has its own mini – like GM, of every mini unit as a leader, and then every product — you’re, like, so close to the core in that decision-making framework.

Bill: 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 with studios. But you have all of the resources you need — you don’t have these dependencies that basically slow you down.

Colin: During this timeframe where we’re 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 <Sonal: Oh, great!> are you gonna 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 as 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.

Bill: 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.

Sonal: 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, really.

Bill: And these pieces all fit together, because then we have to move back to like, oh, the reason that Amazon could do that is because those teams wrote narratives and PR FAQs, so they made it abundantly clear. If Jeff wanted to see what is this team doing, “Oh, here you go. Here, read this document” — and in, you know, two hours, he knew exactly what they were doing.

Sonal: Right, he makes him the chief ecosystem officer, essentially, not just the chief slowdown officer.

Shadowing Jeff Bezos

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 wanna 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 whole thing.

Colin: Sure. So, I mean, my role as Jeff’s shadow was primarily two parts. One was just to make him a more effective CEO on a daily basis. Making sure that the right issues are surfaced, that the people coming into the meetings would cover the right topics and have enough information to make the right decisions. And afterwards that it gets followed up on. So, you know, 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 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, 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 efficient. Fortunately, that is a teachable and learnable skill. And Jeff had some great people at Amazon, like Jeff Wilke, you know, who’s a great operator. He’s the CEO of the Consumer Business. And now in his own right, he’s this great operator and insists on the highest standards — it’s 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. So, for instance, Amazon Prime, he made the call that, “Hey, we’re gonna 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 you know customers were basically giving us a B minus on our 3-5 day shipping — even though we had just gotten reasonably competent and spent a couple of a 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 ecommerce industry, so we’ve got to make the change now.”

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.

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 great part of the book, for those that want to learn more, and — Bill, anything to add there on what you saw on the evolution?

Bill: 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 — 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. <Sonal: Wow.> What is, you know, what is our business? What’s our product, what are we building, what are the details of that? 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, how have I — making sure that I assembled 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 to be able to properly audit the work of the teams. And that’s what, you know, we tried to describe in the book, is actually this management science, frankly, that Jeff and the team developed to really solve this problem.

Sonal: “Working Backwards: Inside Stories and Secrets from Inside Amazon” by Colin Bryar and Bill Carr. Thank you so much, you guys, for joining the a16z Podcast.

Colin: Thank you.

Bill: Thanks, Sonal.

Looking for more episodes?
Find them wherever you listen to podcasts.

Subscribe

• Apple Podcasts
• Spotify
• Stitcher
• Deezer
• Google Podcasts
• iHeartRadio
• Pocket Cast
• RadioPublic
• Amazon Music