How to Make Your Culture More Entrepreneurial with Eric Ries (Transcript)


This transcript comes from our conversation with Eric Ries, author of the entrepreneurship bible, The Lean Startup. In this Creative Confidence Series talk, we hear his perspective on how to proliferate entrepreneurship throughout larger organizations—which he codifies in his new book, The Startup Way. We loved his thinking on Innovation Accounting, and how to track your organization's progress along the road to building new businesses.


people, lean startup, build, project, startup, ge, company, ideo, organizations, engineers, thinking, called, engine, questions, plan, customer, corporate, problem, functions, design

Suzanne Gibbs Howard 00:05
Welcome to the IDEO U creative confidence podcast, a series focused on building your confidence at work to tackle your biggest creative challenges. Coe Leta Stafford 00:15 Join us as we learn insights and lessons straight from IDEO, and today's most impact oriented design thinking leaders.
Suzanne Gibbs Howard 00:27
Hello, happy New Year and welcome to another of our creative confidence series. I am thrilled to be here today with Eric Ries. Thank you for joining us. And I'm sure the majority of you know who Eric is or you probably wouldn't have joined us today. But just to give you a little background, so Eric is a an engineer and an entrepreneur. But he has become very well known around the globe for a lot of his writing on the lean startup. It's really codifying the process that a lot of startups and entrepreneurs and and creative organizations go through to bring new and innovative offers to the marketplace. But he's here today because he has a new book that we just thought was absolutely terrific here at IDEO, and IDEO U, called The Startup Way. And we're going to talk more about what that is about today. So with that, we're going to start off with a question for you. We know, we love to put people in other people's shoes. And today, all of you out there are going to put yourselves in Eric's shoes. And I'm going to have you imagine a moment that happened in his life. So imagine you're Eric, you've written The Lean Startup. It's like a movement out there and people are following it. People talking about pivoting and an MVP, minimum viable products and build-measure-learn loops, and all of these kinds of things. And then all of a sudden, one day, you get a phone call from the CEO of a major global corporation with like 200,000 people in it. And I want you guys to think through and share in the community chat. What are some of the things that would be going through your minds and and making you sweat as you think about taking something that's coming from a startup and bringing it into a major corporation. So go ahead and share some of the things that would be on your mind some of the challenges, some of the exciting things. And while we do that, we're going to have Eric kick us off by telling us what actually happened to him.
Eric Reis 02:18
Sure, this is a I mean, that really did happen. I tell a story in the book about when GE called and said, "hey, you know, come talk to us about about Lean Startup". And you know, I get that call a lot from corporations. And they they're usually not very serious about it. Because usually what happens is some executive or CEO, they read a book about innovation, they get excited about it, like for 20 minutes, and then they get pulled back into their regular job. So when we actually talk to them about, Hey, this is going to require a cultural change, or an organizational change. They're like, nevermind, forget it. So let's say I take this call, I usually say that's, you know, I'm happy to help you know, let me know what you need, then that's usually the end of it. Especially because I have a tendency to tell people that if they want to know why they're having trouble with innovation, they have to look in the mirror. Now they're looking at the problem. A lot of corporate executives are like, "thanks for coming in". That's the end of it. They don't want to they don't want to hear about their own personal behavior. "See you soon", right, whatever. 03:08
Eric Reis 03:08
I'm not a professional consultant, I don't care. It's no problem. But anyway, but GE called and they said, "no, we're really serious about this. We'd like you to come to the officer's meeting", they called it, in Crotonville, their legendary executive development center. I didn't know GE, especially well, except like, you know, what you see on 30 Rock and from general culture. And so you know, we're looking up I think they were at the time they were the fourth largest company in the world, because they were not like a Fortune 500 company, this is Fortune five, and you're like, "Oh, my God, this is a very large company". And I didn't know what the officer's meeting was at that time. But now I know. It is their annual, like, leadership retreat where they spend three days with the top 250 people in the company. So this is all the CEO's direct reports, plotting strategy for the coming year, and I especially didn't understand this is not an open meeting. They don't usually have outside people here. This is an internal meeting. So Beth Comstock was the CMO at the time, who actually met an IDEO event originally, was really going out on a limb to have me come in and spend five minutes pitching the Lean Startup to this very skeptical crowd, I imagined. It was scheduled for five minutes, we obviously took a lot longer but I think they were very much prepared to pull the plug if it wasn't going well, to pitch Lean Startup. It took me 300 pages to explain Lean Startup, they're like, "no problem, just condense it down to five minutes". And so I can go on and get my little pitch. "Any questions"? And you know, this is a very corporate hierarchical place. There are no questions until the chairman has a question. Everyone's looking at Jeff Immelt and he's like, he calls on one of his VPs by name, so-and-so, "Hey, your division only makes $500 million a year for GE. So how come you're not already doing this"? And then there were a lot of questions. And all of a sudden you're like, oh, he's serious, like, ut-oh, better take it seriously. And, and it was fascinating. So I'm like, watching all these concerns and questions people have, you can imagine the skepticism in this room people are like, "why should I listen to you like software dude, we make engines". A running joke from my years of GE was, you know, "well no one wants a minimum viable engine, these things explode if you don't do it right" and like what do you know, what does software have to do with it, out in Silicon Valley, with a 12 person startup , what does that have to do with us". It was tremendous, tremendous skepticism, but to their credit they said, "well, this is all about experiments, right"? So let's run an experiment. And they asked me to come do a pilot project with them, to like, just a workshop with one of their teams to see how it would apply. And remember, Jeff was like "chairman's prerogative, I get to pick the project". So he's like, "we're not doing an app, there's not gonna be any software in this thing, we're going to build a diesel reciprocating platform called the Series X engine". I said, "no problem - happy to do that. I only have one question. What is it?" So like, it was quite the educational experience for me to like, learn about their business and the physics of it and the business model of it. And to build this program eventually became called Fast Works, a lot of you know, doing a lot of transformations on the company.
Suzanne Gibbs Howard 06:08
Yeah, yeah. I'm going to pause and just look at with some of the things are that are coming in from people, but I can see people are wondering about, you know, what are the challenges, replicating small experiments and creating a culture to accept experiments, implementation and budget, challenge and change challenges? What happens when you change some of them?
Eric Reis 06:27
Yup, terrible.
Suzanne Gibbs Howard 06:29
Does this actually work in other domains besides startup? So you know, apples versus oranges. What is risk aversion? All kinds of things. So I'm curious. Um, I think the majority of people probably with us today know about lean startup methodology. And I'm curious, when you started to think about how the Lean Startup evolved, becomes the startup way. Something that was not just entrepreneurial, but intrapreneurial, and inside of large corporations, what are some of the things that stayed the same in your thinking and what are some of the things that shifted?
Eric Reis 07:00
Well, let me I'll let me illustrate that through the story of this project just to pick up the story when I was like, well, let's actually talk about it. I feel like so many people yeah, my favorite is this guy's like, big mistake. You should have started that way. It's like, now you tell me that would have been really helpful if we did this webinar five years ago. That would be that would be terrific. Yeah. And we we did this with Toyota to for the person asking about Toyota, that was quite a full-circle moment. Anyway, so let me just kind of set the scene for you so you can kind of visualize what this was like. Because this is a very culture clash moment. It was not exactly set up for success the guy is like, "you made a mistake, the group made a mistake." It's not wrong. This was not a great way to start. So here's how we started. Picture a like HBS style business school classroom, tiered seating whole thing. I'm at the front at the podium. To my right in the first row are three people from the Series X team who have been summoned from Texas to Crotonville to have this workshop with me, it was not their choice. They've been told to come here and have this workshop with me. In the back of the room, there are 25 corporate vice presidents, there just to observe. I mean, can you imagine?
Eric Reis 08:02
These four guys from Texas, this is the ultimate lose-lose situation for them because on the one hand, this dumb software guy from California is supposed to teach them something new. If they admit that they learned something from the dumb software guy, what does that say about the quality of their pre-existing plan? On the other hand, if they say that this was a waste of time, what does that say about the chairman who told them to have, so they're just absolutely stuck. And the worst part for everybody is, I don't know anything. I don't know, I literally I use the word engine and turbine interchangeably. I didn't know they were two different things. Which drives them crazy. That's like not only two different kinds of products, but two different, fundamentally different, technologies with nothing in common. So, it was a real cultural clash. What was interesting about it was, I started out and I just I came into the meeting, really with the question you asked on your mind, what's going to be the same, what's different? I didn't know. So I said, "look, let's just apply, let's just pretend, that I'm, you know, in south of market [San Francisco] meeting with a startup who wants to build a diesel engine. And let's treat it the same. Let's see what happens." So I asked the team to present for the whole room, myself and all these luminaries, what is the currently approved business plan for the Series X engine. So this is a product that is used, I subsequently learned, for fracking, for stationary drilling, for distributed power, for marine electric - the engines that power boats, it's used in locomotive. So, like, it was like Dr. Seuss to me like by sea, by land, on a plane, and a train, right. Like, wherever you need power the Series X engine is there. I was like okay, though, whatever you say.
Suzanne Gibbs Howard 09:25
So it's for everything.
Eric Reis 09:26
For everything. It's going to take $300 million and five years to build this product. After which we'll have a global launch and it will be used simultaneously by thousands of people for all these things to make the company a ton of money. And they presented a slide that I will never forget as long as I live - a bar chart, bar graph by year revenue forecast for Series X engine for the next 25 years. And it's a beautiful chart.
Suzanne Gibbs Howard 09:52
Because we know...
Eric Reis 09:52
...obviously we got it right. So the first five bars of this chart, blank, because of course during the five years we're in stealth r&d, there's nobody customers, duh. Right? Then we launch the product and there's this beautiful hockey stick shape, you know, because it's the fantasy plan. And I remember, sitting there looking at the slide, and being like "I don't know anything about diesel engines, but I know this graph very well". Like I mentioned, I'm from Silicon Valley, like, step into my office friends, like, we make this graph all the time. And of course, you know, we don't live up to it, but we promised the moon. So you know, and I asked the people in the room, "okay, who believes this forecast? Raise your hand". And I'm not making this up, every person in the room raised their hand. They're like, "of course, kid you don't understand, the brightest minds of the GE Corporation have proved this. This is the basis of our $300 million investment we have to make the billion dollar ROI etc. I'm like, "my apologies, no offense intended, but, no, really." And I pointed to a bar at random, "who here honestly believes in the year 2023 we're going to have exactly you know, 1.8762-whatever-billion dollars in revenue"? When you put it that way, everyone's hands like well, exactly? Well you know -well." And then we started to have a conversation. "Okay, so what do we know? What do we don't know? And what are the leap of faith assumptions that underlie this plan? What has to be true about the world for this product to be a good idea"? And of course, this is an engineering company, so all they want to talk about is technical stuff, it has to have this efficiency rating, the materials, the blades work like this, the, you know, surfaces or whatever like, it has to work where there's a lot of sand to make sure it doesn't corrode. All the technical gobbledygook. Okay, "but what about the commercial assumptions? There's a customer? Yeah, what's gonna be used for how do you know those are the right five use cases? How does it get distributed? How does it get serviced"?
Suzanne Gibbs Howard 11:30
And five years...
Eric Reis 11:31
Right!? And the business plan, in Appendix B, footnote three says like, oh, follow after five years of development, like solve all those problems later. And so it was okay. "Let's imagine that there's a significant problem with this plan, where the leap of faith assumption is wrong. The distribution network plan is not going to work. When you want to find that out"? Now, or four or five years from now, after you've spent $300,000 or $300 million. And so we started to have a conversation about oh gosh, what could you do to build a minimum viable product to test these different assumptions? And at first, everyone's very skeptical - minimum viable engine and whatever. I was like, "well, you know, just bear with me as a thought exercise. What if we only did one of the five use cases first? Are some of them easier than others? Right?" Like, stationary drilling is a lot easier than putting it on a boat.
Eric Reis 12:21
For obvious reasons. Like the weight is super important on a boat. Not important at all when you're on a stationary drilling. So okay, would that save us some time? And of course, like, the way that these corporate projects and their fantasy plans usually work is we make the engineering problem harder for the designers and the engineers in order to produce a better fantasy. But that's not really a good approach, because we've just compounded uncertainty on top of uncertainty by adding all these technical challenges. So the way we reduce cycle time is not by cutting corners and violating safety or whatever. It's by reducing the scope of the experiment to make it easier so that they get down to three years instead of five years. "Hey, how long would it take to produce one engine"? And they're like, "kid again, I don't think you really understand how mass production works. Once you set up the assembly line and the supply chain and all that stuff, that takes the same amount of time no matter how what you produce one engine or 10,000, its mass production." I'm like, "okay, timeout timeout. Again, no offense, I don't mean one line of engines. How long to produce one prototype"? And they're like, "oh, we have to produce a prototype for safety, testing, blah, blah, blah". And then one of the engineers is like, "well, you know, if you just wanted to do stationary drilling, and you were willing to make the following three compromises, we kind of have an existing engine that's pretty similar to Series X when you just modify..." And how long would that take? And that would only take six months. So if you imagine we're going to get into market with a product six months from now instead of five years from now full 10 x improvement in cycle time, and I'm like, "hey any VPS?" We got all these VPs here. Let's use them. "Any VPs have a customer that might want to buy that?" And of the VPs is like "oh, sure!" I'm like this is working, we're cooking with grease now. We're going to make a salable MVP in the market six months. And finally one of the VPs, who was just like, he's not having it. Not having a good time at this workshop. He's finally like, "I'm sorry, timeout. What the bleep is the point of selling only one engine?" Because he's like, "a second ago, we were going to make $4 billion, and now what are we going to make like $1,000 on this engine?" And of course, I got engineers in room they're very helpful. They're like, "oh, no, sir. We're gonna lose money on the first unit, because we're going to have to sell it at a loss" And he's just like, I'm like, thanks, engineer. That very helpful intersection, right right now, and I really needed that we're like, yeah, look, I think there's no way to recover from that criticism. Like, if you already know what's going to happen in the future. Then you're right. There's no point in running an experiment. Just do the plan. He's like, Okay, great! Problem solved, I'm out of here. He's like, now I won't have to be in this stupid workshop. And that would have been the end of my time at GE, except his colleagues who had been listening this whole time said hold on, hold on. Wait a second. Didn't we just say a minute ago that we don't know what's going to happen in the future, and are there these commercially big signs...and wouldn't we... So they themselves started to negotiate and think about what needs yo be learned, and what are the important things. And that was the star, that eventually became the first project in this Fast Works program.
Suzanne Gibbs Howard 15:06
Eric Reis 15:06
We did hundreds and hundreds of those projects.
Suzanne Gibbs Howard 15:09
And so it was really breaking apart something from that like fantasy plan, figuring out what they didn't know, getting them to share what they didn't know,
Eric Reis 15:16
Be honest about it.
Eric Reis 15:17
It was very counter cultural. Yeah, for a company like GE to admit there are things you don't know, you're supposed to pretend. And so you know, and you have to be you to admit that you might fail - an experiment might not be a success. And like, you have to think like a scientist, right? Experiments, hypotheses. like the experiment doesn't work the way you thought, that's not a failure.
Suzanne Gibbs Howard 15:18
Eric Reis 15:20
That's a necessary part of the learning process. So, it was a very interesting moment of trying to get them to think in a new way.
Suzanne Gibbs Howard 15:39
Yeah. So, I think if, I love this story. I think it's amazing and it's really a great illustration of how you came into thinking about things in this way. If you could capture in a nutshell what you're thinking is about moving to a more entrepreneurial management system. Yeah. How How does that happen? And in this startup land, what are some of the elements of it - of your thinking?
Eric Reis 16:03
Yeah, this is really the thing that I became obsessed with over the past five years, as more and more people would adopt lean startup. And there were really two very funny, very different use cases for lean startup that I would get dragged into, that seem on the surface, like they have nothing in common. So like, I'm with Jeff Immelt and this series, I'm doing these - like mad like we trained. I now routinely meet companies that have fewer employees than the number of managers we trained at GE. Just in Fast Works. And people are like, oh, "our company's too big." Like too big? Like, whatever, oh, like you only have 10,000 employees. Oh, come on, you know, we did this in the federal government. So there's, like, you know, "like people at my organizations too bureaucratic and political" and I'm like, "compared to Obamacare?" I'm gonna say, "No, right?" I'm going to say no on that. So like, there's this massive set of companies and organizations that have adopted these practices, and I've been trying to help them to these transformations. And at the same time, many of the companies who were early adopters of lean startup, you know who I met them when there's five people in a garage. They hit product market fit. Now they have 100, 500, 1,000, 5000 employees, and all of a sudden they have these management problems. The CEO is like, "wait, why is my company bureaucratic? Why are we slowed down? We're not as innovative as we used to be what's going I thought we were the startup, we're supposed to be a perpetual startup, what's what's happening?"
Suzanne Gibbs Howard 17:21
Yeah. And how to keep that same vibe and that same way of being?
Eric Reis 17:23
And what I realized was I'm actually having the same conversation across these different domains. Because we're building these new companies to the same blueprint we've been using for 100 years. The organizational structures, incentives and systems of these companies are relatively unchanged over these decades. And I'm like, "wait a second. Can anyone think of any ways the world has changed in the last hundred years might necessitate some new thinking like, surely we could do better?" So I became obsessed with the question - first, it was really, "how do we transform these companies, these big companies to prevent them from dying?" Then it was, "how do we prevent these new companies from being built to old fashioned blueprint?" And I eventually realized like, the issue is not so much - it seems like an intractable problem, "we have this bad culture, we have as bad..." Like all this stuff. But I was like, "wait a minute. How come every startup is built to the same org. chart?" It's because founders have a mental model of our company is supposed to be that is old fashioned. So, if we can our mental concepts, our vocabulary, the diagrams, the like, the concepts of what does it mean to be a modern company, we can stop making this mistake over and over again. So, we did this kind of odyssey of trying to discover what would the blueprint of a modern company look like and the book is my attempt to answer that question.
Suzanne Gibbs Howard 18:36
Wonderful. Coe Leta Stafford 18:37 Hey, guys, just want to tell you a bit more about IDEO U. We're an online school where anyone can learn to solve anything creatively. Built for individuals, teams and organizations, IDEO U equips leaders with the tools and mindsets necessary to ignite creative confidence and tackle complex challenges. This fall, register for Hello Design Thinking, our introductory design thinking class taught by David Kelly. And check out Tim Brown's five week leadership course Leading for Creativity. If you're liking what you're hearing, sign up here for more at Now, let's get back to the conversation.
Suzanne Gibbs Howard 19:27
People are asking about how you can leverage both design thinking and the lean startup or the startup way at the same time. So, what are the overlaps and what are the distinctions? We get this from from Sal, one of our business designers in Chicago, and I'm hearing same thing from people from Malaysia.
Eric Reis 19:47
Very common question. There's actually a little mini book that just got published. It's called Lean Startup Versus Design Thinking Versus Agile. It's just like a whole whole essay just on this one topic because it's common. I'll tell you a secret - just between me and my 3000 closest friends on this webinar - the truth, the very truth of this is, if I ever am giving a talk to a vertical slice of the company where everyone in the room has the same job title, it's all designers, all engineers, all marketers or whatever, generally speaking, somebody will eventually come up to me and say, "listen Eric, isn't Lean Startup just agile, but rebranded for business people?" And like if it's a business person, I love like, "isn't this just lean manufacturing, but rebranded, you know, for designers?" Like, "isn't this just design thinking but rebranded for engineers?" And I'm always like, no matter what it is, I'm like, "you're totally right. It is. But do me a favor, don't tell the other functions that. If the engineers knew that I was like tricking them into doing design thinking they might not like it as much. So let's keep it between us." Because the truth is, I went way out of my way when I built lean startup, to build it on a foundation of every good idea I could find. So design thinking, agile, lean manufacturing, DevOps, customer development, even maneuver warfair like OODA loops Fair and John Boyd for those that know that, like and the scientific method, of course. So like I tried to synthesize the parts of those systems that made sense to me. But it was very important to me to not create another functionally siloed method. Because what happens is like, if you're a CEO of a company these days, like once a month, your head of each function will walk into your office and say, "boss, ya know what will be really great? If you could make the other functions do my thing and put me in charge, it would be the bomb, right? So if you could just get the engineers to do design thinking that would be sweet." But like, the head of engineering was here yesterday being like, "could you just teach the designers to do agile?" Because of the way we built these companies, we have forced people into a very adversarial relationship between functions. I know all these manufacturing people, "I don't want to a software thing that's not my..." Everyone has their own thing. And to be fair, every functional method has a unit of progress that is functionally specific. The easiest one to see is agile with burndown charts and lines of working code and story velocity and stuff like that. If you've ever tried to get non-software people to care about velocity charts and burn down charts, you'll know it's a very challenging thing to do. Design thinking has its own products, similar concepts where it's just hard to translate across domains. So my insight was we need to create a cross cultural, cross company, learning method with its own vocabulary that is not rooted in any one function and units of progress that can be translated to things that everybody in the organization cares about, which is always resources and impact. It has to be translatable for even for the business people even for the CEO, it can't be about our proprietary thing. And so that's that's the starting point for understanding what the relationship is between lean startup and these different approaches. I tried as much as I can to import those concepts, but to either rename them or tweak them so that they would have wide adoption. I can tell you a lot of stories about companies were - I won't name the company - but I was just in a company where they had a totally segregated agile software division, separate from their hardware division. So, these two groups don't ever talk to each other and they have a lot of mutual mistrust. Ironically, the hardware people had been really embracing lean startup, and were really liking it. And the software people were like, "we don't need that. We already have agile." And they asked me would I come in and meet with like 100 agile coaches in their software division. I said, "sure." So I come in, I have this meeting, I'd given the pitch: lean startup. It's the exact same conversation, but for engineers. And at some point, someone's like, "yeah, but even if we do lean startup, we can never get the hardware people to do this. They'll never do lean startup." I was like, "well, let me tell you some stories about hardware people who are already doing lean startup." And they looked at me like I had conducted black magic. They're like, "you got them to care about iteration?" And I'm like, "yeah, because I wasn't trying to lord it over them. I invited them to connect..."
Suzanne Gibbs Howard 23:59
I feel like you're solving for more contemporary ways of working.
Eric Reis 24:04
That's right.
Suzanne Gibbs Howard 24:04
Ones that we all face with the way that markets are.
Eric Reis 24:06
Yeah. So specifically for design, I do think the Achilles heel of design thinking - not in the way that it is designed, it's not intrinsic to the theory, it is a consequence of how we structure it in a lot of organizations - imagine I have a God's eye view of the corporation and each of the siloed functions is literally like a big grain silo, imagine like a big giant God size Pringles can. And so if I zoom in and like pop the top off one function, I'd be like, "oh, look at the agile guys like running around doing this highly iterative, highly experimental, customer centric methods. Oh, look, the designers are this incredible design thinking, hey, look at manufacturing, the manufacturing, customer development, everyone's doing their iterative thing." And I say "well, is this an iterative company, a learning oriented company?" And in a lot of cases the answer is "no." Because how does work get passed from silo to silo? I have been in too many organizations where they use design thinking to produce a specification document, which is then handed to the engineers for implementation. And five minutes after the handoff, the engineers are looking at the spec document it says what says here is, "this thing should be infinitely fast and infinitely cheap, but you can only have one of the two. So which is it?" And the designers are like, "my work here is done, like, just build the spec." Right? And it's like, "we can't keep working on it, we did all the learning for you."
Suzanne Gibbs Howard 25:22
So one of the things that you've really tried to do is structure something that works across the entire organization, and brings this mindset and a way of thinking that's invited into the corporation.
Eric Reis 25:33
When you have engineers and designers in particular, because this is most of the most contentious relationships in most companies, when you have them working side-by-side as peers, you wind up with better learning on both sides. So I mean, you wind up where you actually bring engineers into the design process early, they can give their input about what's feasible, and also they can be learning about not just what the spec is, but why: "why did we make that choice? Who's the customer? What's the use case?" Even if you wind up handing off the implementation later, you know, you still get this learning that's transferable, but even better in this sort of way, we say, "you know what, we don't ever have to do handoffs, we could just build cross functional teams from scratch, and have them work like a startup."
Suzanne Gibbs Howard 26:15
So, I'm going to move on to another question we have here. What are some of the mistakes that large organizations typically do in the very beginning when they're trying to integrate this entrepreneurial way? So it sounds like there are definitely challenges with working across functions. There are problems with the CEO, they need to look in the mirror. Just list for me some of the patterns that you've seen in the in the variety of companies.
Eric Reis 26:44
Just like, "hey, that's not design thinking." I'm like, "I'm with you, Jeff [Immelt]." The point is that when we bring these good methods into a warped organizational structure, we wind up warping the method. So yeah, of course, we shouldn't do what I just described with the binder and that's that's like, yeah... The whole point is, we have to figure out how to prevent the CEO and the business executives from structuring the company such that we create this adversarial relationship. So working cross functionally is a very difficult thing for most companies to do. I would say that like the three like super hard, but really obvious things that people do wrong are, they don't have proper team structure. They don't assign. They don't create cross functional teams. They don't have people work on their startup full time. Right? So they have people working on 20 things at once. If you look at the psychology literature about productivity, every study that's ever been done, as far as I'm concerned, in the history of the world, that's looked at multitasking has found that is not effective. It's never good at doing one thing at a time. There's no evidence to support it at all and yet, I constantly meet teams where everyone's working on something 10% of their time, 20% of their time. And there's like a corporate disease where we just can't admit that we're not doing as many things as we say we're doing. So, we pretend that we're doing 20 projects, but we're really only doing five, and so like 15 of them are just like hanging out. It's a mess. Like, can you imagine? So imagine I was like, "hey, I got an idea for a startup. It's gonna be this awesome, new revolutionary technology, I'm going to get it funded, it's gonna be great. Here's my plan. I'm going to pick 20 people, and I'm going to assign them to show up at my office on Monday. I'm going to have them work 20% of their time on this new startup. And we're going to get funding from a VC where, instead of raising like a round of funding, what I'm going to do is say like, hey, every quarter, give me some more money until I tell you stop." Not one startup in the history of the world that you've ever heard of could have been done this way/
Suzanne Gibbs Howard 27:16
Or would have gotten funding.
Eric Reis 28:34
It's totally crazy. So there's like three classic mistakes, cross functional, like we build functional silos. We don't put people on project full time and then we don't fund projects correctly. We use, in the book, I call it entitlement funding rather than metered funding.
Suzanne Gibbs Howard 28:48
Okay, great. I'm gonna move on to another one. I can see just tons of questions. One more from the IDEO of community. At the core of lean startup and startup way, the build-measure loop has evolved into creative learning organization. A lot of people were asking us questions, as we prepped for this, about how do you know it's the right thing to learn? How do you know that you have good learning? So I'm wondering what some of the things are there.
Eric Reis 29:14
Yeah, learning. I don't know if it was the right word to use because it's a very loaded for a lot of people when you say we're going to learn something people get nervous about it: "is this gonna be some academic exercise?" It's a very common excuse if you didn't perform. Right? Like when you're scraping the bottom of the barrel of excuses for why you didn't deliver, you're like, "but it was, it was a great learning experience." In a lot of corporate settings, especially, that's kind of a bad word to use, because learning implies failure by definition, always. But I chose it intentionally. I think it's important to reclaim learning and give it a more rigorous definition. In Lean Startup, I call it validated or scientific learning. Because imagine I was in my scientific lab, and I was like, "guess what, I've been playing with my chemistry set, and I just invented the elixir of immortality." And you're like, "wow! You have any proof?" I was like, "no. I learned how to make the elixir, but I can't tell you about what I learned. I can't prove it to you." You'd be like, "that's not learning. That's BS. That's not learning. You can't you can't just claim that you did something. What's the proof?" Now if I'm like, "well, listen, I had one cohort of, you know, lab mice that, or like fruit flies. and didn't give them the elixir and they lived, you know, x days. But then I gave them my elixir, v1, and they live for 10 days. And with elixir v2 they live for 15 days." There's a very obvious and clear way, in a scientific context, you demonstrate that you have achieved some kind of cause and effect.
Suzanne Gibbs Howard 30:33
There's proven data, evidence.
Eric Reis 30:35
And we've been working on the scientific method for like, what, two or three hundred years, depening on how you count, And there's well established forms for how it works. And the fact that it had to be invented means that it's not intuitive. So it's hard. The scientific method is not easy. I occasionally get people complaining that if entrepreneurship... They criticize Lean Startup as trying to turn entrepreneurship into a science, but if entrepreneurship was a science, then everybody could do it. Therefore, that's no good. And I'm like, "dude, science is a science and very few people are good at it." It's freakin' hard. So yeah, this is not easy, but it is clear. We understand what it is. So we have to apply that same rigor to what we claim to have learned. So a very common situation, with a with a minimum viable product. Think about that Series X engine even. You know, the plan, the leap of faith assumption says, "customers with these attributes are going to want to buy this product." So before we even build it, it's not like you walk into or Walmart and say, "hey, give me a diesel reciprocating platform." This product is bought through a sales process. What's the first artifact people encounter in the sales process? It's not the engine itself. They encounter a brochure, a promise. So you take the promise to someone and say, "hey, would you like to buy this?" And they say, "get the hell out of my office. No, of course I don't want to buy that, that's terrible." Now, have you learned something yet? I would say, "not quite yet." You've got the possibility that you're on the right track. Well, let's take it to a second customer. Second customer says the same thing. Third customer says the same thing. Okay, well, maybe we've learned this isn't quite right, but that's not the kind of learning we're talking about - learning that you're wrong is not what we want, we want to learn the solution to the problem. So, then you pivot. So okay, the first brochure promisedthis level of performance, this price point, these features. Let's try something different. Take that to 10 customers and 1 out of 10 says, "I'm interested." Then you do it again, now 3 out of 10 customers. Now you're starting to say, "with each iteration of the product, we seem to be getting a better response from customers." That's proof that something is changing from version to version from cohort to cohort. So, it's very important that we not only ask people, "what did you learn?", but we also ask them, "how do you know -what is the evidence that supports that?" And we have to train people in these more rigorous ways of thinking no matter what function they're in.
Suzanne Gibbs Howard 32:41
One of the things that I love in the way you talk about learning loops and measurement, is that you're forcing the pace in a lot of things. You're saying, "don't let a week or two weeks or a month go by without going out and having an opportunity to gather more data, gather more evidence. Because I think that's one of the things that people can always lean back, cool their heels - "oh, we're not quite ready."
Eric Reis 33:02
No one's ever ready.
Suzanne Gibbs Howard 33:03
And so how do you force the pace to share things and start looking at that data over time?
Eric Reis 33:09
In the in the book, I say that accountability is the foundation of management. Ultimately, what matters is leadership holding people accountable for pace and speed. If you don't do that, then you always get delay is delay is the most rational thing in the world. Because, you know, especially if you operate under entitlement funding. If you delay, you're still going to be funded.
Suzanne Gibbs Howard 33:29
So where's the pressure?
Eric Reis 33:30
Where's the pressure? In fact, it's actually counterproductive to ship. I know a lot of teams that sit there on a Friday and they're like, "okay, we're ready to ship on Monday, or should we delay two weeks?" Let's You should always delay because there's four possible outcomes: ship or don't ship times it's a success or it's not a success. So, if you ship and it's a success, what will happen to your budget? It will continue. If you ship and it fails, your budget could be cancelled. If you delay, there's two possibilities. You either had a good reason or didn't have a good reason. Just kidding! You always have a good reason there's an infinite number of good reasons to delay. So, you always come up with a reason. And then what will happen to your budget if you delay for good reason? In most organizations, nothing. So logically speaking, you should always delay to improve your chances of your one big swing being successful. If you build your company that way, not only do you wind up, wasting a lot of money - goal is delay. But people eventually realized, wait a minute, "if I'm audacious enough, I can play this game over and over again, and get promoted out of this job before we ever ship anything. And then whatever happens is the next guys fall." So you wind up with all these middle managers running on these organizations that have never shipped anything in their life, but have gotten amazing reviews. And that's really toxic to building a creative and design-oriented culture.
Suzanne Gibbs Howard 34:40
I'm gonna start pulling in some of the questions we can see. I can see tons of questions are forming around, "how do you get this started inside of a larger organization?" So from Kim: what are the conditions for readiness on innovation occurring that will lead to impact? From Andreas: what are the first organizational habits that need to be broken? So, when you're getting things started in an organization, how do you pick like the project where to start?
Eric Reis 35:05
It's hard. You can't be picky at first. To me, the entrepreneurs mantra is three things: think big, start small scale fast. That's it. So think big. You have to have in mind an organizational transformation that you think could work. But just like we did at GE, start small - one project, four projects, five - a small number of pilot programs, and do those projects right. Don't do it halfway. Because if you do it halfway, and it doesn't succeed, half the people will say it's because we did this at all, and half the people because we didn't do it all the way. So, do the first projects all the way. And then always have a built in scalability plan. So, my general rule is double every time when in doubt. When we do this at GE, we had one project, we had four projects, and then we started to do four projects at a time, you know, every couple of months and then we would do eight projects at a time. Just scale it up, but have a plan to scale it with pace. In terms of choosing the projects, at the beginning, beggars can't be choosers We would take anything, where just like, "send us you're tired, you're hungry, you're poor. We'll take whatever." And the truth is, that's actually a great strategy because you want low expectations. I love getting the orphan project that's like stuck between two divisions and can never get funded. And everyone's like, "this project is a bunch of losers." And then you whip it into shape real fast, discover that the people are perfectly talented, it's the organization that's the problem. And then you seem like you did magic. So I like the unassuming, decrepid projects from the dregs of the organization, no problem. As you build the transformation, you can start to get more rigorous about portfolio building, about project selection. I mentioned, that at some point for the GE projects we made the project team bring their executive sponsor to the workshop, and they would learn about Fast Works.
Suzanne Gibbs Howard 36:38
Right from the get-go.
Eric Reis 36:39
That was a prerequisite. We couldn't have imposed that rule at the beginning because then no one would have showed up. We added rules as we went. In the initial cohort of the project, there was no dedicated founder, CEO, leader of the team. You can't get anything done without a dedicated leader, but we did. So we didn't make that a requirement until we built up some political capital.
Suzanne Gibbs Howard 37:04
In the beginning, you're pulling whatever you can find. Start well and finish well.
Eric Reis 37:10
We always made sure that teams had proper coaching, had executive air cover. We really set it up so that they could succeed. And we put them under a lot of pressure. The initial Fast Works projects had four months to demonstrate success, and they had to, they had to pitch their plan to very senior executives at the beginning, and they had to demonstrate their progress to senior executives. So with a high stakes high pressure there, and that allowed us to then say, "look, because you're being held to a high standard ask for what you really need." And that's when we uncovered all these organizational mistakes. You know, it was hard to get teams allocated or structured properly; all this political nonsense we uncovered. We had to get people to learn to speak openly about these things, which were a little bit countercultural, and like a little bit embarrassing to admit.
Suzanne Gibbs Howard 37:58
But someone is also asking, Roman is asking, when you talked about the Series X project, and there was the fantasy plan that you worked backwards from and deconstructed, is that an approach that you often use? Is that a natural way where people do what you usually do, come in with the typical plan, you would break it?
Eric Reis 38:16
I actually really like to work that way. I feel like I'm the last person in startup land who's pro business plan. I'm just saying, like, not the fiction writing part of it. We can scrap the word document and the diagram of the beautiful pictures. Just give me the Excel spreadsheet. Show me how individual customer behaviors add up to a highly scalable business. And from there, you can easily identify the leap of faith assumptions. Because imagine I have a spreadsheet, from pick your favorite business plan you've ever read, and of course, it was in appendix B in 2 point font. So I gotta have my magnifying glass. Once I got my magnifying glass out, I pull out your spreadsheet, print it out, zoom in, I'm going to find some box somewhere that's going to say 10%. Like, "whoa, what is this 10%?" It says percentage of customers who sign up, who become paying customers after the free trial. "That's an interesting number." Is that something that should be in 2 point font in Appendix B, or should that be in like 100 point font, blinking red, "leap-of-faith assumption" on my wall? Well, I know it's the latter. Why? What happens to your beautiful spreadsheet if I change that 10 to a zero? It's like a nuclear bomb. You see the zeros cascading out, the whole spreadsheet turns to zero, because if nobody will sign up, it really doesn't matter what the average lifetime value is, it doesn't matter the growth. Nothing matters because nobody wants to buy our product. So we have a fundamental problem.
Suzanne Gibbs Howard 39:26
So how do you peruse a business to identify which ones are the leap of faith?
Eric Reis 39:30
Yeah, there's a whole technical aspect of this called innovation accounting, which we're obviously not going to get into too much detail here unless people genuinely want to talk.
Suzanne Gibbs Howard 39:39
It's one of my favorite parts of the book.
Suzanne Gibbs Howard 39:40
It's a really good one. Talk a little bit more about that.
Eric Reis 39:40
Okay. Well, I don't hear that very often.
Eric Reis 39:44
Yeah, happy to talk about it. But basically, just like you didn't learn cost accounting from some guy on a webinar in five minutes, if you want to study this, you got to learn the math. It's complicated, but the idea is to deconstruct a business plan in a rigorous way to identify which of these metrics have high sensitivity to the final outcomes, and the way you do it is by looking at the inputs that drive the model, not the outputs. Even that Series X, ludicrous hockey stick that I was teasing them about a second ago, there's nothing wrong with a hockey stick. What is wrong is pretending that that hockey stick is a prediction about the future. It's not. It's a deductive consequence of a series of assumptions. Well, the assumptions are where the value is not the outputs. So in the chapter on innovation accounting, I try to show how the fantasy plan] actually describes the end zone of where we're trying to get to innovation. Accounting gives us a rigorous way to evaluate progress against that goal, even when the gross numbers are very small.
Suzanne Gibbs Howard 40:40
Mm hmm. And then what are the questions and metrics you need to look at in order to progress from backward from the real right now and implement closer to what that real might look like.
Eric Reis 40:51
Most teams that they run an experiment and nobody wants to buy it are like giving up. Like, "oh, this is bad. I better not tell anybody." But I would say finding out that we bad news that's true is a lot better than having good news that we made up. So you ran an experiment, nobody wanted it, that's a great place to start. Now we know that we're at zero, we're at the zero yard line, we know we need to get to the hundred yard line so let's march down the field and let's build, measure, learn our way to subsequent experiments and see that we're making progress. I think we can destigmatize that, so that it's not such a big deal.
Suzanne Gibbs Howard 41:20
Okay, I'm going to go to a speed round because there's so many questions.
Suzanne Gibbs Howard 41:23
Cynthia: silos and hierarchies, how to get around them?
Eric Reis 41:26
Just blow them up. Obviously, there's a lot more to it than that.
Eric Reis 41:31
Look, in the book I lay out the actual blueprint of how I think these silos and functions should work together. And so like there is some rigor to this but like, there's nothing sacred about these silos. They're not magical. They were not given to us by Moses on stone tablets, we can change them.
Suzanne Gibbs Howard 41:50
Another one from Andreas: many corporate corporate environments now have innovation departments. Is this good? How should the organization be educated?
Eric Reis 41:58
Yeah, so it's interesting you use to term Innovation department because that's not necessarily bad. But usually what I see is what I would call an innovation lab. So generally what happens is I go into a company and I ask the CEO, "who's in charge of innovation in this organization?" And they usually will tell me everybody is. And I'm like, "okay, but if this was a different function I was asking you about like marketing, would you accept that answer?" Do we need a chief marketing officer? No everyone's in charge of marketing. The hell are we talking about, we don't need a chief financial officer. We'll just make everyone in charge of finance, and we'll put up posters on the walls, "everybody think finance, good finance, thoughts", like we'll be in prison in no time. Of course you wouldn't do that! Now imagine I'm like, "hey, you know what we should have? A finance lab. Let's have the finance people go work in the finance lab, and then we'll outsource all the finances to them, and the rest of us could just pretend it doesn't..." Of course, that would never work. So why is innovation any different? I call it the missing function in the corporate org chart. I think we should treat entrepreneurship as a first class corporate discipline just as important as marketing, engineering, design, or supply chain and we should integrate it into the org chart in a very specific way, which I outline in the book.
Suzanne Gibbs Howard 43:04
Nice. Last thing. Where do you find entrepreneurs inside of a corporation?
Eric Reis 43:10
This is a great question! Nobody believes my tell them this, but organizations of any size, just by the law of large numbers and the normal distribution of talents, are loaded, absolutely loaded with entrepreneurs, you wouldn't believe it. I'll just tell you one last thing. One of my favorites. I was working on a project that came to one of my workshops that was a joint project between finance and IT to do what's called "corporate consolidation". This is like, one of the most boring projects you will ever hear about most, most creative people I end up telling about what corporate consolidation is, like, "ah, kill me now." Right? Like what? And it's like the worst functions, right? The most snarling, evil, like uncreative, you know whatever. And the project team that came to me was a 25 person committee, everybody on at 10% of their time. So this is like a nightmare project. Here was their plan. Here's the plan: they were going to spend, this committee, 18 months studying the problem and figuring out a new global standard for a new software finance product that would do the consolidation differently. They would then print that out into a binder, like we talked about before, hand it off to the CIOs of all the divisions and tell them to spend 18 months implementing this new standard. So 36 months from now we're going to have these amazing productivity improvement. Come on, we all know what's going to happen! These projects are like classic, you know, black holes, zombie projects don't deliver any value and who's going to be accountable for the screw up? Nobody. Because the CIOs are gonna say, "well, that was a bad spec" and the people who designed it are gonna be long gone. So this is a nightmare project. So we spent three days together after which the team reorganized into a five person cross functional team, and they went around to different PnLs and they say, "listen, we'd like to make you an offer, voluntary offer, I'm going to tell you what to do. If you say yes, our whole team will be on an airplane the next day to your corporate headquarters, wherever it is in the world, we will sit with you, the first version of the software will be stood up in 30 days and every quarter we will voluntarily give you the chance to switch to the new software if you want to. And we will not leave until we have proven that we can improve productivity for your PnL. And after which will do it for a second and then a fourth, right, lthen we'll scale up at a faster rate and refactor the differences." And the people that they made that offer to call me up and were just like, "what did you do? Was there something in the water?" We did the workshop in San Francisco, so they're like, "is there something funky in San Francisco? Some kind of pharmacological or spiritual miracle?" I'm like, "there's no miracle." These are the same boring people that worked here before, but finally, finally, finally, given the opportunity to act in an entrepreneurial way. And this is the part nobody believes, but I was there. I saw this with my own eyes. The intensity, the creativity and the passion of these 5 IT finance dudes was every bit as entrepreneurial as anyone you would meet San Francisco. They were the real deal, even though if you looked at their resume and the way they were dressed, you know, you would never in a million years have been like, "oh, there's an entrepreneur." So there are an insane number of these people in organizations that are just hidden in plain sight. In fact, I would go so far as to say that most organizations teach them that they have to hide the entrepreneurial side of themselves and leave it at home. Don't bring it to work. Because we want you to be a corporate drone and not think creatively. And companies swear that they don't want that, but if you look at the deep systems of the company, how they reward people, how they promote people, how they allocate resources, they do. So you say with your mouth, you tell people to be innovative, they hear with their ears, "you want me to be innovative", but they hear with their wallet, "you don't want me to be innovative," and guess who wins?
Suzanne Gibbs Howard 46:50
Yeah. Well, I think that is a excellent note to leave it on. I think that's one of the biggest things we have in common. We believe that anybody, anywhere, is capable of doing these more modern, entrepreneurial, creative ways of working. So, thank you for coming and thank you for sharing.
Eric Reis 47:04
Really, my pleasure. Thank you all so much.
Suzanne Gibbs Howard 47:07
We'll have more to talk about soon. Thanks, everybody.
Eric Reis 47:09
Looking forward to it. Thank you.
Suzanne Gibbs Howard 47:12
Thanks for listening to this episode of creative confidence from IDEO U. Stay up to date on our creative confidence conversations and send your questions for upcoming guests. Follow us on Twitter, Facebook or Instagram, and sign up for our IDEO U newsletter at Thanks for joining us.

Courses Starting Soon

Foundations In Design Thinking - IDEO U Certificate
Designing Strategy Course from IDEO U