I’m excited to present this interview I conducted with Eric Ries, the author of the Leanstartup. Eric’s background is in startups – having started a few himself, he wanted to find a way to reduce the risk inherent in startups. For him, a startup is a state of affairs where there is tremendous encertainty. He believes that the principles of Lean can help do that.
PS: We also interviewed Laura Busche who tells us about Lean Branding and Jeff Gothelf from whom we learned Lean UX.
Ries was influenced by the Toyota Production System and his book is filled with examples where the principles of Lean is applied to startups and entrepreneurial endevours. In order to suit the needs of entrepreneurs, he modified the basic problem solving approach from PDCA to Build-Measure-Learn, believing that this approach will better assist the entrepreneur reduce his or her risks and increases her chance of success.
In this interview – among other things – you’ll learn the following:
How Jeff Immelt, the CEO of GE, said that the Leanstartup will now become the “operating system” of GE.
How Leanstartup is applied outside of software development and in manufacturing.
How to identify “minimum” in Minimum Viable Product.
What’s the balance between doing it right versus the absolute minimum steps required, knowing you’ll have to fix it later.
And, how technical debt is different from financial debt and why some technical debt can actually be good.
Enjoy the interview and please read about Eric immediately after the transcript below. And also please enjoy other interviews in the Lean Leaders Series.
Transcript
Eric, first off, thanks for taking the time to speak with us. I just wanted to give you some context before we begin. I’ve been in the lean world for awhile. I started at Toyota and I’ve worked at Amazon and eBay. And I’ve done consulting for other companies and industries. And I have to tell you, man, in my years I haven’t seen so much excitement about lean as I do about the leanstartup movement. There’s lot of excitement around it. Even old timers like Art Smalley, Matt May, Michael Balle, Emiliani; they are all speaking really positively about it.
Eric: Thank you.
So nice work on that.
Eric: Thank you; and thank you for asking them about on the record. It’s been great. A lot of those guys I don’t know at all. I didn’t know what they thought of it, so it’s been really cool for me just to see all of that happening.
Yes, it’s been really neat to see their responses. They are very excited about it, and you know, in the words of Matt May, he said that the lean startup what he sees is really this true spirit of lean, where it’s not focused on tools…
Eric: Yes.
…but really on the principles, and they can be applied anywhere really, and so it’s been really cool.
Eric: Yes, it was very meaningful for me to hear that. That’s so much what we strive for in our lean startup movement and to hear that recognized by one of the old guard was really a treat, so thank you for making that happen.
You bet, awesome. Well let me jump to my questions. I want to begin by talking about FAST Works. There’s a lot of buzz around it, and I think it’s actually really, really cool. So GE has partnered with you to help them build FAST Works.
Eric: Yes.
So let me read a quote and get your reaction to it.
Eric: Okay.
This is from Mark Little, Head of GE Global Research. He said, “We’re looking at young Eric thinking how the hell is this software dude going to have anything to say to us, and yet his ideas were transformational. I went in completely skeptical about it, and I came away completely enthused.” So you pitched to the old guard; these guys are super seasoned. You pitched to GE’s CEO, Jeff Immelt. Were you freaking out?
Eric: Totally, yes, I was very nervous. And I didn’t know what this was going to become. My background isn’t software, as Mark said; it isn’t Silicon Valley. You know, I had written in my book that entrepreneurship is a kind of management, and that lean startup was a way to manage in the situations of high uncertainty that every kind of company faces, and I made this kind of relatively grandiose claim that it could be used by companies of any size, scale, industry sector, like all business authors do.
But I didn’t know whether people in those situations would actually take me seriously or not. You know, it was the deduction, it was a hypothesis that I was very confident in, but it’s one thing to be confident of it, you know, when you’re sitting down to write something. It’s quite another thing for people who are full-time practitioners whose job depends on delivering results to take it seriously.
And yes, the first time I presented to Jeff Immelt; I just told the story, it must have been to Business Week. They just did a profile about it. They were asking me the same question, was I nervous? And I said, the way you know I was nervous is I wore a suit, which in Silicon Valley you never do. But I’m being summoned to the legendary facility at GE at Crotonville.
The meeting was with Jeff and his, pretty much his top 200 managers in the world, so the most senior people in the entire company. And you know, I consulted with my wife and decided to wear a suit. Of course I show up in a suit. I’m not making this up. Jeff Immelt is making fun of me. My first interaction with him, and I was dressed more formally than he was. He wasn’t dressed nearly as formally as I was. And you know, he was teasing me, “What did you wear a suit for?” And what I got was that they’re expecting hoodie and jeans, you know, and something a little bit more flippant. So I don’t know if they took it as a sign of respect or what, but yes, I was quite nervous.
That’s awesome. Well I come from the world where you can’t dress too formally, so I think that’s awesome. Well how is Fastworks going now?
Eric: I think it’s been incredibly successful. I think certainly far beyond my expectations. And a lot of the most successful stories about it, you know, I feel like it’s not really my place to tell. As with all my clients, I want to respect their confidentiality, and that’s what gives them the safety to kind of have really candid conversations with me, so I try to follow their lead in what they say publicly.
But you know, if you look at the videos, like from the Lean Startup Conference last year, we had some people from GE there to present. (?) said that there has been a piece in Business Week, so there has been some public acknowledgement of the fact that this has had a tremendously positive impact on the company and to the point that Jeff Immelt said he wants this to be the new operating system going forward for how they do work, you know.
Wow!
Eric: For a company that has had so much experience with lean and obviously the very famous or infamous episode was Six Sigma, depending on your point of view. But one thing you can’t argue with those past episodes is that they were…….of course leaving out Workout, which is going to fall out of favor now, but was a very big deal in its day.
Yes.
Eric: One thing you can say about GE is that when they adopt a new methodology from the outside they really take it seriously; they really make it their own, and they deploy it full scale, you know. They don’t do things halfway. What I think most people don’t realize maybe about something like FAST Works is just how much work it is. It’s incredibly hard, you know, of course they bring in outside people like me, but the real work is done by the internal team. They have a full-time internal team that is driving this change inside the company. And I think what people don’t realize and should is that it’s not just for product development. We’ve done really cool things, you know, healthcare, super high-tech healthcare devices, deep sea drilling, energy, fracking. I’ve learned all about the deep, steep world of the industrial capitalism through my experience with GE; and their appliances, before they sold the division and did quite a few things with them. Lighting, you name it, they make it. We’ve done FAST Works projects on it.
But that’s only half the story. There is also the work to transform all the internal initiatives, so IT; new IT systems that are still done the old waterfall way. Changing those teams to work with the customer service mentality and really test and iterate, finance, legal, HR. They think about all the functions, the commercial functions of sales and marketing, I mean, it has been a company-wide effort.
And so it’s really engaging people all over the company. It seems like such a cliché like put up posters and say, oh, think like an entrepreneur and be more creative and whatever. I even feel silly talking about it, but the truth is we’ve had thousands of employees at the company who have felt free, I think, in some cases for the first time, to really do things in a different way, to really take the good ideas that were there before, but now actually have the freedom and opportunity to implement them. And so it’s been really an incredibly moving experience to be able to witness.
That’s awesome; nice job on that.
Eric: Thank you.
Now as you mentioned, you know, a lot of these folks are familiar with Deming and Plan-Do-Check-Act. I’m just curious, I guess, from a technical perspective, when you taught them build-measure-learn, I’m sure they were able to see some of the influence that PDCA had on your work. What were some of their reactions to that?
Eric: Yes, well Mark Little is a great example you know who we started with. He is a deeply technical person, and one of the first projects we did at GE was a very technical energy project that involved hardcore material science, hardcore engineering, hardcore supply chain and manufacturing. It was a significant, very expensive project in the context of the company.
When you have a bunch of engineers in the room, and a bunch of technical people in the room in addition to the corporate VPs and the other business big-wigs, one thing I’ve learned is you really can’t BS your way through it. You have to know what you’re talking about, and you have to be able to answer the questions that they have; namely, how does this relate to…and all kinds of things come out of their mouths. How does it relate to this concept from Six Sigma? How does it relate to the way we do supply chain, manufacturing, finance, and discovery? And to be fair, even the marketing and customer-research-type people, they have really hardcore specialty as well, and you have to really understand the connections between ideas.
And so I think that it’s a great strength for a company like GE that has that background in PDCA who understands lean. That’s a strength, and you can say, listen, this builds on a set of tools that you’re familiar with, but move them into a new domain that you’re not as familiar with, and let me draw you those connections. A manufacturing company or any company that really understands manufacturing, you know, you could say, you know, we all know that work in progress inventory is bad. We don’t want to have excess work in progress inventory, and our goal is to achieve single piece flow and to drive down buffers, and all those concepts will be familiar to people, and they’ll say great.
So now think of or visualize the hypotheses that we have about a new product, or any new initiative for that matter. Every untested hypothesis is a form of inventory.
That’s awesome.
Eric: And so if you work for two years, three years, four years; I was working with one project with five years of planning and research, and implementation before they were going to launch to customers. That means five years of massive numbers of hypotheses, just piling up. But unlike on the shop floor, the problem with intangible inventory is you don’t see it, so you don’t have that visceral feeling of this is incredibly wasteful. Where are we going to store all this inventory, all those very concrete and kind of easy to understand stories that traditional lean books are full of.
Here since you can’t see the inventory, part of the challenge is helping the company understand their own process well enough to be able to visualize what’s going on; so you can ask people who are familiar with the manufacturing metaphor to kind of do a leap of imagination, and say, look, here all these untested assumptions, all these unimplemented designs are my favorites.
People spend years designing something, but if it hasn’t yet been implemented, and they haven’t put it to the test of reality, then how do we know if the design is any good? All this inventory just piling up everywhere, and then it’s not enough to tell people that the way that they do things today is the problem. You have to, just like any lean transformation, you have to point the direction and say, we can take those same tools that you already know, you know, all the Kaizen tools, you know. Think about Kanban, and Encore, you name it, they have their analog in lean startup and we can apply that same expertise to this new domain where that will give you an advantage, if you’re willing to make the conceptual leap. And I think that’s what Mark is talking about.
I remember very well the first time he was in the audience, you know. We were working with one of his teams and he was very skeptical, and he asked very tough questions. That guy’s very smart. And you could see the light bulb go on when he’s like, “Okay, I’ve got it.” This is not just some random fad that some business person, you know, said oh hey, we should get on the bandwagon. There is some substance here. And let’s experiment to see if it will really work in our context.
And that’s the other thing I really admire about GE and a number of my clients. They are willing to do this. I would be very suspicious if someone called me in and said, you know, on day one we want to do this company wide. The CEO is going to make the official directive and we’re just going to say that everyone has to do it. We’re making everybody read your book, and of course, I’d be flattered.
I don’t think it would be effective because we haven’t actually run the experiment yet, to figure out does this work for this particular industry, for this particular business. How do we customize it; how do we use the right language to describe it? How do we connect it to the initiatives that people know and the systems that people understand? That was a lot of work that has to happen to kind of both prove, create the internal proof points, but also create that translation that makes…and that’s why we call it FAST Works. It is a special program indigenous to GE that is, you know, customized for their culture and environment.
Well it sounds like by you being able to build on a set of common beliefs that seemed to have built a lot of trust.
Eric: I think so. I mean, I come in for criticism not infrequently for calling it Lean Startup. That is not a very popular choice. As it has become more famous, you know, the criticism has more or less dried up. But every once in a while someone will say, you should have called it something different. And my response has always been the same. From the very first days when I was trying to explain this to the software people, many of them had never heard of Lean Manufacturing. The reason it’s called Lean Startup is for one and only one reason, which is that it actually does build on this conceptual machinery from the lean movement that was incredibly helpful in forming my own sense of how this was going to work.
And so, what I want is for people to be able to learn more. I think that’s kind of the obligation of anybody who’s trying to create a new set of ideas. You have to be able to give people a map that shows how your ideas connect to other ideas, and if they want to go deeper, you have to be able to point them the way. It just seems ludicrous for me to be like I came up with everything, it’s all brand new. If somebody wants to go and understand the Deming underpinnings of this whole thing, I feel like it’s my obligation to kind of give them the sign post that says, hey, that’s an important direction to take in.
Cool.
Eric: Yes, I feel like that was a very important choice, both for my own intellectual integrity, but it has had these very practical benefits as well.
No it makes a lot of sense. My colleague here, Ben, has a couple of questions for you.
Eric: Sure.
Ben: Hey, Eric, I’m a big fan. I stumbled across your book on my own, and I think I’ve gone through it three times.
Eric: Well, thank you.
Ben: ….just while road biking and stuff, and I love the examples you have, and just the concepts really motivate people to almost go into startup mode, which is pretty fun. But the question I have for you is, and I’m sure you’ve dealt with this; when you are working with a team of software engineers, and you get kind of split decisions where there is doing it quickly, and there is doing it right. The example I might give is you can hardcode the sequel statements in your code, or you can use something like sequel alchemy, or some object-oriented approach that’s maybe a standard approach. So how do you navigate something like that with a brand-new startup, and you have no product? How much rework are you willing to take to push a product out?
Eric: I appreciate getting a software question. After all this time lately in manufacturing, it’s fun to go back to it. I consider that my home. Yes, in hard coding the sequel statement; I’ve had that specific argument with people how many times in my career I can even count. It’s always tough. Everybody knows time, quality, money-pick two. I was taught that as a young engineer that the business people never seem to understand that you can’t have it all. And it was actually a revelation to me, because one of the things I loved about reading the original books I read about lean was to learn that that saying is not a law of nature. It is an artifact of a specific away of working. And if you change the system, you can change the trade-offs that are available to be able to get better ones. And the classic lean trade-off is that you really can’t trade quality for speed, because the defects slow you down. So even if you think you can make that trade, you really can’t.
The corresponding concept in the world of software, we talk about technical debt end.
Ben: Yes.
Eric: Those of your listeners or readers who are familiar with software will know all about technical debt. For those who are new to it, it’s a very simple concept that says, if you don’t do things the Right Way, and you have to imagine that capitalized R and that capitalized W, the Right Way, then what happens is over time the software gets more and more crufty, more and more difficult to change, and you have more and more bugs and problems, because you’ve been hacking and kind of kludging your way.
Picture, you know, the duct tape and the bailing wire and the whole thing. And so eventually you have to pay that debt back, so that’s why it’s an analogy to financial debt. It seems like if you borrow money, it’s like free money, I can spend a lot of money today. I can get a few extra features today, but over time if you keep borrowing money eventually interest payments are going to kill you. That’s the analogy of technical debt.
One of the big insights that I had in developing Lean Startup was something that really shocked me. Unlike financial debt, technical debt has some very strange properties. And there’s one property that is unique to the startup situation, which is that some technical debts never come due. Imagine how cool that would be, if you went to a bank and you borrowed $10,000 and you got a notice the next day that the bank has become insolvent and you never have to pay the $10,000 back. It’s your money; keep it. In the world of finance that very rarely happens.
But in the world of technical debt it happens all the time, and I’ll tell you why. Sometimes in a startup situation we build a feature that customers don’t want. And then the right thing to do is to throw it away. So if we’ve spent extra time building it the Right Way, capital R, capital W, that would have been wasted time, because it turned out we were going to throw the whole feature away.
Now that’s very strange. People are not used to taking that into account and there’s an assumption, a deep assumption in most engineering cultures is that you always know what the Right Way is, and that the thing you’re working on is always going to be valuable to customers, and therefore you never have to face this trade-off. But there’s an even worse strange thing about technical debt that is kind of unique to the startup situation. In some situations we don’t know what the Right Way is in advance. This one really bothered me.
So I’ll give you a story; I was once working in a startup, writing the software myself. I was the CTO, and it was very important to me that the software be high quality. And the way that we thought this software was going to go to market was to interoperate with 10 different third-party systems. I won’t go into the details, but we had to write an incredible amount of code to interoperate with these 10 different systems. This is before the days of clean, beautiful REST APIs and all kinds of nice interoperability standards. This was kludge and reverse engineering, and just a total nightmare to get all this code to integrate with the 10 systems.
But the payoff was that therefore we wouldn’t have to build the systems ourselves. We could leverage all this infrastructure that was out there already. And in order to do that we had to make a lot of very important architectural trade-offs, and I was very keen that things should be done the Right Way. So everything in our system was refactored so that which transport you were using to send messages, you know, it was platform independent. And there was all of this indirection and object-oriented code that allowed you to kind of swap different systems in and out. It was very elegant, very beautiful architecture if I do say so myself.
So if you’d asked me, you know, is there a lot of technical debt in this system? I would have said no. I mean, there were other assets of the systems that had technical debt in it, but this particular system I was very proud of, and it was a very core focus of us because we knew it was going to be critical to the company. High quality was very important, very good unit test coverage, you name it.
Well two or three pivots later it turns out that the business strategy of interoperating with the other systems was a mistake. And we had to throw all that code away, because it turned out there was no alternative to building the system ourselves. So I won’t get into the details, but suffice to say, instead of interoperating with somebody else’s system we were going to build our own full stack implementation of all the transport layers ourselves.
Ben: Wow!
Eric: You know, that was pretty painful, because I had all that interoperability code that got thrown away. So that’s an example of what I was talking about before, technical debt that never comes due. Whatever technical debt was in that system was removed by the fact that it was thrown away.
But now think about the architectural choices that we had made, the ones I was really proud of, having really thought through and done the Right Way; all this indirection, and objects. Once you don’t have to interoperate with more than one system, every ounce of that indirection, all that architecture went from optimal to suboptimal. And it actually introduced all this new technical debt that we didn’t know about. And in fact engineers who were hired into the company later thought that I was a complete idiot; because they’re like, why did you build this terrible architecture? You should have done it the right way. And I’m like, you don’t understand. It was the Right Way at that time, but the use case changed. They never believed me. They said, well if I had been here I would have been able to [inaudible 00:21:02] this. I was like, yes, I’m sure you’re right.
So in a startup the calculation around technical debt is complicated by these two factors. One, some technical debts never come due. And two, sometimes the Right Way becomes the wrong way. So there’s a very counter intuitive way to solve this problem. And I advocate for a system, you know, that is based in lean startup that I think really addresses this. It’s very controversial, and a lot of engineers just don’t want to do it. The article I wrote about it originally was called, Embrace Technical Debt which I thought that was going to get me lynched by my fellow engineers.
Here’s the idea. Technical debt is not bad. The question is what do you spend the technical debt on? In the traditional formulation you spend technical debt on features. Instead of doing the beautiful Right Way sequel and direction object-oriented thing that you were describing, we give hack a sequel statement, hardcode it and that saves us, you know, a little bit of time. We use that little bit of time to build an extra next feature. Now if you keep doing that that will eventually kill you, startup or no. But what if we spent the technical debt? What if we borrowed the money and invested it in a process and infrastructure so that we could go faster? And this goes back to the production system. What if we actually spent our own resources, instead of on more throughput, on quality improvement built into the systems that we create? So what if every code deployed had the equivalent of an end-on cord on it? And any kind of problems that are created are automatically reverted? We called that system the cluster immune system at my past company.
And we built in this system called continuous deployment, and it’s an investment to be able to deploy as quickly as we could. We could do a deployment in about 10 minutes. We could do it about 50 times a day on average. When I say a full deployment, I mean literally an engineer writes a piece of code, checks it in directly to the trunk; there are no branches. That piece of code is transferred directly to production and goes through an incredible battery of tests and automation to make sure that the system is fine afterwards, including the business metrics and everything that’s important to the company. And if anything goes wrong it’s automatically reverted.
So here is the idea. Instead of building more features, build better profit, better tools because if you’re able to respond more quickly to what the market needs, to change it in use case. If you’re able to change architectures quickly and easily, then that makes you more resilient to the accumulation of debt, to unexpected debts you didn’t know you were going to have to pay. And of course, it makes it less painful when you have to throw stuff out, because you didn’t spend so much time polishing it.
To just give you one more example of this system in operation, again, think back to time, quality, money, pick two, and then think with that lens through the story I’m about to tell you. In my last startup called In View, we had a period of incredibly rapid growth when we went from thousands of customers to millions over the course of only a few months. It was a very rapid S curve and the kind of growth most startups dream about. And our technical infrastructure at the start of that surge was very primitive. I’m talking about single master database, and effectively one server ran the whole site. At the end we had a very, very hardcore horizontally partitioned sharded. This is all pre-cloud computing, so pre-AWS. We had to build servers and physically stick them in a data center kind of thing. Anyway, a very cool architecture afterwards. And here’s how we got there.
We called it Just-In-Time Scalability. Every week our product was used peak usage on the weekends in those days, so on Sunday it would peak time and the site would be on the verge of falling over from a technical point of view, on Sunday. So we’d come in Monday morning; we had an operations team that would analyze what happened over the weekend. They would look at the components of the architecture that seemed like they were about to fall over, all the bottle necks and places that were approaching red zone. And we would make a plan. We would say, how much more capacity do we have to have added to this site to survive the coming weekend. And that’s not just adding servers. In a lot of cases we had to go in and refactor the code so that, like one of my favorite examples is the user’s table. Every site has this. It’s a critical table, that’s like, who has an account in the system. It’s like core, core, deep, deep, deep in a system. Most engineers are scared to death to touch the users table, because if you make a mistake there, you could have spooky actions in the distance. Any part of the site can fail as a result of touching that deep stuff. People were usually afraid of it. But we didn’t have fear, because we had all these tools and infrastructure to support us.
So we would go in and say, okay, this week it’s time to refactor the users tables so that it no longer resides on a single master database, but it is horizontally sharded across 20 databases. And we would build, implement, and test the new architecture on Monday, Tuesday, and Wednesday. Generally we would deploy it on Thursday, and that would give us Friday to kind of make sure that it seemed like it was working okay, and we’d go into the weekend. And we would do that every week for months, just in time, figuring out what needs to be refactored, and what we can leave the same.
And the architecture at the end was of course way better than it was at the start. It looked mostly like the architecture diagram we had set out at the beginning. We did have a vision for what we wanted the architecture to look like. But a lot of the details were different. If you had asked me at the start for a site with 50 million customers, which in those days was a lot I know, everything has been inflated as the web grows bigger, what percentage of the data can live on the central master versus what percentage has to be partitioned? I would have told you 90% of the tables need to be partitioned. But as it turned out, it was only more like 20%. It’s just a way of saying that you can’t always tell what’s going to be needed unless you studied the system itself.
It goes back to the old Toyota production system saying that every defect is a treasure. That used to drive me crazy. I hated that saying for so long. It seems like such a Zen crap, you know. I hate defects. You can never convince me that they’re a treasure, but I eventually learnt of course the deep truth that is there, which is that problems that you’re having with your system, and the system is defined as the combination of technical and human components together, the whole system is trying to teach you where it needs intervention, and that’s why root cause analysis and [inaudible 00:27:32] and all that stuff is so powerful.
So anyway, that’s a very long answer to a short and simple question, but I think it’s important, because there is no simple answer to those kinds of questions, and it’s why people spend so much time and energy trapped in these false dichotomies, having these stupid debates, and I wish I could have all those hours of my life back.
Ben: I appreciate the response though; it was great. And I have one more question for you. This one will be less technical, but I think a lot of your fans will appreciate this question, because they are in startup mode. Assume you’re doing a new startup right now, a software startup. You’re putting it on Amazon or something. And you need to decide which vertical to chase. You don’t have a product; there are lots of verticals available out there. How are you going to choose a vertical? Are you going to hit all of them, or are you going to hit a few? What would that process look like and what advice would you give to your readers on finding the right vertical?
Eric: Yes, actually this is not hypothetical for me. I am in fact building a startup and I am having this very debate as we speak. So I’m struggling through this myself, and it’s always hard. It’s actually very difficult to answer this question in the abstract. So the first answer is you have to look at the specifics of any given situation, because different products have different strategies that make more sense for them.
But in general, when we have a series of verticals that we could choose, there is a customer segment that we could target, I’m a big fan of targeting narrowly at the beginning. So the first question is should I target many segments or just one. It’s very easy, especially when people try to build a platform-type product, to build a product that’s kind of like 80% good for many, many different use cases. But it’s not really 100% good for any specific use case. Call it the platform disease. That’s a situation I know a lot of tech companies find themselves in. There is actually a whole section in the great book, Crossing the Chasm, just about this. It says hey by the way, if you’re building a platform product don’t make this mistake. You have to build a product that’s useful for somebody before it can be useful for everybody. So I’m a believer in narrow targeting rather than going for more broad applications, even if your eventual goal is to build a broad platform.
Okay, I’m going to target a segment, but how do I choose which one? And there are kind of two principles that are key. The first is we have to target an early adopter first. So when we think about a segment we have to think about how urgent is the problem that we’re solving for the segment? Is it like hair on fire, critically important, or is it kind of nice to have? We want to pick some place where it’s critically important, so there’s whole literature on early adopters, like in Crossing the Chasm. Steve Blank has a great chapter on early evangelists, he called them. And there are a lot of people who have written about this, so I won’t belabor that point. So let’s start with an early adopter.
And then the second criteria is how quickly can we learn from the segment? You know, say you have three or four different early adopter potential categories. How do you pick one to go target? And that is a little bit more difficult; that requires really understanding those customers to figure out who’s going to be willing to make a decision quickly? Who has a sales cycle that I can address in a short amount of time? Where are their distribution channels that I can access, you know, the classic in a consumer company, is there are certain segments you can only reach if you have premier distribution in a really high-end store. There are some segments you can just reach online with Google AdWords. All other things being equal, I’d choose Google AdWords. So those are two criteria. How important is this problem for the segment, and how quickly can we access them?
But there’s a metapoint that’s really important. Do not succumb to analysis paralysis here. Because my guess is those of you who are listening who are actually in this situation right now, your segmentation analysis that you’re doing right this second is wrong. I bet you it’s wrong. I bet you a year from now when you look back on what you used to think was segmentation, you’re going to laugh. And it can be wrong in multiple ways. One is, it’s very common to be wrong about who the early adopters are, like I’ve made this all the time. I say, okay, the segments are laid out this way. There are teenagers and adults, and I’m going to go off to the adults, oops, it’s the teenagers or vice versa. But it’s also possible for the type of segmentation you’re doing to just be the wrong conceptual framework. Like I was working on a product that we had segmented by age when it turned out that age was not relevant. We had 40-year olds and 17-year olds that were behaviorally almost indistinguishable. The age didn’t matter at all. What mattered was a certain typographic profile. So if you study marketing and segmentation and actually dive into the literature on that, there are many ways to segment. There are many ways to carve up a hole into many different verticals.
If your whole framework for carving things up is wrong, then you can’t possibly reason about segments correctly. So this is one of these situations where you need strong opinions loosely held. We call it a leap-of-faith assumption. You have to call it an assumption because you’re going to ask as if the assumption is true in order to find out what’s really going on. So I strongly recommend you give yourself a time limited window, and I’m talking like six weeks, where you say, we are going to act in the next six weeks as if this is the correct segmentation and this is our target segment. And we’ll reconvene on a designated date, six weeks or twelve, you pick the time horizon. On a certain day we will have a pivot or persevere meeting where we will ask ourselves, now that we’ve worked really hard to achieve this segmentation and serve this segment, do we feel like we’re on track. Does it seem like our analysis is holding up? And if the answer is yes, then we’ll keep going for another six weeks. And if the answer is no, maybe we’ll reconsider a new segmentation then.
But we don’t allow ourselves ever to operate with no target, no hypothesis, and no plan. It’s much better to relentlessly and ferociously pursue a plan, even if it turns out to be wrong, because that will help you figure out what the right plan is.
Ben: That’s awesome. Cool.
Hey Eric, this has been great. I’ve got one final question.
Eric: Sure.
The Lean Startup Conference is coming up in December. Can you tell us a little bit about it and why everyone who hears this podcast or is reading this transcript should attend?
Eric: Oh, that’s very kind. Yes, we are having our premier conference; we do it every year. It’s here in San Francisco the week of December 8th. For those who are trying to make a trip out of it, or are coming from long distances, we have a whole week’s worth of programming you can attend. For those who are a little bit more local and maybe that’s not the right thing, you know, the main conference is on two days. I think it’s on the Tuesday and the Wednesday this year.
And I feel like this is a one-of-a-kind startup conference. It’s different than every other one that exists. There is no press. There are no launches, no hype. This is not a conference for rah, rah, pound your chest, launch your product, make a bunch of claims about things. It’s a conference that is by entrepreneurs for entrepreneurs. So it’s 100% focused on learning and learning not through lecture and theory, but rather through case studies. So the vast majority of our speakers are practitioners who you probably are not going to hear from at any other conference. They are not professional speakers on the circuit doing motivational speeches. We work really hard all year long to identify entrepreneurs who you may not have ever heard of, but who have a very interesting story to tell and can talk about not how I made money 10 years ago, like a lot of entrepreneurs who speak, not what worked for me in the 80s, 90s. It’s here’s what I’m working on and struggling with right now, or very recently.
So while we do have some big names, and you can check our website leanstartup.co, you can see all the big name folks who will be there. Of course, we have workshops and in-depth programming as well. I think what makes this really unique is that we have a truly diverse range of voices who are talking honestly and candidly about what entrepreneurship is really like and yes, the week of December 8th.
I think one other thing to note is it’s probably the only conference where we have both garage entrepreneurs, venture backs like Silicon Valley style entrepreneurs and corporate entrepreneurs from big companies all in the same room at the same time. You know, we take an expansive view of what entrepreneurship is; people who are dealing with situations of high uncertainty, trying to create something new. And we don’t discriminate based on who pays your bills, and what kind of health insurance you have. So anyway, that’s the Lean Startup Conference. I hope folks will join.
Awesome. Hey, again, thank you so much. This has been really helpful and instructive. We’ve learned a lot, learned a ton from you. So thank you so much.
Eric: I appreciate it. And these were great questions, and it’s really a pleasure.
About Eric Ries
Eric Ries is the creator of the Lean Startup methodology and the author of the popular entrepreneurship blog Startup Lessons Learned. He previously co-founded and served as Chief Technology Officer of IMVU. In 2007, BusinessWeek named Ries one of the Best Young Entrepreneurs of Tech and in 2009 he was honored with a TechFellow award in the category of Engineering Leadership. He serves on the advisory board of a number of technology startups, and has worked as a consultant to a number of startups, companies, and venture capital firms. In 2010, he became an Entrepreneur-in-Residence at Harvard Business School.
He is the co-author of several books including The Black Art of Java Game Programming (Waite Group Press, 1996). While an undergraduate at Yale Unviersity, he co-founded Catalyst Recruiting. Although Catalyst folded with the dot-com crash, Ries continued his entrepreneurial career as a Senior Software Engineer at There.com, leading efforts in agile software development and user-generated content.
Other Interviews You Might Enjoy:
Lean Leadership Interviews
Jeffrey Liker, NYT Best Selling Author, Professor, and Author of the Toyota Way
Jeffrey Liker, author of The Toyota Way, shares his thoughts on Toyota Kata, why sometimes root cause analysis isn't necessary, and what else he is excited to learn - even after 30 years of being a student of the Toyota Production System.
Eric Ries, Author of the Leanstartup
In this Podcast interview with Eric Ries, the author of The Leanstartup, we learn about the how he's applied Lean principles to starting companies. He also tells us about his consulting work with GE and how GE, worldwide, has applied Leanstartup throughout all its divisions and is considering Leanstartup as its new Operating System for the company.
Michael Balle, Author and Respected Lean Thinker
Michael Balle is a leading voice in Lean. In this interview, he shares with us his thoughts on Lean, tells us about his book, and spends a good amount of time discussing Respect for People.
Bob Emiliani, Author and Professor of Management
This interview with Dr. Bob Emiliani covers several aspects of Fake Lean versus Real Lean. There are real insights here from the "Lean Professor".
Laura Busche, Author of Lean Branding
Lean Branding is an application of Lean principles to branding. Read her provocative and practical approach to brand branding using the principles of Lean.
Robert Martichenko is the Founder and CEO of LeanCor - a lean logistics and supply chain company. He is also the author of the book "A Lean Fulfillment Stream", published by the Lean Enterprise Institute. In this interview, he shares with us how Lean can be applied effectively beyond the 4 walls of manufacturing and outside the office, but infused into the entire supply chain.
Peter Armstrong, CEO of Leanpub (Lean Publishing)
Leanpub is an innovative approach to book publishing, where Peter believes that lean principles apply. He claims that writing a book is essentially a startup. And, the worst waste of all is writing a book that nobody wants. Read more to learn how to apply lean to the world of book publishing.
Keith Sparkjoy, Chief Culture Officer at Pluralsight
Keith Sparkjoy is the Culture Officer at Pluralsight, a Utah company that raised $135 Million in 2014 - an unprecedented amount of venture capital. And, here's the really cool part, as the culture officer, he's trying to transform his company using Dr. W. Edward Deming's teachings.
David J. Anderson, Author of many books on Agile, and inventor of Kanban for Creative and Knowledge work
David J. Anderson is the pioneer of the application of Kanban for creative knowledge work. His methodology and approach has had widespread acceptance and adoption and in this interview he shares results from companies that have tried his approach and other lessons learned.
Dimitar Karaivanov, CEO of Kanbanize
Dimitar Karaivanov is the CEO of Kanbanize, a visual kanban system designed for creative and knowledge workers. In this interview, we discuss the product and its many uses and how it embodies the principles of Lean.
Chris Hefley, CEO LeanKit
Chris Hefley is the CEO of LeanKit, a company that provides Virtual Kanban software for software development teams and knowledge workers. Reah his interview and learn what led to the development of LeanKit and the role Lean and the Toyota Production System plays.
Dan Markovitz, Noted consultant and expert on Lean for Office
In this interview with Dan Markovitz, we learn why he believes that everything is connected to the customer through the office. Based on this belief, he feels that Lean for Office makes the most sense. Read and learn how he's implemented Lean for the Office.
Jason Yip, Consultant to software development organzations
Jason Yip is a noted thoughtleader in software engineering. As a consultant, he helps software engineering organizations get better. In this interview, we learn the state of software engineering and the role of Agile, Lean for Software and Kanban.
Matthew May, NYT Best Selling author, consultant, and expert on Toyota Production System
Matthew May is an author and influential voice in Lean and also Design Thinking. He worked close to a decade at University of Toyota to help codify the Toyota Production System. In this interview, he shares with us his thoughts on his experience and what we can learn from it.
Mark Graban, Best Selling Author and expert on Lean for Healthcare
Lean Healthcare expert Mark Graban stops by and share his thoughts with Shmula readers on how Lean can be applied to arguably the most important industry in the world, healthcare.
Art Smalley, 15 Year Toyota Veteran and authority on Toyota Production System
Art Smalley is one of the most honest and influential voices in Lean. He was the first American to work in Japan's Kamigo plant, the plant where Taiichi Ohno began the Toyota Production System. He shares with us his thoughts on the Lean Movement and where it is going wrong.
Jeff Gothelf, Author of Lean UX, applying Lean for User Experience
Lean is being applied to every facet of business. Jeff Gothelf shares with us his thoughts on applying Lean for user experience, or Lean UX.
Cecil Dijoux, Expert Consultant on applying Lean for IT
Cecil Dijoux shares with us his thoughts on applying Lean to IT, definitely a must-read if you are in the information technology space.
Brent Wahba, Author and Expert on applying Lean for Sales and Marketing
Brent Wahba is a fellow at the Lean Enterprise Institute and shares with us his thoughts on Lean for Sales and Marketing.
Interview with Tony Hsieh, CEO of Zappos
Tony Hsieh, CEO of Zappos
In December 2008, I was fortunate enough to interview Tony Hsieh, CEO of Zappos. In a 5 part series of interviews, we discuss the Zappos strategy and Tony answers questions on why he chooses to focus on the customer and how he sees that as strategic.
Interview Questions from shmula.com blog readers
Tony Hsieh, CEO of Zappos, Part 1
Tony Hsieh, CEO of Zappos, Part 2
Tony Hsieh, CEO of Zappos, Part 3
<a title="tony hsieh interview, part 4"