[S4E2] The Lean Startup

Welcome to Business Books and Company. Every month we read great business books and explore how they can help us navigate our careers. Read along with us so you can become a stronger leader within your company or a more adept entrepreneur. This month we read a modern management classic, the Lean Startup by Eric Reese. The Lean Startup is about bringing the scientific method to the forefront at the start of a new enterprise. Instead of following a classic waterfall development methodology, reese emphasizes the importance of building Quick MVPs that are easily testable based on actionable metrics. Although just a dozen years old, the Lean Startup philosophy has already gone from controversial to common wisdom. In this episode, we'll break down the key ideas and terminology that the book has popularized. But before we get to the book, let's introduce ourselves.

Hi, I'm David Short. I'm a product manager.

Hi, I'm Kevin Hoodak, chief research Officer at a commercial real estate research and advisory firm.

And I'm David Copeck. I'm an associate professor of computer science at a teaching college. Let's start with the author, Eric Reese. Tell us briefly about the author's life and what led him to write this book.

Eric Reese is an entrepreneur, frankly best known for writing this book. I think he attended Yale, where he took a leave of absence to start his first startup, Catalyst, recruiting a forum for networking between companies and college students, which ultimately failed. He returned to Yale, and after graduating, he moved to Silicon Valley to work at a 3D virtual world startup called There. After that company folded, he started IMVU, and he was the CTO of that company for many years, an experience that features quite prominently in this book and inspired a lot of his experiences around creating the ideas that ultimately form the Lean Startup. He briefly worked at Kleiner Perkins before becoming an independent advisor and investor in startups, and ultimately it was advice that he began to document in his blog, The Lean Startup, which ultimately led to this book.

Okay, just briefly tell us what happened next. What does he do today?

He is now still a startup advisor and investor, and he serves as Executive Chair and Chairman of the Board of Long Term Stock Exchange, a national securities exchange focused on aligning investors and businesses towards long term thinking instead of quarterly earnings. And that's actually something that features in the final chapter of the book.

Yeah, it's hard to start a new stock exchange. Good luck to him with that. Okay. A lot of the definitions in this book are pretty well known today, but I do think it's important that we get them out of the way so that we're all speaking the same language. So for the purposes of this book, what is a startup? And for the purposes of the book, I want to mention it's not just a new company, which might be what everyone's thinking yeah.

Through the framing lens of eric Reese startups aren't just a new company. They're an organization of any sort. Whether they're a new organization or they're internal to a larger corporation or a larger nonprofit that's really tasked with figuring out the right thing to build or do that customers will actually want and demand also in the shortest amount of time possible. In particular, according to Reese's definition, they're also doing this under conditions of extreme uncertainty. That element of uncertainty is what, to Reese distinguishes them from a typical company, whether it's a new market environment they're working in, whether there's unsure market demand, new or innovative customer behavior, or a disruptive product that you'd be delivering that may have not been seen before by that customer segment you're targeting.

Okay, and another term I want to get out of the way is MVP, minimum Viable Product. It features very prominently in the Lean Startup, so we really need to understand it. What does MVP mean?

Yeah, and Reese mentions in the back of the book that others have been using MVP for Minimum Viable products since 2000 or so. They've been defining it as the minimum featured product that customers will actually buy. Reese, on the other hand, adds a bit of nuance to that definition, and he says that the MVP is the minimum product that will enable the build measure learn cycle. That is, it allows you to enter that cycle as fast as possible, even if your features aren't necessarily aligned definitively to customer demand in order to get that quick feedback and learning from those early adopters. And then very quickly, iterate fantastic.

Thanks for that. And one last concept I want to get out of the way. The pivot. I think most people know what that is, but what's Reese's definition?

So before I even go into the definition of pivot, we really have to look at the way that Reese views an organization. Early in the book, he puts forth a pyramid. Right at the bottom of that pyramid is vision. Strategy is in the middle, and then product is in the top. So according to Reese, when you're looking at that pyramid, starting from the top, products will be changing and tweaked continuously in the middle. That strategy may have to change occasionally to map and adapt to a changing environment, new learnings, customer reaction to that product. However, he has the vision at the bottom. The vision of the organization should very rarely change. According to Reese, almost like the bedrock foundation, a pivot is happening when the moments that your metrics are showing that repeated product changes aren't really meeting those customer needs and wants.

Right?

And that's when a strategy change is necessary. To Reese, that's called a pivot. When you're looking at your strategy based on an inability to further experiment with the product you have, or if your assumptions are changing, or if your engine of growth needs to change. And we'll explain what that is shortly.

Yeah, thanks for that Kevin, and we'll come back to Pivots later and go into them in some more depth. Now, I know this is kind of a big question to start out with early in the episode, but can you tell us in a nutshell to kind of lay the framework for the rest of the episode what a Lean Startup is and how it differs from a non Lean Startup? How is the whole concept of the quote Lean Startup different from the prevailing startup philosophy that might have been around before the book came out?

Yeah, very simply, Reese looks at the Lean Startup as the application of Lean manufacturing practices to the process of product and service innovation in the startup environment. If you look back at what Reese says early in the book, he says we're in an environment where production capacity is far surpassing possible customer demand, what customers want. So while a traditional startup takes an idea and runs with it with all of that production capacity and it might even persevere rather than pivot when some of those storm clouds are on the horizon, a Lean Startup is constantly adjusting and iterating to real consumer demand and preference. The way that Reese phrases it is, they're not just asking can it be done? But a lean startup is asking, should it be done? And I love that callback to Jurassic Park. Some of the core tenets of the Lean Startup include the fact that entrepreneurs are everywhere, anyone who works within a startup or even small and large established enterprises, and at most tasks can be an entrepreneur. Two, entrepreneurship is management. Three, the concept of validated learning in Lean Startups that through a series of experiments, whether it's split testing, a B testing, lean Startups have numerous inflection points where they can refine a product and business to be more sustainable. The fourth point he mentions is this build measure, learn cascade. This is really how Lean Startups turn ideas into products that actually fit to a customer who's out there. And accelerating those build, measure learn cycles is really the core of efficiency of a Lean Startup. And then finally, the concept he brings up is this idea of innovation accounting. It's just what you said COPEC prioritizing actionable metrics over what he calls vanity metrics. It's the accounting that truly can be refined based on the mistakes that you're making but still learning from them. And it allows those quick pivots to achieve even quicker build measure learn cycles.

Okay. And he contrasts the Lean Startup with what he doesn't think is a good idea, which is the just do it startup. Just briefly, what's a just do it startup?

You're being PG rated and I appreciate it. He actually calls it the JFDI, the just F word do it school. So you can imagine what that F is in that. But for many startups, when that strategic management, when that learning fails, some leaders might just toss things to the wall to see what sticks. Right. Throw their hands up is what Reese said. And they start measuring success with vanity metrics and they're sort of missing the forest through the trees as their customers react to their products. And so it's a much more even though Lean startups are reactive and that they're constantly iterating experimenting and measuring the just do it startup is the epitome of essentially chaotic management and chaotic product unrolls.

Yeah, and I think we've all seen that before either in our careers or in the press. Okay, so MVPs are central to this book. Reese emphasizes the importance of working on new ideas through them throughout. Why are they the central tenant of the Lean Startup?

So, as Kevin mentioned, MVPs give you that opportunity to go through a build measure learn cycle and that's what he thinks is the most important thing. That a lot of startups may bang their heads against the wall for six months just building something internally. And what he thinks is you should get something into the hands of customers so you can get tangible feedback and start to answer some questions about whether or not you really are going down the right path. That you're getting true metrics that can indicate you're onto something that you're leaning towards product market fit and not just executing code and accomplishing tasks that may feel like you're doing something when you haven't actually necessarily delivered something that's actually valuable.

Yeah, and in effect, it's really important to think of the MVP not as the most valuable product, but really the minimum viable product as intended, right. Through experimentation and learning that MVP ultimately is your path to maximum value, but it's what you can get out fastest and most efficiently.

Okay, so you have the MVP and you've both already mentioned this to some extent, but I want to go in a little more depth. How do you go about testing that it's actually the right direction? How do you know the MVP is the right MVP?

So yeah, we mentioned it and we called it a build measure Learn cycle. But to go into a little bit more depth there, what Reese proposes is that you need to have good dashboards that give you, well, I'll just go ahead and go into it actionable metrics and not vanity metrics. So specifically here, he's saying a lot of companies will look at total number of users and that's going up and to the right. And okay, that seems like a good thing, but if it turns out that the way you measured that was just like they logged in one time and they didn't come back at all, then sure, maybe you've gotten some traffic into the platform, but if you're not getting return usage, then it's probably not all that valuable. And so instead, you need to understand the details of the company that you truly are working on and build again, actionable metrics which are going to vary a lot depending on what the company is, but oftentimes relate to cohorts or other methods of saying that the changes we've made have led to customers actually using the product more. And again, he'll use cohort analysis to do that. He'll also use a B test in order to do that. And so again, finding scientific methods of seeing that the change we made to the product led to customers doing more of what is actually critical to us ultimately succeeding as a valuable company in the future. Not just numbers that go up into the right and make VCs happy enough to give us another round of funding, but instead things are going to lead to a truly successful and profitable business in the future.

Let's talk a little bit more about vanity metrics. Let's talk about some examples. I think there were some periods in the history of the tech industry where vanity metrics were really at the forefront, especially during the.com boom in the late 1990s. What's an example of a vanity metric that was very popular in the late 1990s, but ultimately the companies that were only emphasizing this failed when the bubble burst.

Yeah, so I kind of touched on it, but it is really like users versus valuable users. So there were a lot of companies that had paid for a bunch of traffic, they maybe put out a Super Bowl ad, they got a bunch of people in through the funnel and they were using the product. But ultimately those customers were actually like a net loss. So the classic example of losing money per customer, but we're going to make it up in volume. If the customers are costing you money each time, then that's a pure vanity metric. Going up in customers may look good, it may make you feel like you've accomplished a lot, but if the company is going to fail and run out of money as a result of it, then that's definitely a vanity metric.

Yeah.

Working in data, the idea of the actionable metric versus the vanity metric really resonated with me. If you think about a vanity metric, so total page views, for example, it really gives no direction to employees, advisors, shareholders. Vanity metrics can tell every story if you want them to, which leads to perhaps different divisions or teams across the boardroom table starting the blame game that he mentions later. Or they're getting selectively data driven in some of the things they do and not all of them. When you think about an actional metric without any explanation, it can make the path forward so clear and it tells the only story, right? Not every story. It's the difference, like we were just talking about, between presenting total page views versus total visitors, unique visitors and their time spent on each page. That can really help you optimize that website, optimize the customer experience.

And let's talk a little bit more about assumptions too. Can you give us some concrete examples of a type of assumption that you may make that is really one that you should be checking.

Yeah, so I thought this was a really interesting concept in the book around what he calls leap of faith assumptions, that when you're starting a company, you have some gut feeling about what people want. And sometimes there's obvious proof of that. Like, I don't know, food or something like that. We know people want food of some variety, but if you say, I tried some exotic food and no one in America has ever seen that food before, I like it. So I think other people are going to like it. That is definitely a leap of faith assumption that you're making. And so you might want to do a taste test or offer the product for a reasonable price and see if people are willing to pay for it. And again, find ways of measuring actual outcomes with real customers that are not you or your friends, that can then verify the assumptions that you're making. And so you might have a follow up assumption about I like this type of food, but I also think that combining it with American style might make it even more appealing to the American audience. So the first test proved like, Americans are willing to try it this way, but now I'm going to try an A B test. And now my second test is going to be something that combines it with a hot dog somehow or whatever and makes it more approachable to that American audience, and I'll see if that becomes even more interesting and compelling to our customers.

Yeah, I really enjoy the example that he provided in The Book of Wealthfront and one of their original products, the Kaching Game, which was essentially like fantasy football but for stock traders and mutual funds. It was almost like the last star fighter. For those of you who remember the 80s movie where they set up this fantasy trading game and they were hoping their leap of faith assumption was that ultimately there'd be enough folks participating in this stock trading game.

Who.

Would excel and beat professional traders and fund managers that they could then use those folks and recruit them, or at least use their guidance and input to recruit them to actually manage funds. In reality, they had to revise that assumption when I think only seven of the thousands who participated actually demonstrated that above average or elite level decision making when it came to the funds. So that's when you know because you have those actual metrics that it's time to revise those assumptions and consider a pivot.

Believing in the vanity metric itself, I think can be a kind of assumption that you make that needs to be checked. For a lot of folks in tech, it's kind of like what both you've been mentioning earlier. If we build it and we get a lot of traffic, we'll be able to figure out a way to monetize that traffic. And that's oftentimes a flawed assumption. But the flawed assumption actually starts with using the vanity metric to begin with, right? Okay, so you build your MVP. Your MVP is maybe not going exactly the way you intended it to go. The response isn't quite what you expected. You're doing the build measure learn cycle. When do you reach the point that you really have to decide that this is just not going to work? When do you actually go for the pivot? How do you know you've crossed that line?

So, COPEC, one thing I'll say is it doesn't necessarily happen after your first one or two MVPs like you were mentioning. There are some of these companies that Reese mentions that are in the, quote, land of the living dead, right? Organizations that aren't growing or thriving, but they're also not dying, but nothing is really moving forward. And Reese seems to be all about Lean startups constantly creating new value, constantly creating growth. And when that's not happening, whether you're after one or two MVPs or you're in that land of the living dead as an otherwise successful looking company, that's when it's really time to consider the pivot. The way he defines the pivot, it's a fundamental change to the strategy. Remember I mentioned how you have that pyramid with vision at the bottom, strategy in the middle, products at top?

Right.

This is a fundamental change to the strategy because your vision remains the bedrock of the company. Pivoting can happen when you're no longer receiving validated learning, when you're doing those build measure learn cycles, or if your experiments are just in effect, no longer being effective. Pivots are changes that are designed to test new fundamental hypotheses or premises about the product, about the business model, or even about the engine of growth that you've chosen. So, for example, I know we're going to talk about Vodacin one more time before we end the podcast, but their initial engine of growth was assumed to be the sticky engine of growth. That is, you drive more engagement with individual activists and voters in Sense, and then depending on your retention outpacing churn, you'll reach success. But after the failure of their experimentation on that front, they pivoted to a paid engine of growth, right? Moving to more of a B to B platform where they were selling these registered voters who they had validated their registrations in the system and selling access to them to corporations, advocacy organizations, et cetera. Then finally, after not seeing enough growth on that front, they ended up pivoting to more of a viral engine of growth that was more driven by other advocates and activists talking to each other, paying twenty cents per message to reach your elected officials, and essentially recouping and grazing revenue off of those 20 cent messages. But really, throughout that entire process, they were constant experiments, right? And what Reese mentions is that each of the pivots in strategy based on changing up that engine of growth were consecutively faster than the one before it. And again, that contributes to this Lean startup methodology because as you learn, as you build more, learn more, measure more, you're being faster and faster each time you then pivot again.

That's great. Thanks Kevin. I'm wondering if we can think of some other famous pivots, ones that aren't in the book. And sometimes even very large companies make pivots, right? And when they do, just because you're making a pivot doesn't mean it's a good thing, right? I think Reese, one of my critiques of the book might be that he doesn't emphasize how much that actually making a pivot can be fatal too. It could be that you made some flaws in your analysis to begin with and maybe you could have improved things and now you're going to go in a radically new direction, a strategically new direction at least, and this is actually just going to totally flop, whereas maybe you were kind of sort of surviving before. It can be dangerous to make a pivot. I'm just thinking of one off the top of my head that's really big right now, which is Facebook pivoting into Meta, trying to go all in on virtual reality, taking billions and billions of dollars of market cap off. The table by going down a road that nobody wanted them to go down and yet to be seen whether any of that value will be recaptured. They were obviously having some significant problems and limits to growth in the traditional business, but they went down into an avenue that seems to have no redeeming qualities. Pivots can be dangerous, right? Yeah.

Well, I guess what I would say is Facebook is still printing so much money that placing a really big bet on the future is actually kind of different. Like they're sort of doing both right? They didn't stop doing all the Facebook stuff. They just also bought Oculus and they also tried to bet on the future of VR, but they still kept the core product up. Not that they've necessarily focused on as much. To your point, the money that they spent on that could have been given back to investors, could have been spent on improving their core products that are still very successful. I personally do use an Oculus a fair amount for sort of exercise type stuff. I think that's the one area where they're having some success so far, but it certainly has not proven to merit the customer expenses that would match the investment that they've made so far, that's for sure. In terms of other famous pivots that I can think of, stuart Butterfield is kind of like classically known for these major pivots, both in the case of Flickr and of Slack. Those products were originally internal messaging systems or side features that were designed for games that he was developing. So in both cases he was trying to make an online game, the game didn't really succeed. But in the case of Flickr, he'd created like a photo sharing capability that turned in a really successful product. In the case of Slack, he'd created this internal messaging system for the team to build the software with that they decided could actually be a product in and of itself. So very radical. Pivots.

PayPal.

Quite famously, and in a previous episode of Ours, you can learn more Pivoted from their original plan to use Palm Pilots for payments into seeing that it was email was what was actually really succeeding, and people were sending a lot of payments that way. And David Sachs kind of took it and ran with that, recognizing the customer usage that that was really where they could grow and it wasn't the business they'd originally planned on.

So David took my PayPal reference because as our listeners know, I always love referencing back to our earlier episodes. But just to throw a few more out there, I know Avon, which is now known for the Avon pink Cadillacs that are given out. Avon actually started, I believe, as an encyclopedia or a book selling business. And once the founder and doing door to door sales realized that women were more interested in buying makeup at home, they Pivoted there. Another big one would also be Groupon, right, which was profiled a bit in this book by Eric Reese. But with Groupon, they were essentially more socially conscious and looking at funding, big thinking, social justice, environmentally friendly volunteer initiatives. And when they reached the tipping point of funding, that funding would be granted. As Reese profiles in his book, though, they had made this strategic pivot to looking at retail, restaurants, consumer sales, things that were more utilitarian. So what Reese mentions at one point in the book is Groupon's founders had to contemplate, are we ready to make the basis of our business selling off two for one pizzas? And that was a struggle for them. And then one other I could think of is Twitter, which I believe started as Odeo, or a service that was more about organizing podcasts, finding podcasts like ours, and eventually became just this 140 character social blogging experiment that we all know today.

Okay, you guys are all doing a lot of really positive Pivots, but I want to come up with two more negative ones. And again, these are kind of big company ones. They're well known, though. So foursquare, right? Foursquare was a pretty exciting product for a time. And then it seemed like Facebook was kind of copying some of their features and they kind of panicked and they totally went. They broke their whole product into two different apps, changed their business model, and I can't remember the last time anybody talked to me about Foursquare or swarm their successor app since they did that Pivot. Let me give you another one. Nokia was of course one of the largest cell phone makers in the early OS, when Android and iOS were starting to disrupt them, they again panicked. I think in a similar way that Foursquare panicked and decided, well, we're being disrupted. Let's just go a totally different direction. And they fully adopted Windows Phone. Eventually that part of the company got purchased by Microsoft, and nobody buys a Nokia phone today. Right. So I think in all three examples that I mentioned, facebook to Meta, nokia going to Windows Phone and Foursquare, I think we see the danger maybe of large companies with established businesses doing Pivots. Maybe this is really something for the startups.

Well, when it comes down to it, Dave, I know that you're the Grim Reaper of Pivots now, it seems. But all of the positive ones that we mentioned were likely driven by good research and good learning points. Those key inflection points that we mentioned. I mentioned Avon, that the founder was doing door to door sales and was very much aligned and in touch with the customers. But then there's also good research that doesn't necessarily produce much. There was the Food Meal prep service that they mentioned that I'm zoning on the name of that Eric Reese mentioned. But with that example, you had the founders who would literally pick one store and do face to face meetings with customers to get the ingredients they're looking for, the meals they'd like to make, and optimize their menus. It seemed like a really great idea. They put a lot of research into it. They were going along with MVP One, and they were building, measuring, and learning. But in the end, I looked them up. I was going to use them as one of my favorite examples from the story from the book, but they actually are no longer operating. And they only had that one fundraise that Eric Reese had mentioned, and I believe it was called Food for the Table.

I think it was Food on the Table.

Food on the table.

Yeah.

And I thought that I always am a big proponent of research coming from my occupation, but in that case, not even all that research and alignment with customer and multiple iterations could really help them, it seems.

All right, fair enough. I mean, I'm just pointing out that Pivots don't always work out, and they aren't a holy grail that's going to save it every time. Okay, let's go on what's problematic about big batch production, and first, actually explain to us what big batch production is. Reese emphasizes that startups should be doing smaller batch production. So let's start by defining big batch production and let's contrast it with smaller batch production, and then we can go on from there.

Yeah, Reese really simplifies large batch versus small batch with his anecdote about printing and stuffing letters, printing the letters, stuffing the envelopes, and then sealing them. When you're thinking about large batch production, that would mean that you're printing all the letters. So imagine it's. 30 letters. You're printing 30 letters. You're sorting them, you're transporting them. You're then going to stuff all 30 envelopes at once and then affix the seal. On the other hand, a small batch methodology, you would sit there and do one stuffed and sealed letter at a time, printing, stuffing, and sealing the crisis with the large batch production. And obviously these are small numbers just for comparison, but the crisis with large batch production comes when, after printing those 30 letters, you only then figure out they don't fit in the envelopes. In a small batch methodology where you're doing one complete package at a time, you'd have detected this immediately. Right. And those small batch operators were probably more cross functional and maybe came up with some new, faster, more efficient ways to print and stuff and seal the envelopes. When you extrapolate this to a large corporate scale, large batches can keep growing at an unlimited rate, right? Because production capacity is always high. If those large batch operations are constantly growing errors and bugs, just like the printer paper not fitting into the envelope, those keep piling up. And what was meant to initially be a time saver becomes more of a time waster and an absolute nightmare for startups. What Reese is telling us is that small batches enable more experimentation on that build measure learn spectrum. Since you're not experimenting on something so large and vast on which the company depends, or where there's so much coding, there's so much transportation cost, you're also not keeping a large inventory of code product service capacity that you'll ultimately tweak and just waste later on for measurement purposes as well. When it comes to small batch, you can also very easily split up small batches to measure actual causality with consumer action. Remember, what Reese put forward are those three A's to measurement actionable, accessible and audible. When you have large batches with thousands of variables of measurement, it's impossible to really accomplish any of those A's because you can't really correlate what you're doing with changed internal or external behavior. So he's really a proponent of these small batch operations and small batch thinking, particularly when it comes to startups.

Yeah, I love that part of the book. I did hate the example of the envelope stuffing when I was growing up. My dad had a side business running chess camps over the summer, and our family was employed in stuffing envelopes. He would buy brochures, and this was how unsophisticated an entrepreneur he was. He wouldn't pay the company the few extra cents to stamp the brochures or stuff them in the envelope, whatever. I think he could have probably gotten a mass mailing certificate, but he literally had us put them inside envelopes like the family and stuff 10,000 brochures every summer. And I can tell you for sure you do not want to do that using small batch production. If you do that, it's going to take you like 20 to 30 seconds per brochure. Whereas if you split it up and one family member does the folding, one does the stuffing, one does the ceiling, and one puts the labels on, it goes a lot better. And you're unlikely to make mistakes because the whole point of the small batch, right, is like, oh, if you end up making a mistake, you didn't go that far down the wrong direction, right? But when you're stuffing envelopes, you're not going to make big mistakes.

What about if there was a typo, like an Egregious typo, on the printed piece of paper that you only determined after you read it? Stuffing it as the first envelope, sure.

But hopefully you've done that. Maybe you do the first one as a small batch, right? But then after you've done that first small batch, you definitely should be stuffing the rest of those as a big batch, working on an assembly line anyway. Okay, but sorry, that was an unnecessary tangent.

To be clear, COPEC, he technically had a different version of it, which was that it's one person doing it in large batch. So an assembly line is an alternative to the methods that he said where small batch was better. But I totally agree with you. It made no sense to me.

That is fair. And he says in the book, he's like, I know this is unintuitive, and then he gives that example and yes, that example is very unintuitive. I want to go to another technique that's later in the book, towards the end of the book, it's called The Five Whys. Tell us about this technique for finding the cause of a problem, the Five Whys?

So I think we've all probably heard about this before in some ways, but he puts a slightly different spin on it. But essentially it's when you are confronted with a problem, you're going to ask, Why? Why? So like that child that just keeps asking Why? To the additional step that you've responded, you just want to go deeper and deeper until you truly understand the sort of root cause of what may have gone wrong. What he talks about specifically, I mean, I think we can all apply this quite broadly. Anytime you're confronting a problem, you can do that just on your own. But what reesuggests is that this should actually be effectively like a corporate retro session, where when something has gone wrong, you get everyone in the room that was involved in what went wrong and the attempts to resolve that problem. And altogether, you answer those questions and you need to make sure that everyone is there because otherwise whoever isn't there is going to end up getting blamed. And he talks about The Five. Whys turning into The Five blames? Very easily. And I have totally seen that happen. Post mortems are something that I've definitely been through in corporate America. And you do not want to miss the post mortem because you are definitely easily going to get not fully blamed for something. But you can definitely see people manipulate the room in that way. And when there's no one there to defend themselves, it's very easy to frame it in a way that makes some other party look responsible. So I think it's a really good idea. But basically fundamentally about when you confront a problem, you want to dig deep, you want to go beyond just the surface level. And so you see, okay, a customer wasn't able to complete some action. Why did that happen? The website gave them an error. Why did the website give them an error? The server was rebooted. Why was the server rebooted? There was a new person that was working that day and he did that accidentally. He didn't know how the server worked. Well, why was he able to do that? He wasn't trained properly. Or maybe it's too easy to reboot the servers. Maybe there should be a process. And that's kind of like the idea that he really wants to get to is, is there some process or human change that we can make to try and avoid these problems in the future? And so let's not put a band aid on the problem and say, oh, if you attempt to do that then just don't show the error. So the customer thinks that things are okay or whatever, but actually they still didn't complete it. Instead, like, let's actually solve this problem, let's keep the server from getting reset during customer hours or something along those lines.

So I will say short that at first I found The Five Whys to not necessarily be counterintuitive, but it just seemed like it was always leading to human error or lack of judgment, lack of training. But I thought that you just explained The Five Whys even better than Reese did in that chapter. So I appreciate that. And what's coming to me now is the Five Whys are very collaborative. He describes the agenda and the facilitation needs of a Five Whys meeting so that it doesn't become a Five blames meeting. And that really resonates with me because I do feel that that sort of a session should be very collaborative. By asking those wise, wise, wise, it's really leading to that maximum of people value far more what they conclude than what they're told. And so if you gather the team around the table and go through the Five Wise exercise, I can now see how that would be especially powerful. And I do think it's okay for the answer to be, more often than not, more training. One of the things that Reese really gets into is the idea that training, at least back in 2011, was seen for startups as nonessential or a bad word, the idea of training. But Reese puts forward a pretty compelling argument for why training at all levels is very important. And then another thing that he mentions is proportional investments to each of the five whys are important. And I do think when you break down those five whys, it allows you to then attach to each of them a solution, a proportional investment to fix them. And just before we go on, I also wanted to mention that he goes into two rules when it comes to change when it comes to the five whys. One, be tolerant of all the mistakes the first time, and two, never allow the same mistake to be made twice. And this actually reminded me of a commercial real estate firm that I've worked with in the past, embracing more of a startup or disruptive model of property management. And one thing that I really admired was in promulgating this new kind of startup division through the organization, the company's leaders said, we're all bound to make mistakes, but no employee shall ever be penalized for making a mistake in the favor of or in support of our tenants. However, once we've all been coached and learned from that mistake, it just can't be repeated. And I thought that was very powerful when that leader said that the first time. Right, because changing initiatives are hard and really scary, but it's concepts like that that make it so much more appetizing. So I appreciated those two rules that Eric Reese shared.

I actually am sorry about this, but I want to go back to the Pivot discussion a little bit more because I was thinking as since we talked about it, what connected a lot of those companies that failed with their Pivots? And I think a part of it was that they were flailing. A Pivot can be something that you do when you're desperate. For example, when I was doing a startup ten years ago, it was a company we're trying to do reverse auctions for selling new cars. And my business partner, when the company wasn't going well, we were selling some cars, but it wasn't enough. He wanted to totally Pivot to doing helping people find mechanics on the fly, like Uber for mechanics kind of thing. They'll come to you and fix your problem, which we had no background in, no expertise in, in the same way that I think Facebook had no real background in VR other than they bought Oculus, right? But there was no evidence this could be some giant business. It was just a vision thing. It was just like Mark decided, this is the future and this is what we're going to go all in on. Right? So it can be something that you do badly on a whim. I think it can also be something you do when you get desperate and it can actually be totally the wrong call because it can be a huge distraction. Or maybe you could have fixed something. Anyway, sorry, but I just want to tie together my ideas earlier.

Well, I also think it's a big deal too, Dave, to not pivot when it's really called for as well, so we read about Polaroid and Kodak earlier, actually last season, and I also think that there's many examples of companies that just fail to pivot. I do believe that those are almost a little bit more famous than those companies that pivot the wrong way, even though the pivot the wrong ways are a bit more juicy.

That's fair. That's very fair, actually. Okay. Another concept towards the end of the book is that of a sandbox. Reese says that innovators working on a startup should be protected in a safe environment for trying things out. And he calls that a sandbox. How does that also apply to internal startups at large companies? What would that look like for large company to have a sandbox internally?

Yeah, so imagine an innovation sandbox, as he terms it, is a subset of a team with a subset of a product implementing those fast build, measure learn cycles, right? He mentions an innovation black box, much like IBM, when they had separate divisions in separate locations working one on their mainline business, and then kind of a black ops black box team working on the PC, which actually breeded. Some resentment amongst the other team that was kept intentionally out of the loop on a machine that could very well spell the cannibalization of their product line. That's the black box. What Reese is talking about are innovation sandboxes, which really are meant to protect everyone and everything, right? Protect the product and the development process from upper management smothering or Meddling or Shenanigans. Protect the people and the talent, right. Both those working on it so that they can be innovative and do this experimentation. But it also protects the feelings and awareness of those not working on it because unlike a black box with a sandbox, everyone can look in and learn. And then finally it protects the customers because the work that's going on in the sandbox, as Reese describes it, will only be affecting a very small segment of customers. The point of the innovation sandbox, then, is to disrupt from within, but not disrupt with the possibility of doing massive brand damage or customer damage. It's that small subset. And going in this innovation sandbox, empowers those innovation teams or those startup teams, even in large internal corporate environments, to have that full authority, provided they follow several rules that Reese mentions, and then they can simulate their desired disruption or disruptions. And as they demonstrate success in the sandbox, they can then be deliberately and intentionally integrated into larger enterprise.

You know who's really good at sandboxes is actually academia and corporate research. In academia, if somebody has an idea for a research project and they have their own lab, they're pretty much given funds and the ability to explore it in whatever way they want to. There's this whole concept of academic freedom and also just this lack of, to a certain extent, oversight when somebody wants to try something a little bit radical and I think that's why we see a lot of exciting new ideas come out of academia. But corporate research divisions can also be really good at this. If we think about two of the most famous corporate research divisions in the history of Tech bell Laboratories at at and T and Xerox Park, they both were given a lot of leeway to experiment, to do things that weren't necessarily going to right away become a product, to try to develop new products that maybe weren't yet ready for market. I think that this can be, if you have the resources to do it, something that can be incredibly powerful for a large organization.

The classic book about this is Skunkworks about Lockheed Martin spinning up a separate Skunkworks to develop the SR 71 Blackbird. And it's a fun read. We should maybe consider it for a.

Future book and COPEC. One point I was going to say was with the academic side, you call it academic freedom, but I know there's all those sabbaticals and they're just trying to keep you away so you can do your own thing.

It sounds like, yes, I'm on sabbatical next year, I'm going to be able to do a lot of innovation.

And two, I was just going to mention, when it comes to large companies embracing this, sometimes there's large companies that I've worked with who want to embrace this, and even Reese mentions it at one point. You can do all the research in the world. I was working with an appliance company and we were doing great focus groups, market research, surveys. The problem, though, is that with some of their manufacturing practices, tooling up a new appliance or a new gizmo could be a multimillion dollar proposition just to get the template and the tooling done to create a prototype product. And so I'd say there's a lot of organizations that I've encountered out there who do want to be more data driven, who do want to be more Iterative and embrace that Lean Startup methodology. But sometimes it's just impossible to get around some of the manufacturing practices, which is why Reese mentions how important 3D printing and faster prototyping can be.

That's a great point. And so there's some ability to do some of the ideas in the Lean Startup today in certain industries that it wouldn't even be possible in 30 years ago. Okay, we're getting to the end of the book. I actually loved the epilogue, which was chapter 13. I thought it should have been the introduction. In the epilogue, Reese ties the whole book together along with placing it into the larger history of management. He specifically mentions the founder of scientific Management, Frederick Taylor, but he doesn't agree with all of the famous ideas from Taylor's work. What ideas does Reese think are faltering today? From the Principles of Scientific Management. That famous Frederick Taylor book. What are some of the ideas from it that Reese thinks are faltering today?

Well, kopeck. I'm happy to take that and feel free to add some color since it was your favorite chapter. But really, Taylor wrote The Principles of Scientific Management in 1911, so it is very much while innovative for its time, it's also a product of its time. So Reese first sort of caveats this by saying how problematic it was in terms of setting up some bad class racial and gender distinctions. Like I mentioned, though, it was one of those first methodologies to studying work as a science and improving it by a rigorous experimental approach. When you look at Taylor's methodology, it focused on really building more, producing more, and making the wheels and cogs of production even more efficient. Which definitely made sense at the time because things were more focused on the individual rather than the manager.

Right?

Reese now says that that has become, or the science of management has become a bit too widely held a mantra, and instead we should be really focusing not on what can we build, but should we build it? And by focusing too much on can we build? We've really been wasteful in producing too much without aligning to need, right? Customer need, societal need, et cetera. In his words with Reese, we're really trying too hard at the wrong things instead of working smarter towards the right things and therefore needing less actual calories and horsepower and doing more good. And Reese's number one objective, delivering more value. So in his world, the Lean Startup is almost a correction in that always making the customer and societal needs, their wants, their expectations, the mutual value we can all derive, making that the center of this grand story is most important, not just burning calories more efficiently to no end. And so, like I mentioned, while it was groundbreaking at the time, reese just feels that that idea has just become too commonplace and that this routineification and efficiency for efficiency's sake is incomplete and flawed and that it's really about aligning to what we should be targeting, who we should be targeting. And what do they need, not just what can we build?

I love that he put this kind of humanistic tinge because a lot of the book is about being data driven. It's about really looking at your metrics. And then he throws in this like, oh, by the way, actually the why is almost as important as the what. Or maybe more important than the what. And I think it would have been nice if he started with that, actually towards the beginning of the book. Anyway, there were many anecdotes about interesting startups throughout the book. What were some of your favorites? One of my favorites was about the early days of Groupon. And in the early days of groupon, apparently they were using a consumer database called FileMaker. For those of you that aren't familiar with it, this is like what you use to manage a chess camp. This is what my dad used when he was keeping records of who registered for the chess camp. Or this is something I've seen used by photographers to catalog the different places that they've done shoots. This is not something that you usually back a web startup with, and it's not even designed to back a website. This is a database product. It can be used for that today, but especially when Groupon started, this is a product you usually used on your desktop and you, like, hand put records into. And they were not only using FileMaker to keep track of the orders coming into Groupon, but they were actually hand making the PDFs for each of the orders. I don't know if you remember when you use Groupon, you used to get sent like a coupon, basically, that you would print out and you would take to the business, right? And this wasn't being done by some code somebody wrote. Somebody was going into, I presume, like, Photoshop or Illustrator and hand making them for every customer. And then I guess going file saved to PDF. That is, I think, the ultimate kind of example of this whole Lean Startup methodology. Let's just get something that works for these first customers. Try out this idea. And obviously it worked tremendously for Groupon, who became one of the fastest growing companies of all time. So that was one of my favorite anecdotes. What were some of yours?

I really enjoyed hearing about Grocket, which was actually a startup that I used when I was thinking I wanted to go to business school. I signed up for their GMAT prep course, which apparently was an early product of theirs. But actually what I found most interesting was the description of the MVP, which was that the founder of Grockett had been a really successful Kaplan and Princeton Review teacher, and he chose to just literally start teaching people on a webex and charging them for that. And he got enough traction with that and enough people that were signing up and paying him. He was able to raise VC funding to then turn that into a tech startup, which it was when I used it, which was a website with a variety of methods for interacting with other people who were preparing for the test, as well as practice materials and lectures on various concepts. And so it kind of gave you a holistic way of trying to prepare for an exam that I never ended up taking, actually. But I did pay Crockett, so their advertising funnel worked, and I did use the product. It was a good product. I just decided I didn't want to go to business school and didn't need to take the GMAT. But I followed up on it because I was curious as we were reading this. And if you go to Grocket.com now, you get redirected to Kaplan. So evidently in 2013, they got acquired by Kaplan, his former employer, and ultimately the business got shut down and just now as a redirect into Kaplan's own experience.

David, just curious, why did you decide not to go to business school?

I realized that I didn't want to do any of the jobs that would come out of leaving business school if I wanted to be an investment banker and private equity or something that might be something where going to business school would be important. But for the things that I wanted to do, it was better to get additional work experience instead of going and frankly, going into all the debt of the program as well.

Yeah, that makes total sense. Kevin, you had a favorite one too, right? Yeah.

And as a fellow aspiring GMAT taker at one point in my life, I certainly sympathize with short on that as well. But I'd say my favorite anecdote that we read about in Reese's book was Ardvark. And so if you recall, Ardvark had a pretty astounding journey in the early processes, moving from kind of this idealistic brainstorming session where they came up with five different possible companies Wreckit a service to collect your ratings from across the web and give better recommendations to you. Ninjapa, the Web web macros and the Internet Button Company.

Right.

They used the MVP process to unroll iterations of this product. I believe it took them six to ultimately get at this idea of Ardvark, which was a platform that could derive human inspired answers to human questions from their social networks and other web scraping as well. So imagine they settled on this idea of you instant message ardvark a question. It can scrape your social networks, it can scrape the web and provide you an answer that would excel beyond that of a typical search engine. But for the first nine months, they actually had actual human beings answering and vetting the questions on the back end. That alone without investing in the automation, the AI at that point, which might not have even existed to answer these questions, they had humans on the back end answering them. This enabled them to do several build, measure, learn cycles at the cheap, essentially, and ultimately recognize what means the most to our customers. What are the questions that are being frequently asked and how can we pivot some more?

Right?

And ultimately they sold to Google for reported $50 million. And one, I thought that was an interesting journey, a lot of iteration. Some of their different MVP Sprints would essentially be four to six weeks. So they had a lot of acceleration as well. And I just love the idea. It reminded me of Seinfeld when Kramer is replicating Movie phone and he's trying to convince them that he is an automated operator. But then he asks, why don't you just tell me what movie you'd like to see? And so I thought that was amusing.

Four.

Four, four filk excellent memory.

Okay, we're coming to the end of our episode here. I'm wondering if there's anything about the Lean Startup that we didn't talk about that you'd like to mention.

Yeah, I think that one important takeaway for me was with the pivots. And I know Dave Kopeck, you've revisited this as well, but a lot of times you hear startups talking about the runway, what's your runway? And sometimes folks can describe it in terms of their budget, their revenue, their treasury. They have left to pay employees to keep the lights on, essentially. But one thing I thought he brought up that was important was really the runway in the Lean Startup methodology is how many pivots you have left in your budget, in your raise, et cetera. And I thought that was a very interesting way to think of runway. Really, how many times do you have left to iterate measure and learn and then pivot before you sort of exhaust all of your funds, your resources, your staff commitment, your treasury?

One thing I talked about a little.

Bit before, but I wanted to go a little bit deeper on, was the idea that an MVP doesn't actually need to be the product. And I think it kind of came through in the stories we were just telling. But he gave some specific examples of a video MVP being something that they did at imbu, I think it was, where you don't even build the product. You literally just create a virtual representation of what the experience might look like. And you can use that to get people to sign up to an email list, to get an announcement when that product actually gets launched. And again, a way to get clear indication that there is customer interest in this without having to have actually done any true product development, like maybe just spent a few weeks working with the designer. So the idea of either the concierge MVP, which Kevin talked about quite a bit, where there's a lot of humans that are involved when in the future you do plan on doing some tech automation, or the video MVP I thought was something that was really compelling to think about. And these easy ways to get into that build, measure, learn cycle do not actually require a website that's functional and can truly perform the tasks that you're.

Looking to sell to people.

And sometimes your MVP actually does have the functionality your customers are looking for. If you remember with IMVU or I called it Mvue, in my mind, they had avatars walking around talking to each other, except they weren't walking around. And so to get from location to location, reese and his team had essentially programmed a teleport feature because obviously with Mvue, what they had learned was the number one objective of their users was to meet new people. And how do you meet new people, but you have to walk around this digital environment, this 3D world. So they put it out with a teleport feature, thinking that they were delivering something faulty, that they. Would rather have kind of the Sims like characters walking around and meeting each other. Their users and early adopters actually got back to them and said, we actually like the teleport feature more than we would like seeing our avatars walk from place to place in clunky fashion. So you never know. Sometimes those MVP features are ultimately the most viable.

Hate to be talking about Pivots more, but you mentioned Runway Kevin, and another thing that I think should be mentioned is that sometimes the ethical thing to do when you're flailing, which again, I think is unfortunately the situation where a lot of Pivots are made, is when you're flailing. That was certainly the case in our startup ten years ago. But I think the ethical thing to do sometimes is just to shut the doors and return the remaining money to the investors instead of diving into another area with tons of uncertainty. If it's clear that this team was not able to put together a successful product based on the original vision and original strategy, and the new strategy is really questionable as well, or just that we don't have any metrics to back it up. We're doing it just based on the leader's vision or based on if we can't use the learning cycle that Reese describes, then maybe the much more ethical thing to do is to just return whatever money's remaining to the investors. Just think that should be emphasized a little bit more. Right?

COPEC, what did Pivots do to you?

Okay, so do you recommend the Lean Startup? And if you do, who should read this book?

I do recommend it. I thought it was good, to be honest. I do think it's very popular for a reason, but a lot of the ideas have kind of seeped into the culture more broadly. So I'm guessing that you've probably heard of a lot of the ideas that we talked about here, but maybe not heard all of them. But ultimately I do think there's a lot of good anecdotes about different businesses. We certainly did not cover them all in this podcast, so there are a lot of little nuggets to hear about various companies facing these kinds of problems and how they've struggled and pivoted and figured out how to shift away from vanity metrics to actionable metrics. I really think he does a good job laying it all out there and I would definitely recommend it to people that are interested in starting a startup. Or he does make a big deal about how it doesn't just apply to startups, that it can be used at nonprofits or large corporations that are trying to tackle a new problem. I think that that's true. I think that you definitely can leverage these ideas outside of startups.

Yeah, I would echo everything that Short said in both recommending the book but also providing some of that context and nuance that he also mentioned. I think that Short it's all about putting names and terminology to these different things that we all sort of know at this point or are intuitive. So I did like that, that now I have a word for success theater or vanity metrics, or when we talk about some of the actionable metrics as well, or the engines of growth, I thought putting words to those concepts that I can reuse was important. When I look at my own experience, we have folks at my firm who are very, very well versed in Lean Startup methodology and I've already gleaned quite a bit from them. But I wish I had picked up the Lean Startup earlier in my cycle here in the business world. I thought that the anecdotes were powerful. I did sort of regret that by the end of the book. In the disclosures, we learned that Reese has had a relationship or an equity interest in ardvark, dropbox food on the table, grocket, imview, obviously intuit vodazin and wealth front, which were really the core anecdotes that we were given. I'm not faulting him for that. But remember when John Dore with OKRs, he would very, very upfront mention I have advised these people, I have worked with these people, this person is my mentee, right? And it was kind of surprising, I sort of assumed that for some of them, but it was surprising to get to the end of the book and hear that he did have this close relationship with them. On the other hand, having that close relationship does guarantee him unmistakable insight into the operations and the thinking of those companies. So I was a little torn on that. But again, I'd recommend this. I'd recommend it for sure. For folks who have never really been exposed to startup methodologies, I think it would be critical, and I really want to say for large enterprises and even for nonprofits, it would be important for you to read this because as Reese mentioned, startups are just not standalone companies. They can be divisions within large organizations, they can be divisions within service companies. Even so, I do recommend this book.

Hardly personally I enjoyed the book. I think it's a well written book, it's a good book, but I think like a lot of business books, it's unnecessarily long. I think the point could have gotten across in about a third of the pages. I have a friend of mine who's been heavily in software startups over the last decade and he also said, well, everyone kind of knows all these concepts in the book already and you both kind of alluded to that at the same time. I agree with both of you that it's nice to have formal definitions of these concepts and to see how they've played out in multiple different scenarios. So overall I'd recommend it. Do I think you could probably do just as well reading one of those. There's all these books on Amazon that are like a summary of because you don't want to put the time in to read the short book. So here's an even shorter version of the short book. I think you'd probably be fine with one of those, but it's a good book. It's well written. Okay. Next month, we're going to be reading how the Internet Happened from Netscape to the iPhone. Brian McCullough kevin, I think you're actually going to introduce this one for us. Sure.

Very excited to read this. It explains the story of the Internet from 1993 to today. It covers both the technology and cultural waves that propelled the.com era to prominence. It also profiles some key innovators like Mark Andreessen, Mark Zuckerberg, using them as COPEC's favorite word, pivots, to describe the disruption, the innovation, the seismic shifts that the Internet has fostered, and the impacts on modern business, commerce, and personal lives. So very much looking forward to reading how the Internet Happened from Netscape to the iPhone.

Never mind it's about pivots. We got to change our mind, guys. We're not doing this one.

And I've recently read the book. It's great. So I'm really looking forward to that discussion. Before we go, I was wondering if we could actually try the five whys without it becoming the Five blames last episode we had some audio issues. I'm wondering why Kevin's connection was not.

As high quality as it should be. Why Kevin works with a large conglomerated cable company formerly known as Comcast that delivers Internet service to Kevin's house.

And can we get to the soul of this? Why?

Because Comcast is a monopoly provider in the DC. Metro area, and Kevin doesn't like Verizon fios.

See, I feel like you're blaming Comcast instead of taking responsibility.

We got to get Comcast in the room.

Cope yeah, that's true. We can't do it. Okay. Anything.

Maybe Comcast should pivot anything either of.

You want to plug. And how can our listeners get in touch with you on social media?

You can follow me on Twitter at David G short.

You can follow me on Twitter at hoodax basement, H-U-D-A-K-S basement. And you can also find me as close as possible to my Internet modem and router, plugged in via an ethernet cable for our next recording.

And you can find me on Twitter at Dave Kopek D-A-V-E-K-O-P-E-C. Want to thank everybody for listening. As always, it was great to be with you. Want to also remind you to rate us on your podcast player of choice, whether that's Spotify or Apple podcast or Amazon Music, giving us that five star rating helps more people discover the show. Thanks so much, and we'll see you next month. Our.