#159 – Interview with Eric Ries - Transorted Testing Tachydidaxy

Eric Ries: This is The Amp Hour Podcast, recorded previously but aired on August 20th, 2013. Episode 159, with guest Eric Ries, Transorted, Testing, Tachydidaxi.

Dave Jones: Welcome to The Amp Hour. I'm Dave Jones from the EEV blog. And I'm Chris Gammell of Chris Gammell's Analog Life.

Eric Ries: Hi everybody, I'm Eric Ries, author of The Lean Startup.

Eric Ries: Welcome Eric. It's great to have you here.

Eric Ries: It's great to be on. Thanks for having me.

Dave Jones: And for those who don't know, this is a book. Yes. The Lean Startup. Wait, wait, Dave, what's a book? What is it, a website? Is it a blog? Is it a video? It's an everything. I don't know. I mean, there's so many mediums these days.

Eric Ries: Yes, we actually, what we do is we take this thing called ink and we spear it onto dead trees and we pack it in huge boxes, basically, and mail it to people. This has a future, I think. This is absolutely... It's going somewhere. Yeah, it's like an heirloom-crafted vintage object is the way I think about it.

Dave Jones: The future is here and we've seen it.

Eric Ries: And also people can see it online too, right? I mean, so you type it into Google, you also get the leanstartup.com, you get all the... You guys have a conference now, right? I mean, that's another thing you guys are doing.

Eric Ries: Oh, this is great. Thank you for all these plugs. Yeah, we do do a conference. Yeah. December 9th in San Francisco. That's exciting. Yeah, it's become something of a movement, much to my surprise, of people really getting passionate about these ideas. Who's we? Well, so, you know, there's a lot of people who have kind of joined this grassroots thing. You know, I obviously run a company that puts on the conferences and I work a little bit as a consultant, but there's no shadowy corporation behind it. It's pretty much what you see online. There's a bunch of bloggers, you know, and we can... There's a bunch of links on my site to people I kind of consider the kindred spirits like Steve Blank and Ash Maria and Patrick Laskovitz and Brent Cooper. I'm sure I'm leaving people out because you guys have me on the spot. But, you know, I actually think that far more important than the individual personalities involved are the fact that there's just a lot of entrepreneurs all over the world who have taken these ideas seriously and have formed their own meetup groups, you know, in a couple hundred cities now. And really, they're the ones who are kind of acting as the laboratory, pushing the cutting edge of this, you know, more than I who just, you know, just a talking head.

Dave Jones: Well, I think there's even like two or three of them here in Sydney, like on that meetup.com thing. There's, you know, two or three, you know, internet entrepreneurial business startup-y type groups. They seem to be popping up all the time.

Eric Ries: One of the first most surreal experiences of my life was, this is, boy, three or four years ago now, I spent exactly one day in Sydney. Right. It was extremely short.

Dave Jones: Well, you flew all the way here. You flew 15 hours to get here and you spent a day.

Eric Ries: No, no. Luckily, I was in New Zealand. Right. And I got this request from the Lean Startup Meetup Group in Sydney, Australia. Yep, yep. That's one of them. When I stopped by Sydney on my way home from New Zealand. And I thought, well, sure, why not? So, we did an event. We did an event in a pub in Sydney, you know, where I, if I would have told you I knew not a soul in my life. I mean, I don't know anybody in Sydney. I certainly did not at that time. I've met a few since then. And there's like a packed house. All these people in the pub to hear me talk. I give my presentation. And every time I give a presentation, I try to change it up a little bit and, you know, make it a little bit different. Because, you know, you can see the videos online. I try to make it too boring. But I kid you not. Some of the first question, number one from the audience was, how come you didn't do that bit about such and such topic? This is very strange. They knew your routine? They knew my people had watched the video. They knew what to expect. And they were actually disappointed that there was a certain point I hadn't made. And I actually, I sought that guy out because I was so disturbed. Who asked such a question? What's going on? And he said, he's like, listen, I've seen your videos. And there was no book at that time. I've read your blog. And he had actually brought his development team from his company to this event because he wanted them to learn about that specific topic. And, of course, I hadn't bothered to mention it. So he had a really good reason to ask the question. So it was one of the earliest indications I had that there was something going on here with Lean Startup.

Eric Ries: Yeah.

Dave Jones: But you could do, here's my business card. I do consulting. You know, I'll come to your company. I'll fly back for another day.

Eric Ries: Yeah. Oh, God. It's a long flight.

Eric Ries: Dave, did you hear that?

Dave Jones: Yeah, I heard that.

Eric Ries: That was weird.

Dave Jones: Buzzing sound. I have no idea what that was. I think we had a dodgy switch there, folks, in our Samson mic. Hardware issues.

Eric Ries: Hardware.

Dave Jones: Well, this is an electronics podcast radio show.

Eric Ries: That's why I love software so much. This kind of stuff never happens. Right.

Dave Jones: Never happens?

Eric Ries: Yes. Unless there's cosmic rays that, you know, flip a bit by random chance.

Dave Jones: Yeah, exactly. You can get flaky hardware that you're developing software on. You know, it happens.

Eric Ries: Yeah, but anyway, if anything goes wrong, it's always the hardware's fault. That's one of the things I learned as a software engineer early in my career.

Eric Ries: That's it. It's over, guys. We're done here. Well, I mean, tell us about your background a little bit. I mean, so just for people that haven't read the book yet, I mean, everybody definitely should be reading the book. Oh, well, thank you. Where did you come from and how did you get to this point?

Eric Ries: Yeah. Yeah. Listen, no one's more surprised than I am by how this has all kind of turned out. I'm one of those kids that was programming computers in their parents' basement from a young age. So, you know, you can picture me just like all the other nerds, like spending way too much time on the computer and not nearly enough time with other people. And to my parents' credit, you know, they were worried about it, but they were kind of willing to let it go and kind of see what happened. And I really thought, you know, I would be programming computers my whole life. It's something I really loved. I really loved. And when I found out – so, you know, I found out you could get paid to write software. No. Which was like one of the greatest things that's ever happened to me in my life. I mean, really, it was an incredible and a very unexpected experience. And I was like, this is it. This is perfect. This is all I ever have to do. And so, you know, I did a lot of freelance programming as a kid and did like internships. And just like anytime someone would pay me for programming, I was all there. I eventually realized that in the early days of the internet, you could get paid to write books about writing software because it was like a desperate short supply of programmers who could write or who would even want to. So, as a kid, I did that. And then, you know, when I was in college, the dot-com boom was in full effect. And everyone said, you know, if you want to do software, you should become an entrepreneur and start companies. And it just seemed like everybody was doing it. So, I thought, all right, let's give it a try. And by the way, that's not a really good reason to start a company.

Dave Jones: Well, it was in the dot-com era. That's right.

Eric Ries: It seemed like a good idea. It seemed like a good idea.

Eric Ries: But actually, I do not recommend it. In the dot-com era, it seemed like if you had indigestion and it felt like a good idea, people said, yeah, here's a couple million. Yeah, definitely.

Eric Ries: So, yeah. So, I did your, like, classic dot-com failure from my dorm room at school. And, you know, if you've seen The Social Network, like, I like to say that I had the first half of the movie, The Social Network Experience. So, like, all the parts about working really hard and getting all my friends to join the company and that whole thing. Like, we did all the stuff just like we did in the movie. But we didn't have the second half where anybody, you know, wanted to use our product. No one got rich. Dot-com bubble burst. And, you know, in the movies, what's exciting and, you know, in any movie that has kind of an entrepreneurial protagonist, there's all the people that told you, you know, you were wrong to start the company and you shouldn't do it and it's a bad idea and et cetera. Like, in the movie, the most satisfying part is you go back to those people and say, ha-ha, now I'm a big success and, you know, you should have whatever, wrong. So, in real life, let me tell you, the most embarrassing thing to have to do, you can possibly imagine, is you go back to those people and say, yeah, you were right. It didn't work out. And, you know.

Eric Ries: Yeah. Can you just avoid it at that point? I mean, isn't that like a thing?

Eric Ries: Yeah, right. It's like, maybe I should have just changed my name and gotten a new identity and moved to a different place. But it didn't occur to me. I didn't have that international man of mystery skill at that time.

Dave Jones: You have to tell us, what was this startup? Oh, sure. Yeah, listen. Listen, see if this sounds like a good idea, too. Okay?

Eric Ries: We were, this is... Well, it might work these days. Who knows? Well, so here's what the idea, I kid you not. I'm not making this up. This is, they got a picture of us in 1999. We had an idea that college students from top universities starting in the Ivy League should create online profiles on the web for the purpose of sharing. Sounds good. Now, as it turned out... Who's going to want to do that? As it turned out, that's a pretty good idea, if I do say so myself. But unfortunately, and this is like so classic of the dot-com era to me, we were very focused on building a real business. We didn't want to be like, I remember saying to people, we don't want to just be like a Yahoo, you know, we want to be a real business. And so we wanted to use that technology of online profile sharing for the purpose of helping people get to jobs. So it was a resume database. The profiles were called resumes. And you were, you look through the resume and then companies could pay for access to the resumes to help you, help you find a job. And so, yeah, even if someone had come, if you had a time machine and went back in time and told my idiotic 20 year old self, dude, there's going to be this thing called Facebook. It's going to be huge. You have the technology ready to go. You're in the perfect location. You should do it. But I would have said, you know, in my very arrogant way at that age, you're an idiot. You know, I'm trying to make a real business here. Not a business. Yeah, not a business. That's just kids sharing. What I like, you know, I really had no idea what it meant to make a business, which is what happens when you start a company because you heard it is a cool thing to do rather than for any good reason. Yeah. And so, yeah, we went down in flames.

Dave Jones: So are you saying that sometimes if you go into it too seriously, that can be a downfall? Well, that's what's so... Thinking, oh, I'm going to start a business rather than I've got this cool product and I'm going to do it. And if it turns into a business, fine. But if not, eh.

Eric Ries: Well, right. Like people forget, like, and I don't, it's hard to explain to someone who hasn't been through it, but you think that you create a company in order to make money, but that's just wrong. Like a company that is succeeding in its mission will make money as a side. It's like, you know, you need to breathe, you need to breathe oxygen and you need to take in food in order to stay alive. But, you know, we don't live just to carry out those metabolic processes. Hopefully we seek out some higher purpose. And starting a company is like that. You have to have an instinct to try to make the world a better place in some specific way. You know, what we call a vision. I think that's very important. And you have to be willing to change your strategy in order to achieve that vision if your initial idea turns out to be wrong. And I had no concept of that, you know, in my early companies. I just was like, look, you just build a business plan and then it's a business plan. If things go well, like it says in the plan, you get rich somehow. But I didn't really have an understanding of like, why do you do this in the first place? What do you have to believe in to sustain you through the difficult times when inevitably things in the plan don't work out like they're supposed to? And, you know, skipping way ahead, of course, a lot of my work now is about helping people understand that distinction between the vision, which you try to keep as immutable as you can, and the specific strategy, which is subject to change as you get learning from what really works in the market. We call that change a pivot, a change in strategy without a change in vision. But that's something I did not understand at that time. I wish I did.

Eric Ries: Well, it seems like a lot of places still don't understand that kind of thing. I mean, it seems like that, I mean, well, I think of like business plan competitions and stuff like that, right? It seems like there's so much focus on the, how are you going to do this thing? Well, the thing, it doesn't really matter. I mean, oh, you're building another Instagram or you're building, you know, this little sensor board. Oh, whatever. No big deal. So what's the plan though? You know, that's the important part. Yeah. Yeah. Can you make, can you make some predictions for me about what's going to happen in the

Eric Ries: future? Yeah. Soothsayers as it were. Yes. Yes. Sometimes I like to think of what we're doing in lead startup is trying to move us away from business astrology and towards business science. I like that. Right. And the people that, the people that do startups get really offended when I claim that they believe in astrology because a lot of them are engineers and scientists and they people have a technical background. They don't like to think of themselves as astrologists. They take that, you know, quite offensive. But, but if you ask most startup people, really anybody in doing new product development, how's it going? You know what the answer is. It's going great. Always going great. It's going great. Always going great. Yeah. How do you know? How do you know it's going great? Well, let me tell you. I'm not fired yet. Yeah. Last month we shipped this awesome product, you know, new feature. We did this great campaign, whatever, like something happened in the past, in the recent past, and now we are killing it. Numbers are all up and to the right. And you're like, okay, well, I have an alternate theory. Last month, Mercury was in retrograde. And I heard that every time Mercury is in retrograde, numbers go up and to the right. So that's my theory. And if you've ever tried that, they get so angry at you. Like, how could you suggest such a thing? And I'm like, listen, neither of us knows why the numbers went up and to the right. But I'm just visiting. You live here. You actually believe this stuff. Show me some data. It's like, where's the evidence that what you did caused the thing you're celebrating? And, you know, if you read the tech press, like, you know, you read the launch announcements of startups, like they're full of what we call vanity metrics. So it's like, you know, the company has 30 billion messages sent, you know, and it's launching today. And that's really exciting. And you're like, well, what does that really mean? Right. Is that 30 million customers?

Dave Jones: The alternative term for this, of course, is bullshit. Yeah, that's exactly right. Come on. You used a buzzword there. You should have used bullshit. Sorry. That's just one of my favorite terms.

Eric Ries: I'll leave the professional judgments to you guys. Yeah. So Dave is nothing if not professional. Vanity. Exactly. Good to say. Well, it's in the book, though, Dave. And so then the other side of that, though, is, I mean, there's a whole other thing about like what you actually have in order. Oh, the accounting. That's what you call it. Oh, innovation accounting. Innovation accounting. That's the one. Yeah. As you can see, I'm a bit of a buzzword factory.

Eric Ries: But.

Eric Ries: Well, I mean, but that's how that's how ideas are kind of spread. Right. And if you just. Oh, yeah.

Eric Ries: Listen, I'm not apologetic about it at all. Yeah. In order to talk about things in an like in a in intelligible way, you have to have terminology that people can agree on. I agree. And, you know, it just has to go through the buzzword phase because like buzzword is like in an intermediate stage between no one understands what it is to being a universally accepted truth.

Eric Ries: Yeah. Like Kaizen. Oh, I know. I know the Japanese have all these words for it. All the lean stuff. But man, Kaizen always just rubs me the wrong way for some reason. You know, it's just.

Eric Ries: Let me just put it. Words that do not. Words and phrases that don't ever achieve that escape velocity to become universally accepted are very vulnerable for this very reason, because they take on, you know, cultural significance that is not related to the initial thing, but has to do with the fact that like a certain group uses that term and then it becomes a thing anyway. The fact that if it, for example, is kind of end the universal business lexicon, I take as a, you know, as a victory for this trying to help people understand this concept, which is obvious in retrospect. Like, I can't believe we ever thought we could talk intelligently about startups without the ability to talk about this thing that happens to every startup along the way where they have this total failure that is like, gives them a key learning that allows them to make a vital success.

Eric Ries: Yeah.

Eric Ries: And so, yeah. So, but I do believe that part of the problems we have with startups is has to do with the way we do accounting. And, you know, people are always disappointed when they hear me talk and then I'm like, hey, we're going to talk about accounting. I thought we were talking about something cool, like startups, right? Who wants to talk about accounting? But so many of our problems in new product development and innovation really are rooted in accounting. And so we have to make changes to the way we account for progress. Otherwise, we're going to keep having those problems over and over.

Eric Ries: So I was wondering about the lean side of things. I mean, so based on your background, where did you get introduced to lean? Because obviously I've stated my displeasure for Kaizen. I understand the benefits of it, but I still, some of the lean stuff kind of.

Eric Ries: Well, I do understand. So it's funny because for those who don't know, lean comes from something called lean manufacturing, which was a distillation of the Toyota production system. You know, the just-in-time production, as you say, Kaizen, Andon Kord, Kanban, all this Japanese terminology coming out of Toyota, really, you know, starting after World War II, but becoming very popular in the United States in the 80s and 90s. And it's funny. I actually have no background in manufacturing whatsoever. I have never set foot in an actual factory in my life. Oh, that's got to change.

Eric Ries: It's awesome.

Eric Ries: Yeah. Like, I mean, listen, I'm a software guy through and through. Like, you know, mechanical things was never, no forte of mine. I could never even get a bread pour to do anything but catch on fire. So- That's a start. I guess that's right. That's step one. So what's interesting is by the time, you know, so I talked about the failed startup and so, yeah, like in early 2000s, I moved out to Silicon Valley and started doing startups out here and had a bunch more failure. But then finally had a chance to do things differently. I had always been an advocate for agile software development. I was a big extreme programming fan. I had this instinct that if we worked faster, if we had customers more involved, if we kind of did things in quicker sprints with more automated testing, less documentation, that kind of stuff. Like, that was kind of my intuition. And I was always that kid on the team agitating for those things where other people would be like, no, no, no, we're going to do things the traditional way, kid. And by agitating enough, we could kind of reach some kind of compromise. So like, you know, we do it a little bit more agile than otherwise. So like instead of doing an annual release, we do it and release every nine months or something and we would call that a victory. But when I finally got the chance at a company called InView to set the technology direction from the very beginning as the CTO, I was like, no, we're going to do things as close to real time as possible. And so we developed this set of practices that today has a lot of terminology associated with it. But at the time, we didn't even know what to call it. We were just doing it. So take something called continuous deployment, where as we write software, we put it directly into production as soon as the automated tests certify it without having any kind of manual intervention. So we were able to release production, you know, every 10 minutes, 50 times a day on average, you know, really fast. And we could do that without causing problems because we had the infrastructure to do that. So if you've studied manufacturing, you'll be familiar with single piece flow and the end on core that you pull when there's a defect on the manufacturing line to stop the line and immediately intervene. So without knowing it, we were doing something very similar in software. We would, as soon as you would write a module of code, we would immediately deploy it to production in single piece flow because that makes debugging so much easier. If there's a problem, you know instantly what caused it, namely the thing you just deployed rather than when you deploy in large batches. Like imagine, God forbid, a monthly release or an annual release. You take 10,000 different features and deploy them at the same time. Now there's a problem. How do you know which feature is the problem? And that works great in software because when you're building something new, something like 80% of the work of that newness is in the underlying systems and infrastructure. It's not even user visible. So we make, for every one user visible change, we make thousands of, you know, supposedly side effect free infrastructure changes. And my claim is, okay, if they're supposedly side effect free, let's just deploy them right now. You said it was side effect free. And then people are like, whoa, whoa, whoa, I'm scared. Help me, mommy. Right? So I'm scared of it because I'm worried that maybe there is a side effect. Well, if there's no ghost in the machine, there either is or there isn't a side effect. There's no spooky action at a distance. Like either the systems are tightly coupled or they're not. So let's find out immediately. And then the flip side of it is every time we have a surprise, like if there is a side effect and we have to roll back, let's immediately invest in preventing that from ever happening again through automated testing and something we call the cluster immune system. Which allows us to automatically certify each releases is good. And I give you all that background only because at the time you gotta go back. This is 2004, 2005. I'm using these techniques to great effect. I mean, our team at Inview was incredibly productive because we had a better development methodology than most people who we were competing against. And everyone always wanted to know why were we so productive? And the general assumption here in Silicon Valley that something is good is happening. Whoever's in charge of it must be some kind of super genius.

Speaker ?: Right.

Eric Ries: Which couldn't be more wrong. It's almost rarely the cause. Maybe even never the cause. I don't know. So I had this reputation as some kind of technical super genius. And yet, when I would try to explain people why we were getting these results, no one understood what I was talking about. You know, I was talking about continuous deployment and, you know, investors who we want to invest in our company, employees I would try to hire. I mean, I had people working for me who were like 10-year veterans of, you know, some enterprise software company. And on their first day of employment, I would say, listen, you're going to deploy to production today, your first change. Right now, we're going to fix a bug, you and me, at your desk in the next hour.

Dave Jones: And they wet their pants. That's exactly right.

Eric Ries: It was really scary for some of them. And their first reaction was always the same. They'd be like, listen, kid. This isn't how it's done. Let me explain to you how software is made. And I had to be, you know, listen, with all due respect, sir, try it. You'll like it. Sir, I'm paying.

Dave Jones: Sir, I'm paying you. Shut up.

Eric Ries: You know, it's like, I do want to be respectful, but you do work for me. Yeah. And listen, the deal I would offer them was, all you have to do is try it. If you try it my way, and you don't like it, and you think it doesn't make sense, then Leave. Well, I was a lot nicer than that. I said, listen, convince me that we're doing something wrong. If there's a better way to do it, I'm all ears. And so I call it the green eggs and ham defense. It's like, try it and you will like it. And, you know, everybody liked it pretty much. Because it was so self-evidently true that this was a more productive way. I mean, using it, no one ever goes back. But just being able to show people that something works is not good enough. Because like, think about we would raise money from VCs. VCs would ask their tech due diligence guy to come take a look and make sure that the company was on sound footing. Right? Can you see where this is going? Tech due diligence guy is a 20-year veteran, gray-haired veteran of the software industry.

Dave Jones: At IBM. Right. Doing it all wrong. And I'm doing it all wrong. Everything's wrong.

Eric Ries: And so he'd come in and like, listen, kid, this isn't how it's done. And I'd be like, listen, with all due respect, let me show you the evidence that this works. And if you've ever met any 20-year veterans of whatever industry, like the last thing in the world they're interested in is evidence that the way that they've worked their whole career is not the best way. Nobody wants that.

Eric Ries: Yeah. My field is littered with analog engineering is just like nothing but gray hairs. And most of the time I love that patronizing. Let me show you actually how to do it. But yeah, sometimes it doesn't work like that.

Eric Ries: Yeah. Right. And listen, I mean, I don't mean to say that we never learned anything from anyone who is experienced by far be it. In fact, many of our best engineers on that team who advanced the system quite a bit were quite a bit older than I was. But the problem was for the people that weren't reviewing it from the outside, it was my job to explain to them not just what worked but why it worked. And to be honest, I didn't know why it worked. Like the theory of like the traditional engineering theory, and this goes back to pre-lean manufacturing, you know, back to the logic of mass production, says this kind of small batch development with rapid feedback, it shouldn't work. The overhead should dwarf the benefits. But that turns out to be wrong. And so I was studying anything I could get my hands on that I thought might help me figure out what the hell was going on. Because it really bothered me that I was doing something I couldn't explain. And therefore, I couldn't answer people's questions about it. Like as I started to be – remember, I had this reputation for being a super genius. So all these other companies are asking me for advice. Like I'm on people's advisory boards and people are asking me what to do. And I would say, listen, here's how we did it at Mview. Blah, blah, blah, blah, blah. And people would get really angry. Like, you know, like I was saying something insane. Like that will never work. You know, it could – I'm like, I'm not telling you a theory. I'm just telling you a story. It literally works for me. Come visit and I'll show you. That did not work.

Eric Ries: You should have cut out the blah, ha, ha, ha at the end of every time you told the story. Exactly right.

Eric Ries: That's how the super genius becomes a super villain. But yeah. Yeah. I mean that was what was happening to me. And the only – like the first thing I read that really helped explain on the product development side what was working for me were books about lead manufacturing. It was like, oh, here is a theory that has a straightforward application to what I'm talking about that helps understand the logic of batch size, the importance of feedback, the quality benefits of going faster, et cetera. And so that was a big like relief to me. So then I would start talking to people who asked me why this word. I'd start talking to them about Kaizen and all this Japanese crap. And as you can imagine, that wasn't so great either because it's a bunch of people who are like, listen, I want to learn software. Why are you talking to me about manufacturing?

Eric Ries: Yeah.

Eric Ries: And to be fair, there's an important conceptual difference. And this really gets to the heart of what Lean Startup is all about because lean manufacturing and in fact all of our previous business management systems from the 20th century. I mean going back to Six Sigma and scientific management and the Alfred Sloan, General Motors, like the things we teach to our MBAs. Those systems are really designed around known problems. So if you know in advance what the customer wants, they can help you give the customer what they want more efficiently. And in order to do that, they use all these tools of planning and forecasting. So the reason why we have business plan competitions and people are obsessed in business with business plans is not because they like love astrology but because in the old system, we could make pretty good forecasts of what was supposed to happen because the world was a lot more stable than it is today. And the likelihood was if you're in business, you're building something that's a new version of something you've done before. So version 95 of an old, old product like an automobile or pick your favorite product category has a lot more certainty than uncertainty in it. And to the extent that it has uncertainty in it, it tends to be technical uncertainty about a new technology or some new feature. And the insight behind Lean Startup was to say, listen, in a startup situation, what are defining characteristic is uncertainty. We don't yet know what's going to work. We don't know what the customer is going to do. The customers don't read the business plan, so they don't do what we think they're going to do. Our job is to act like scientists and discover what's going to work. And that means planning and forecasting is out because we do not know what's going to work in the future. But it also means that we can use all these Lean techniques like pull and batch size, et cetera, but we have to apply them to a new standard of value, not just what the customer wants because that's something we don't know. We have to apply those same techniques to our hypothesis about what's going to work. So this is really a system of rapid experimentation to discover what works. And that framework unlocked a lot of explanatory power for me. It allowed me to make sense of the things that I had been doing in my own career that worked. And then as other people started to latch on to it, I called it Lean Startup. I started to write about it. We started to take it into other industries. People started to ask me questions like, okay, sure, it works for consumer software. But what about enterprise software? What about clean tech? What about healthcare? What about energy? What about – and I know we're going to want to talk about what about hardware? And at first, my thought was I don't know if it's going to work in these other domains. Logically, it seems like it should, but I don't know. But luckily, since the book came out especially two years ago, a lot of people have said, okay, I accept your challenge, which I didn't even know I had issued. That's fun. Which is let's go find out if you're right, if this is a – I believe this is a general purpose management system to be used in situations of high uncertainty. And so far, so good as we've tried to apply it to more and more strange and strange domains.

Dave Jones: Can it be applied to the one-man band, to just the sole software or hardware developer in their garage, the midnight engineer?

Eric Ries: I think it's even more important in that situation because like when you're doing a job for somebody else – and listen, as much as we glamorize the individual entrepreneur, like the companies that you're familiar with, it's a lot of employees involved. There might have been Steve Jobs alone in their garage like for a little while. But like pretty soon, there's employees, okay? Like way, way, way before the iPod. There's a lot of employees. There's a lot of people working. And to be fair, even most entrepreneurs who take outside money, you're fundamentally working with other people's money in a lot of entrepreneurial situations. And so if it fails, I mean sure you're upset, but you didn't bear the loss directly. It's somebody else's money and you got a good resume. You got a lot of benefits out of it. You got paid. You got a good resume line. You built useful skills. Like all these good things happen to you as an employee. If you're a solo entrepreneur, if you really are a one-man band, it's your life we're talking about. It's the ultimate finite resource. So to me, the greatest crime is to spend all this time and energy working on something and then nobody wants it. And so you basically wind up saying, well, that was a total waste. I wish I'd found that out a little bit sooner.

Dave Jones: Well, not always because the one-man band, often their reason for doing it is because they want to do it. It's their hobby. It's their passion. Well, that's fine. So even if it fails, it doesn't sell. It doesn't matter to them.

Eric Ries: Well, let's distinguish doesn't sell from doesn't have any impact. Because I think it's the rare person. I mean, listen, occasionally I do meet a true artist who's like a real avant-garde to release an art for art's sake. But you never hear about those people because they don't care if anybody hears about them. So they're happy to do the art in their basement and they're done. So they don't even need to distribute it. The vast majority of artists and inventors and scientists, like the vast majority, want to change the world through their work in some way. It's not always a commercial way and that's not important to me. But they want to have an impact. And as soon as you say that, you're like, well, if you want to have an impact, it's going to involve other people. And so the question is, will other people do the thing you expect them to do or not? And a surprising number of times, the answer is no. Other people are stupid and irrational and poor and lack your vision and they refuse to use your thing. I mean, it's just so classic. So if you look at – if you don't want to look at commercial failures, like go on SourceForge and add up the total number of man hours that have been invested in open source projects that have never had anybody download them. Yeah. Right. That's a huge waste of time. And I doubt – and listen, I have plenty of those projects myself, so I'm no better than anybody else at this. A lot of those projects, I would say, are a very sad outcome. Where you say, gosh, it would have been better if they had had actual customers in mind earlier and more involved in the process. They could have avoided this situation where they built something that nobody used.

Dave Jones: But often you don't know what people want to use until you build it.

Eric Ries: Well, that's exactly the question.

Dave Jones: You have to have that finished product. Bang. Here it is. And, you know, there's so many examples of that.

Eric Ries: So I claim – here's my claim. This is very controversial, so not everybody agrees. But my claim is that for any product, there are ways to test if people are going to want it before the final finished product is done.

Dave Jones: In theory, of course there are, yeah.

Eric Ries: Yeah, we call it minimum viable product or MVP, which is the version of the product necessary to get that initial testing and insight into the market. And the reason it's such an important concept – I can prove to you that it is a necessary step if you believe in something called the technology lifecycle adoption curve. So people are familiar with crossing the chasm.

Eric Ries: Is that like the hype curve as well or is that something different?

Eric Ries: It is different, although I think it is related.

Dave Jones: Okay.

Eric Ries: The idea is that as technologies or any new product really diffuse into a population, early adopters try it before mainstream customers. Right? So there are certain products – and those of us who live a little bit more on the cutting edge know this extremely well. There are certain products that you can tell your parents about. They're ready for prime time. And they can just go buy them in a store and set them up themselves. And there are certain products where you've got to tinker with the settings and you've got to know how to download it and you've got to kind of set up it. It's not ready for mainstream consumption.

Dave Jones: 3D printers. Sorry. No.

Eric Ries: 3D printers are squarely in that category of early adopters only. And entrepreneurs, of course, they're very rarely satisfied with early adopters. They have visions of building a product that everyone will want to use. Well, there's actually really good research that says it is impossible for a product to be used by mainstream customers first. First, it has to go through the early adopter phase. And I can prove it to you. It's a very, very simple proof.

Dave Jones: I don't think you have to prove that to anyone here.

Eric Ries: If everyone on this podcast considers it self-evident, then we're way ahead of a lot of the audiences I talk to, let me say.

Dave Jones: Well, our audience is smarter than your average bear. Us hardware people, you know, you go in there with your corporate – you know, try and tell your corporate suits and they just don't get it. Whereas us – Amen. Us hardware people get it.

Eric Ries: You should hear what the corporate suits say about you guys.

Dave Jones: We don't care because we're smarter than they are.

Eric Ries: Amen. Amen. I couldn't agree more. You guys, definitely the smartest and best-looking podcast and audience I've ever seen.

Eric Ries: There you go. Yeah.

Eric Ries: So if you believe what I'm saying, that you have to work with early adopters before you work with the mainstream, then everything I'm talking about follows logically from that. Because you say, all right, if you do extra work to make a product more polished, more ready for the mainstream before you give it to an early adopter, all that extra work is waste.

Eric Ries: Oh, totally.

Eric Ries: Because it doesn't help you get to the mainstream. And the early adopters don't care. That's why early adopters are awesome is they don't need to have all the polished guardrails on the thing. They're happy to go into the advanced settings and muck around. But in fact, if you don't have the advanced settings there, they get kind of pissed. So it actually is counterproductive to make things too slick, too polished before you show them to early adopters. And therefore, one way to think about minimum viable product is to say, what is the least amount of work we must do to get that initial engagement from those first customers in? Well, we're all about the least amount of work around here. That's for sure. That's right. Well, there's one thing I know about engineers, hardware and software, is that they are lazy. Yes. And, you know. I think that's one of our great virtues, as Larry Wall said.

Eric Ries: Yes. So speaking of hardware, let's get into that a little bit. Because I think that's one of the places where I start to have issues with lean startup stuff is kind of defining the MVP for a piece of hardware. Because, you know, it could be – there's always the ambiguity between, like, you know, is Arduino with a breadboard attached, is that an MVP? Or, like, how do you actually define that for, you know, a hardware situation?

Eric Ries: So the first thing that's critical to understand about MVP is it's industry and situation specific. So it's not important that your MVP be as fast as, like, a software guy's MVP. Obviously, if we're building something in hardware, you know, I would say obviously because I know some pretty slow software guys. I know some pretty fast hardware. But often the MVP for a piece of hardware is going to take longer than the MVP for a piece of software. But that's irrelevant. I mean, that's not an important comparison. The question is who's learning fastest in your market, your segment, right? You want to be the fastest learner so that to the extent that competitors are doing anything, you absorb what they're doing faster than they can absorb what you're doing. And so if you think about that, yeah, oftentimes there is a way to prototype the experience for the customer without having the full bells and whistles. So I'll give you an example from a car company I was working with where they had an idea for a new kind of in-dash entertainment system to replace what you normally get, you know, in your car. You know, navigation, entertainment, podcast kind of stuff. So, you know, the traditional way to change that would be to do a massive research development project integrated into the supply chain, you know, and prepare it for the next, you know, for the model year five years from now. And we said, okay, let's do something a little different. Let's, as the MVP, what's the MVP of this experience? We want to see customers using this in an actual car to see if the experience we're creating for them is actually better than the old experience as measured by their lived, you know, experience. Not, I think I'm using the word experience too much, but by what's actually happening in the car versus some focus group or some more abstract thing. So this is like, you kind of see where this is going. We've mocked up a, you know, an alternative plastic housing. It took a couple of days and put a Android tablet in it.

Dave Jones: A tablet in a, yep. Yeah. I was going to say that. It's obvious.

Eric Ries: Yeah. And we wired up an Arduino board so that it could get access to the car's internal electronics. And next thing you know, we got some volunteers, you know, early adopter types who are like, oh, yeah, you want to muck with my car's electronics? Sign me up. No problem. These guys were actually overwhelmed with the initial early adopter response. I think they literally put one ad on Craigslist to say, didn't even say what company it was. It was just like, well, you're thinking of messing with your electronics for a new auto product. Like, you know, are you interested? Please fill out a survey. And hundreds of people, hundreds were excited to try something new. Because you think about like people who like have a long commute every day. Like the in-car entertainment is like so important to them. They're like an innovation here. Awesome. And so from the customer's point of view, they take their car into the shop, you know, and they don't – like it looks like – visually, it looks like the in-car navigation screen has been replaced. Although actually what's happened is we've just slotted an Android tablet in front.

Dave Jones: Yeah.

Eric Ries: And it integrates with like – so it's like very kludgy on the back end. It's totally non-scalable. It has absolutely no supply chain behind it, right? It's like manually done one car at a time. But this company went from, you know, concept to having customers in like 30 days instead of five years. And then this is the second part that's so important to understand about MVP. It's like the phrase MVP causes some confusion because it sounds like it's a product. But really what we're trying to do is start the build, measure, learn cycle of learning. So if you just do one MVP and launch it, that's like doing one science experiment. You can't ever tell. If that goes wrong, you don't really know if the experiment was flawed or the hypothesis was flawed, right? It could be either. So you have to keep going with a series of experiments. So the first version of this that they put in people's cars, the people that actually didn't like very much and didn't use nearly as much as they thought. And it turned out that certain features were a lot more important than others. And like, you know, I'll make something up. This is not their actual thesis because I don't want to give away – I respect their confidentiality. But, you know, so you go and say, well, we don't need radio controls because no one listens to the radio. We'll just gas instead and podcasts are better than radio. And lo and behold, like, yeah, not everybody actually – not actually everybody feels that way. So whatever your thesis is, you have to go in there and discover – Sorry, Chris. Sometimes you want to listen to a sports game live and then you're like, where's my freaking radio? Yeah, of course, of course.

Dave Jones: Right. So like – See, to me, that's self-evident, right? That is just so bleedingly obvious. Like I would call you a dumbass if you thought otherwise. What, to train you mean? Yeah, yeah. Well, to not put a radio in it, you know, it's just – Oh, well, that's great.

Eric Ries: This is what's so great. I actually just made that example up because I can't tell you what really happened because I want to respect this company's confidentiality. Cool. But in almost every case where I've been involved with a company that's done this, at least one of the things that they viewed as completely obvious turn out to be 100% wrong. And the problem is you never know in advance which of your 10 obvious truths is that like fatal flaw that you just missed. And this is really – I think this is the only way to find out.

Eric Ries: Yeah. And then you always have someone fighting tooth and nail for it, right? You have someone saying, no, it has to have – in this case, right, a radio. It has to have a radio. And then if you test it and said it didn't – you didn't need it or you didn't need it, that kind of thing is – because it gets into all the, you know, the ego of people designing and stuff. Oh, totally.

Dave Jones: But you have to be careful though because when you take a feature out and you don't give it to them to begin with, right, if you take that radio feature out and you don't give it to them, they might go, oh, where's the radio? Oh, okay, it hasn't got one. I guess that that's okay, you know, and you can get a false sense of success there if you understand what I mean.

Eric Ries: Yeah. No, no. Listen, this goes to good experimental design. So like in this particular case, these guys did something really clever, which was the initial customers – I don't remember the exact details. It was something like the customer would agree to have this thing installed in their car for a week and then at the end, we were going to take it out of your car.

Speaker ?: Right.

Eric Ries: So what would happen is at the end of the week, we would come to you and say, listen – and I think we're paying people as a beta test. So like you get your usability, you know, $100 gift certificate or whatever your prize was. But they would say at the end of the week, you know, if you'd rather us not take it out of your car, if you want to keep it, you can. And forego your $100 gift certificate. You can keep the device in your car, you know, for another – I can't remember. It was like for another 30 days or something. So it was a way of gauging if people were just like – because people might say, oh, yeah, sure. It sounds fine. Give me my gift certificate.

Eric Ries: Yeah, yeah.

Eric Ries: And they had some people who were not that interested. They said, oh, yeah, you know, it's fine. And like anyone who's willing to have the product removed from their car is not really an early adopter or the product is not really as good as we thought. But some customers were like – this thing had a killer – had one killer feature in it that was actually so good that certain customers would say, yeah, I'll give up my radio for that. Yeah.

Eric Ries: Yeah.

Eric Ries: Like, yeah, so I'm annoyed that it doesn't have radio, but I can't live anymore without this feature. It's so critical to me. And that was the kind of validation that they were looking for. But let me point out another thing that's really important because you said something that was key, which is some people are sometimes nervous that if you're missing a key feature and you piss people off in the MVP, that's bad. But actually, it's actually a good thing. If you have a couple customers who you put a thing in there that has no radio and they're like, what are you, a moron? It has no radio. So then you can – first of all, you can just say, I'm sorry. Take it out of their car and thank them for their time. You got really valuable learning that this thing turned out to actually be important. And you immediately go – remember, build, measure, learn. So we immediately go to the next version that does have a radio and then now we're better off than we were. So it's always better. Even if you're missing a critical feature and you're convinced that it's critical, you're still better off running the experiment to let customers verify that that is in fact something that's important to them versus insisting that it has to have every last thing that everyone on the team thinks is critically important before you launch it to anybody.

Dave Jones: But if it costs you not much in terms of time or money to put that feature in, you're probably better off going with your gut saying, hey, I like the radio, so I'm going to put it in. So then you can avoid that build.

Eric Ries: Listen, we always want you to – you have to believe in your hypothesis or you can't learn anything. So this is like an old lesson of the scientific method, right? You can't run an experiment unless the person running the experiment believes that it's true because otherwise you won't be surprised when it doesn't work. So yeah, if you really are convinced that it has to have radio, amen, then that's what it has to have. But the danger is – especially if they're in a team situation, if you have five people working on a product, they'll have five different ideas about what's essential. And what we don't want to do is just say, well, everybody has to get their pet thing in before we can even run one experiment. It's much better off to say, you know what, we'll just add features one at a time and we'll experiment, you know, one experiment at a time. And hopefully that way learn which of these five features is critically important and which one isn't.

Eric Ries: Sure. So with regard to the, you know, adding stuff in and everything. So one of the things with hardware, it always seems like a limitation is kind of the discrete nature – I think of PCBs, right? And trying to roll in, you know, a new component or even a new big chunk of a circuit, right? You know, how do then – in that case, it seems like it has to have these discrete steps of I'm going to do this and I'm going to do that. Is it – how do you actually then kind of decide when to make that jump? Because that seems like another big issue with iterating.

Eric Ries: Well, there's a couple different ways. The first is, you know, as you guys know, depending on the thing we're talking about, there's often – like most technology platforms, there's a high production count and a low production count version of the technology. Right? Think about like field programmable gate arrays versus, you know, burned silicon. But also like I've worked in some industrial applications where – like I'll give you a funny example from an appliance company. That makes appliances where you have to do injection molded plastic and you really have to like – you have to build out the tooling to produce millions of the unit. But because it's appliances, appliances are regulated. So in order to prove that you pass the ENERGY STAR standard and various other regulatory requirements, you have to produce a prototype version much earlier in the process than the one you can mass produce. And you can do that using soft tools. So, you know, you pay a lot less money for soft tools that burn out a lot sooner but that nonetheless allow you to produce pretty reasonable quality products that, you know, like a consumer would look at it and say that looks like a real appliance. I mean it works. It's completely functional. It passes the regulatory. So I was working with a company that does this and they were trying to build a high-end appliance, not a mass-produced one. So the high-end appliance, you know, the high-end appliance market at the very high end is not that big. I mean the number of people in a given year that can afford like the most expensive appliances is relatively small. So we're talking about thousands, not millions. And yet their internal company rules required them to build out the hard tools, you know, just a part of their normal product development process. So they're going to spend a year building out the tooling for something where – so I was talking to them. I said, well, listen, and the whole – like you think about this as a very uncertain proposition that customers are even going to want this incredibly fancy thing. So I was like, all right, how about if we could sell one appliance? How long would that take? And they're like, what do you mean? They're like, listen, you don't understand manufacturing. Producing one is the same as producing a million. Once you have the line set up, you produce as many as you want. I was like, oh, no, no, I'm sorry. My mistake. I don't mean one line of appliances. I mean what if I wanted to sell one individual appliance? And they're laughing at me. They're like, well, we have one in our office right now. I was like, wait, you've already built this appliance? They're like, sure, we had to. We have one in our office. We use it every day. I said, okay, could you sell that appliance? They're like, well, you know, there is a – our company has like a model store where we allow people to come and see our latest products. I was like, oh, really? Is that like really far away or something? They're like, no, it's in the main building that we work in. I said, okay. So it's literally like 100 meters from where this demo unit is in their – I was like, could you go back to your office? Do you have a dolly? And get a dolly and walk this unit 100 meters to the other place and put a price tag on it to see if anybody wants to buy it. And they were like, you can't do that. And I was like, why not? And they're like, well, our product development process says blah, blah, blah. And they had every dumb, bogus – and these guys that come in being like, listen, software guy, you don't understand. The hardware has all these special things. I was like, listen, you actually already have the tooling necessary to produce more of this thing that you've already built than you probably will sell in your first year. I mean you'd be lucky to sell that many in your first year. So you've talked yourself into this complicated situation when we could be doing the validation right now. And what's awesome was that's a business where new appliances, like really new models, tended to come out like every five to seven years because it took a long time to design and you need to build money and all this tooling. So like the industry structure was set up for slow iteration. So we worked through a plan where they could be on an annual release cycle with this appliance. Software annual releases have gone in the way of the Dodo. Like we don't do Windows 95 anymore, right? You don't put the year that thing came out and the name of the product. That tells you something horrible. Some companies still do it. It's like anytime you see that, you know that something's gone horribly wrong with them because it's at best once a year. No good. But in hardware, in this particular hardware situation, annual releases are going to kick the pants out of their competitors. So it's actually a really good situation to be in. And now here's my favorite part. Anytime you're selling a product that has a long cycle time for the sales process – because it's not like people buy an appliance on a whim. You know, at this price point, it's like part of a designed installation. You know, so there's like a designer involved. It's complicated. You actually can do two build, measure, learn loops. You can be working on the actual product iteration. So the soft tooling and accelerating the development of the actual thing. But you could also be iterating in the sales cycle with the product concept.

Eric Ries: 3D images and stuff like that, you mean?

Dave Jones: Selling the product that doesn't exist yet. Exactly right.

Eric Ries: Almost every customer buys a product based on your version of what it's supposed to be, which is the easiest thing to iterate on the world. So I'll give you another example. This is – I was working with a diagnostics company that makes an extremely high-tech healthcare diagnostics physical device. I mean the science of this thing like blew my mind what I learned about it. It's incredibly complicated, like has patents up the wazoo and, you know, is something that is very difficult to sell because it's an expensive, fragile. Yeah. Yeah. But – Regulatory. Yeah. But on the other hand, the benefit of this thing is off the charts. So it's like – customers have a hard time understanding that what they can do with this device is evil. But once they find out what it can do, they're just like, holy shit, I got to have this. So the problem was, you know, this is not yet an approved device for sale. So we can't sell it yet. But, you know, and regardless of the sales regulatory issue, there's an even bigger problem, which is that it's unclear what the workflow should be for this device. The version of it – I saw it working in a lab and it's a very complicated workflow and it needs to be – it's pretty clear that it needs to get a lot easier before they'll be able to sell it at the rate they want. But how much easier does it have to get is an unknown. So you kind of see where this is going. I said, okay, we go to our printing plastic manufacturer and why don't we use a complete to scale replica of what we think the workflow is supposed to be. So like imagine – it's like printing all the external shell components of all the parts of the device. This device has a lot of components to it. So – and they're like, well, that we could do right now because we have like a proposed schema of what we think the final design is supposed to be. So we actually built in very little time a replica lab that looks like it has this technology installed and it has the workflow set up as a model example. And then we could bring customers into this lab and the customer, we say, listen, sit down, try the workflow, see how it works. Here's the specification document. Here's all the details. Here's the pricing. Here's like all the things you would need to know to make an informed decision about whether you might want to purchase this or not. And then we ask them to make a purchase decision and all the flows are mocked up. So there's like a man behind the curtain. It's a sample lab. So whatever – no matter what you do with the shell, you see the same images on the screen and whatever. But it's a demo. So the customer doesn't know that it doesn't work. It looks like it works. So what's cool about it is every time you bring a customer in, you can change the experiment. So you can offer it at a different price point. You can change the configuration to make the workflow easier or harder. Like this – the big question in this thing was should it have robotic arms that do a bunch of the things for you or can we have humans do it themselves? And that, as you can imagine, adds a lot of cost and complexity to the device if it has to be fully automated versus something that's mostly automated. So those make huge differences to the amount of engineering complexity required. So by figuring out whether customers actually will pay a price premium for that automation or not, we're able to do a much better job in setting up the specification that we have the engineers working on. And in almost every case where I've done that kind of experience, I've done this in like gas turbine engines, healthcare products like we're talking about, like equipment that's used in fracking, like really heavy industrial hardware type stuff. Well, it's obviously more consumer electronics type products. The way we get the MVP to get to market a lot faster is by making the specification document easier by reducing the requirements.

Dave Jones: Of course.

Eric Ries: Because when we are sitting at the whiteboard with some product manager and a bunch of scientists and we're imagining what we think the customer requires in order to buy the product, we tend to get a little bit carried away with the technical standards.

Dave Jones: Right?

Eric Ries: The efficiency has to be off the charts. I'll tell you what company I was working with. Here's how they chose the efficiency. They showed me a requirements document. I hate the word requirements, by the way. There's nothing that's required in this earth except for the laws of physics. Everything else is a hypothesis. So they showed me this requirements document and it has this efficiency target. I said, where does this efficiency target come from? I said, well, that's what is going to be required to win in the market. I said, how do you know? Well, we took all of our competitors' efficiencies of what they are today. We projected five years into the future when this product is scheduled to come out for what we think the competitor's best efficiency using their best technology, blah, blah, blah, will be. And then we added on 10% for good margin to make sure that we're the most efficient. So it's like we extrapolated a thing we don't have any clue about based on information we don't have and then we added 10% just for the cherry on top. And I'm like, okay, how much of the fact that this thing is going to take five years to produce is in the fact that you've set this ambitious efficiency target? Right? Actually, they've proved it. Yeah, if you're done next year, you could just get it out there and check and see if it actually works. I can prove to you conclusively that customers won't pay a price premium for that efficiency target. How much time could we save from this product development effort? In this case, it was something like four of the five years could be saved. I mean, it was really dramatic. Now, listen, I'm not saying that customers don't value efficiency. I'm saying we need to go find out. Let's find out.

Eric Ries: And find out if they'll pay for it, right? That's the key thing is if they'll pay. Right, if they'll pay a price premium for it. Exactly right.

Eric Ries: That's the logic. Like this elaborate business plan. I mean, these guys had a business plan that was like 100 pages and all these spreadsheets. It was a very disciplined, detailed business plan. Like buried in footnote 25 in appendix B, like at the very fine, fine print is this like what we call a leap of faith assumption that says, by the way, customers will pay a price premium for this efficiency. If you take that statement and make it false, the whole house of cards comes tumbling down.

Eric Ries: So how do you deal with that then? Because the thing that always kind of bugs me about it is that, and you talk about this in the book, obviously, is like the siloed structures from, you know, for established companies, there's these siloed structures. Here is marketing. Here is R&D. Oh, yeah. Here is sales. And then like at some point, the price gets set. At some point, the specs get set. At some point, the, you know, how you're going to sell it gets set. And it's like unless you, I don't get how that happens otherwise unless you just smash everyone together. You have to smash it. Yeah. Oh, listen.

Eric Ries: You do? Okay. Like what we're talking about is a completely different management system. It's like a different incompatible operating system than people are used to using in these established companies.

Eric Ries: You have to change it. Let me ask this then. How do you do it? So when you come in, are you just like, when you go into a company and are you consulting, do you just pretty much say, well, you have to do this or you're screwed? Or like, I mean, like how do you actually affect this change in like these big monolithic corporations?

Eric Ries: I may be the world's worst consultant because, you know, think about how someone like me gets called in as a consultant. What happened? Some manager somewhere read my book and they gave it to their boss and they said, hey, you love this book. And he gave it to his boss. Anyway, somebody important finally reads the book. Some senior manager. And he's like, oh, yeah, let's get this guy in as a consultant. So some underling calls me and says, you got to come in. So and so important person wants to talk to you. I say, okay. I come in. I give a talk or something. And then my talk is just, hey, exactly what was in the book but now in a talk. So then we have a conversation. The senior manager always comes in. If they like it, they say, okay, great. Yes, I want to do this in my company. Like they're hoping is going to like, you know, what do we do next? I want to pay you a lot of money as a consultant. Do something for me. And I think what they're usually hoping is I'll tell them you got to fire all your employees and get new, fancy, more entrepreneurial employees. Put up some posters to tell everybody to be more innovative or whatever. Like they were looking for like easy, quick, cheap fixes. And I'm the world's worst consultant because I always tell them, listen, if you're not getting the innovation you want out of your company, look in the mirror. Now you're looking at the problem. All of our innovation problems in corporate America originate first and foremost with senior management because they are setting the accountability standards and the management process that is required to be used across the company. And it's the wrong one.

Eric Ries: Yeah. So Eric, can you start saying, can you start telling them to throw out? So my favorite phrase is the NBA playbook. Yeah. Can you tell them to throw out that NBA playbook? Can you make that a thing? Because I'll never make that a thing.

Eric Ries: Listen, I am honest to God working on it. Okay, good. I like that. And what's interesting is, of course, now I'm not telling them that they should never hire any MBAs and, you know, and that the traditional management systems they have that work for them in the past, they still work for certain kinds of business. So, like, every modern company is a portfolio. And some parts of the portfolio are those things, those products you've been making for 100 years and they're, you know, you're on version 95 and you know the customers well and it's an incremental improvement and whatever. Like, traditional management forecasting and all that stuff works great for those kind of products. What I'm saying is when you're in the startup part of the portfolio, you have to use a different playbook to use the phrase, a different standard, a different set of management practices. And that means no silos, no handoffs, no part-time work. We need full-time engaged small teams with secure funding with a clear mandate and the ability to pivot. And most senior managements that I've said that to have been like, get the hell out of here. You're scared. Like, no way.

Eric Ries: I wanted post-insured. So, you're fired. But, you know. And what they're really saying is I'm afraid for my job, right? I mean, that's what it always seems like to me.

Eric Ries: The things I did in my career that made me successful, they got me to the senior job, you're telling me they aren't the best things. I have to change. I mean, it's not easy. Not easy and like, you know, listen, we got a lot of problems in corporate America including the short-term focus on the stock market and all this kind of stuff that says, hey, maybe if you just hang on a little longer in your high-paying senior management job, maybe this will be the next person's problem. Golden parachute. Yeah. So, it's actually a very small number of extremely impressive, to me anyway, managers who have had both the integrity and the foresight to say, okay, let's go test that. And if I'm the problem, then let's try to see if I can be the solution. And so, you know, a couple of my – like I – last year of my life, I've spent with some very, very large companies working to make this transformation happen. And I was a skeptic at the beginning. I didn't think big companies could do this kind of stuff. But I've now seen firsthand that it is possible if senior management is willing to change the way they behave, you can create the environment that allows internal startups to succeed.

Dave Jones: What you need to do is approach them when they're in the position of going under, losing their jobs and everything else. Then they're a bit more willing. They're a bit more willing when they're under, you know, when their feet are on fire.

Eric Ries: Yeah.

Eric Ries: Yeah. Fair enough.

Eric Ries: So we just have – so we have to get going soon. But a couple of quick questions from the audience. One thing that came up in some of the questions like the themes is just about the iteration of hardware in general, which we kind of touched on a little bit. But so – oh, I can't read this name on Reddit, of course. Of course. But what about – I mean so like how do you fight the need to get it right the first time thing? I mean we kind of talked about that a little bit. But, you know, you set the MVP at a year at some places or, you know, when you come in and you say this is what we have – someone is saying we have to get it right the first time. How do you respond to that kind of thing?

Eric Ries: Yeah. Now, the problem – like there's two different kinds of risk with an MVP that we need to deal with. There's what I call external risks and I call internal risks. So an external risk is something like, hey, if device doesn't work as advertised, someone could die. It could explode. I mean the reason I like software so much more than hardware is that things rarely actually literally explode. But, you know, in hardware, like things explode and people die. So we have safety standards, regulatory compliance issues. Those kind of risks, most companies, most of the professionals I work with know how to mitigate those risks. And MVP is not about compromising on those standards. That would be, I think, a laughably bad idea. But a huge amount of the delay in building a new product and hardware is often stuff to do with internal risks. My professional pride. You know, I'm embarrassed the way this thing looks. It's not the schedule, the official internal process. I am amazed how many companies that have regulatory approval, before they'll even take a product to the regulator, they'll go through years of their internal bureaucracy to, like, decide that it's time to go and talk to someone outside. So, like, all these internal delays. And people are like, well, it's the risk of, you know, what if the thing comes in not on time? What if we have a delay in the schedule? That's not actually a risk. Customers don't care. What if, you know, I don't follow the checklist? Nobody cares. What if it comes in, like, over budget? Nobody cares. Like, your customers don't care. That's all purely internal.

Dave Jones: Customers don't care about anything at all.

Eric Ries: Except the final product.

Dave Jones: And can I get my hands on it? When and how much? Exactly right.

Eric Ries: Does this solve a problem for me? Does it help me in some way? Does it work at a good price? Like, that is what matters. So most of the delays with MVPs are really internal. People's egos, internal process. So, like, once you clear that crap out of the way, it's a rare company that can't get to market a lot, a lot faster. And then you have the courage to take in that initial feedback and then keep iterating, keep experimenting, keep going. So there's still that requirement to have perseverance and dedication. In fact, I think of the Lean Startup as a system for short-term action in the service of a long-term vision. Because if you don't have a long-term vision, this is all kind of a waste of time.

Eric Ries: Probably one last thing here because I know you have to go. So with hardware and shipping it quickly, how do you actually segment the if it works or not? If it's half-baked, how do you – you can't just ship them another product, that kind of thing. You know what I mean?

Eric Ries: Yeah. You have to set up the architecture of both the business model and the physical architecture to allow you to do iteration. And you do that in one of two ways. For some products, you just – you come out with a new version when you come out with a new version. So like think about like the original iPhone that didn't have copy-paste and didn't have 3G and like it was missing all kinds of features. Sometimes you still just go ahead and launch. Then a year later, you come out with a better product and that's one possibility. I'll give you another completely different example as again comes from another – I'm trying to stick with all hardware examples for you guys. This is another heavy industrial equipment company. And this is a product that's used in power plants. So it has a very, very long life. You put this product in market traditionally and it runs for decades. And of course, it's a service contract. So parts wear out. You come in. You fix them. But basically, it's a huge upfront sale and the customer runs it. So we were talking about how do we get into a faster build, measure, learn cadence with our customer in this situation. And one of the things that – this happens to be a product where because parts wear out, there's actually two different kinds of components. There's the physical frame architecture of how the thing is actually built and put together. And then there's like the high-tech components inside of it that wear out. Right? Does that make sense of what I'm saying? Yeah, yeah. Yeah, yeah. So we said, okay, what if we went to the customer and said, listen, we're going to give you today a product. Like instead of waiting five years for a high-tech new product to come out, we're going to give you a product today that has the new architecture but today's materials and today's technology. So it won't have all the benefits of our inevitable thing. But here's what we propose. Instead of a service contract, let's do a business model innovation. We're going to offer you this product on an upgrade path. So every year, we're going to come back to you and give you the option for us to install the latest, greatest materials on the inside of this architecture. And so we can upgrade it for you every year and we'll have a pre-negotiated contract where you pay us for the performance improvements of those upgrades. So if we improve the efficiency of the machine, et cetera, then we get paid more than we do today. And then instead of just getting one major improvement five years from now, we can promise you yearly improvements from now for the next 30 years. Wow. So you think about, okay, what's required to do that? And this goes back to your question about silos and stuff. Like that requires a complete change in the way we build the product, the way we market the product, who our customers are. The service agreement is now completely different. The way the customer pays for the product is completely different. The financial model is completely different. The margins, like it changes a lot of things about the corporation. In order to do a product like that, you have to have a really truly cross-functional team, a startup, working on it together.

Eric Ries: I was also reading about the transition as well. That's another thing of transitioning from a startup mentality and maintaining that throughout as you move into a longer-term life cycle as well. Yeah. Yeah, exactly right. All right. Well, Dave, you got anything else for Eric here?

Dave Jones: No, we better wrap it up. I know we do have some Reddit questions, but I'm not sure if they've been answered. I think a lot of them were covered. A lot of them were covered.

Eric Ries: Yeah, I mean, not directly as we asked them, but a lot of good stories there. And I hope that someday you're able to publish all those stories somehow, Eric. That'd be really cool.

Eric Ries: Listen, if only there was some kind of technology for capturing stories and some kind of data archival system and smearing it on some kind of dead tree surface. I don't know. If anyone ever has an idea about how to make it happen. We need some kind of paper startup. We have the power.

Dave Jones: Where can people buy your book and where can they follow you and read your stuff?

Eric Ries: All right. So let's see. The book is called The Lean Startup. You can buy it at Amazon and anywhere fine books are sold. Is it available on Kindle? It is on Kindle and God knows what else. You can see all the different platforms and everything at theleanstartup.com. We have a conference once a year called Lean Startup Conference. That has a website called leanstartup.co. So leanstartup.co. Our next conference is the week of December 9th in San Francisco. I'm Eric Rees, E-R-I-C-R-I-E-S on Twitter. And so if you follow me, you'll get all kinds of spam about all the great things that I'm doing, including what I ate for lunch, et cetera. And the most important resource, I think, far more important than any of the stuff I have to say is the fact that meetup groups are around the world. So if you Google for Lean Startup Circle or Lean Startup Meetups, unless you are in a very, very remote place, in which case, how are you getting this podcast? It's very likely that there is already a Lean Startup Meetup in your city. A lot of places have a monthly or even more frequent get-together where entrepreneurs can work with each other to try and advance the state-of-the-art in entrepreneurship. And I think that's where the most important work is being done.

Dave Jones: One last quick question. Do you see any competition with other forms of startup methodology, if I'm using the correct?

Eric Ries: Listen, I wish we had more competition. You know, obviously there's a lot of new- That's the correct answer. Thank you very much. There's a lot of good work being done in startup theory, if you will, now, right? There's Steve Blank, who's a mentor of mine, who writes about customer development and a lot about Lean Startup, which I think is a very important resource. You know, there's business model generation and other kind of- There's a great new book called Founders Dilemmas by an academic at Harvard that talks about a research-based look at some of these entrepreneurial challenges. But honestly, the biggest competition is just the inertia of people doing things the old way and just assuming that that's the only way. So, you know, that's- I think that's the number one issue. All right. Awesome.

Dave Jones: Thank you very much for joining us, Eric. Absolutely, my pleasure. It's been awesome. And this has been by far our largest wank word field episode so far.

Eric Ries: And it's been awesome.

Eric Ries: Thank you very much. Thank you very much. I appreciate the compliment.

Dave Jones: No worries.

Eric Ries: Thanks, mate. All right. Take care, guys. Bye-bye. See ya.

Speaker ?: Bye-bye.

Eric Ries: And we forgot to mention that, Eric, you know Tony Long, the former guest of the show.

Eric Ries: Yeah, you should definitely give Tony some kind of plug. I think that's only fair.

Eric Ries: Yeah, of course. Of course.

Eric Ries: Plug. Plug.

Eric Ries: administered administered administered administered administered administered administered administered

Speaker ?: administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered administered