Nathan: Hello and welcome to another episode of the Foundr Podcast. My name is Nathan Chan and I am the host of this podcast and also the CEO of Foundr Magazine. I’m coming to you live from hometown sunny Melbourne, Australia. We’re getting really good weather at the moment and it’s great. We’ve got the tennis here, we’ve got the Australian Open. I’m hoping I can go tomorrow, Friday afternoon, which is going to be great. It’s going to be, like, pretty hot, but looking forward to catching up with some friends, having a few drinks, and, yeah, watching the tennis and having some fun.

So I hope you guys are having a great day wherever you are around the world, having a great start to your 2018. I’m really excited, we’ve got a lot of strategy in place that’s very, very focused this year for us at Foundr and working some game-changing stuff. And I can’t stress this enough, you guys might, you might not know this, but we’re going to…the next couple of years we’re going to produce, you know, eventually 100-plus courses getting, you know, these people that we have on this podcast to teach courses on their, like, expertise. It’s going to be absolutely incredible, I envision a 10X platform that is better than anything else that’s out there in the marketplace, purely focused around entrepreneurship and start-up education.

So that’s what we’re working on. And if you weren’t aware, we’ve just launched one of our…it is our second course for that platform and it’s by Ari Meisel. And his name you may not know of, but he’s an absolutely incredible founder. The course is called Productivity machine, I highly recommend you check it out if you want to be more productive. And just, you know, set up your year in a really, really good way for 2018. Just go to productivitymachine.co, productivitymachine.co. And make sure you check it out, we’ve just opened that one up and I know you guys are going to love it.

So let’s talk about today’s guest. Things are going well on my side, I can’t complain. I hope things are going well for you, but let’s talk about today’s guest, Eric Ries. Now this guy, this guy changed my life in regards to thinking about the way to produce products, how to find a really solid business model for your start-up. And he’s quite the pioneer, and he pioneered the Lean Startup movement. You may or may not have heard of this movement or this framework and methodology before, but, trust me, it’s game-changing. If you haven’t got or read the book The Lean Startup, please make sure you do. We use this methodology in everything that we do at Foundr around how we build, launch product, and really have worked out to seek out what our business model looks like and how we’re building this thing. And I’ve been wanting to speak to Eric for years and we finally have spoken to him and we talk about his latest book called The Startup Way.

But anyways, guys, I’m not going to ramble anymore. I hope you’re enjoying these episodes. If you are, please do take the time to leave us a review on Spotify, iTunes, Stitcher, SoundCloud, you name it. It helps us more than you can imagine. And, also, please do share this with your friends. I know that you must have some other founders that you’re friends with, or business owners or entrepreneurs, please do share this, spread the word. I am on a mission with Foundr and our whole team, everything we do, we obsess about building a household name, entrepreneurial brand, helping tens of millions of people on a weekly basis. We’re not there yet, I’m on a five to seven-year journey to get there. I’d love your help, please do share this.

All right, guys, that’s it from me. Now let’s jump into the show.

The first question I ask everyone that we speak to is how did you get your job?

Eric: Well, which job do you mean?

Nathan: I guess the work that you’re finding yourself doing, the work that you’re doing today. How did you end up deciding that?

Eric: So I was a tech entrepreneur, you know, of the very classic sort. Grew up in my parents’ basement programming computers, the whole thing. And I had a bunch of start-up failures, and then some success. And it was really through that that I started writing about entrepreneurship and eventually called the theory I was promoting the Lean Startup, and then that turned into a movement and took over my life. So I don’t know if you would call that job.

Nathan: Awesome. Look, the book Lean Startup, one of my mentors gave it to me literally five, six years ago around just the time I started doing what I’m doing today and it was just such a life-changing book. And we use the Lean Startup methodology to launch so many different products, do so many tests for things that we’re working on, and it’s just such a game-changing book. So very big fan, but I’m really keen to understand about, you know, you said that you… Just a little bit of a background just for the audience that might not be familiar with your work. Would you be able to give us a little bit of a background on the start-ups you were working on beforehand? I’m really curious on that front. Because you mention them in the book, but was it one, was it two?

Eric: Yeah, it was just a couple. I was in a virtual reality space, you know, before it was cool. And so, yeah, I built a couple of products that involved 3D avatars in virtual worlds, micro-currency also being in that kind of area. So all trends that have turned out to be quite big since, but we were a little early. And in entrepreneurship being early is pretty much the same as being dead. So it was challenging. The company that had the most success from that time is called IMVU, I-M-V-U. It’s still going, still a profitable company in Mountain View in California, but not a, you know, Facebook..

Nathan: I see.

Eric: But still quite proud of it.

Nathan: Yes. And did you exit that company and that’s how you started writing?

Eric: Yeah. I mean I had been there about five years and I had always sworn to myself that I was not going to be one of those founders that has to get kicked out because they’re causing problems. And I just felt like it was time for me to move on. So the company is still an independent, private, profitable company, but it has not exited in Silicon Valley parlance yet.

Nathan: Got you. Okay, interesting. And then how did, like, the idea and the framework and everything around the Lean Startup come about? And then we can move towards talking about your new book, which I’m really keen to talk about.

Eric: Sure, yeah. I mean, look, I had the privilege of having really terrific mentors and advisors who laid a lot of the groundwork for it. Most notably Steve Blank and his theory of Customer Development, which we put into practice at IMVU. But I was also a big devotee of agile software development and Kent Beck and Extreme Programming and that whole world. Through that became really knowledgeable about lean manufacturing and the kind of…all the different theories around…that involve time speed of iteration.

So I had immersed myself in those theories because I found them helpful in doing my work, but the biggest driver for me was that I kept having the experience over and over again that work should be done a different way than I was being taught. So I always pushing the company that I was in to go faster, to be more iterative, to have customers be more involved, to be more scientific in their decision-making. And everyone thought I was crazy, I kept…I would always get so much pushback left and right for these ideas.

And so at a certain point when I started to have success with those ideas and, you know, it was kind of my turn to put them to the test and they started to work, then people would give me a hard time about why they work. And I would be like, “Well, just look at the evidence with your eyes.” And of course nobody wants to look at the evidence, they want to understand the story of what’s really going on. And so I felt like in order to explain myself I had to kind of develop a theory that could explain my own experience, and that’s ultimately what Lean Startups was born out of.

Nathan: I see. And did you think it would be this massive movement and, you know…

Eric: Oh, of course not.

Nathan: No?

Eric: Of course not. No, I didn’t have the slightest inkling of it. The first time someone asked me for permission to start a Lean Startup meetup group I said, “Well, first of all, you don’t need my permission, just go ahead. And, second of all, it sounds like a terrible idea, I really don’t think that’s a good use of your time, you really should do something else.” And they said to me, “No, no, I think it could be good.” And they said, “Well, if”… I said, “That’s fine, but probably nobody will come to the meetup, so it will be really a waste of time.” And he said to me, “If people come, will you come speak to the first one?” And at the time it seemed, like, really easy to promise, “Sure, yeah, of course I will. Since I don’t think anyone is going to come.”

Well, of course a lot of people came and that was the first of many, many, many such groups that were created. And the whole thing took me very much by surprise. I mean I certainly…I appreciated the work that people did in building up the movement, and I certainly did what I could to encourage and inspire, collaborate, you know, as much as possible. But it was not my idea and it was not…I was not the source of energy behind it.

Nathan: Interesting. So let’s talk about your latest book The Startup Way. I’m really curious what compelled you to write this book? And then also I’ve got a ton of questions because it feels fitting for me why you started this book, but I’m curious to hear your story. Because, yeah, I mean I’m probably… Yeah, it’s a really relevant book to me now.

Eric: So just like with Lean Startup, there’s a point at which when you are doing something new and you have a certain intuition about how it should be done and you do it. It’s really interesting the first time, and even the second time and the third time and the fourth time. At a certain point you start to feel like, “Wait a minute, if I’m explaining the same things over and over again, it may be more efficient to use some kind of one-to-many transmission mechanism to share instead of, you know, one company at a time, one founder at a time.”

So I was being asked more and more often to help people apply the Lean Startup framework in scale situations. First really, and especially, companies that had gotten past product/market fit and the founders wanted to know, “How come my innovative DNA, my start-up DNA seems to be evaporating and my organization is getting sluggish and lethargic, it’s not scale. You know, why is that and how can I prevent it?” And at the same time people from some traditional, older organizations, like, “How do I recapture that innovative spirit that we’ve already lost?”

And so I started to do that kind of work both with hyper-growth start-ups and also with established big companies, and even with some governments and, like, real bureaucracy. And I started to notice commonalities and patterns in all those situations. And, you know, it took me a while to kind of figure out the theory of how and why and what does it all mean. And once I had that sorted out in my own head, then the answers I was giving people were starting to seem kind of repetitive. You know, I was like, “Hey, maybe this could be I found a foundation for a new book.”

Nathan: I see. And I’m going to shoot just some random questions at you and just feel free to answer them as best you can. Because these are some things that I’m personally struggling with, so I’m going to be a little selfish. So when it comes to scaling a company and building teams, in particularly hiring, how do you know what is the next appropriate role to hire for?

Eric: This is a really hard question and, of course, there are a lot of context-sensitive variables. But I will say one rule of thumb that has always served me well is to look at the job that you’re doing yourself today that is either something you want to get more professional about or almost automate, you know, because you’re starting to do that over and over again, or where you’re really struggling and you need help. It’s really difficult to hire someone to do a job you’re not currently already doing.

So, you know, like, we talk about shedding load as a founder. Try and find the places where you have an area of responsibility that you can hand over to somebody else. Because the fact that you’re already struggling to do it means you know what the job requires and why it’s hard, so you’re more likely to hire somebody good and you’re more likely to be able to hold them accountable. Classic thing is a self-start-up that has like no customers and no external facing anything hiring a fancy VP of marketing to do marketing in the future. They haven’t done any marketing at all yet, they don’t even really know what they need or why it’s hard. And it’s really easy to get snowed by someone who can talk a big game but doesn’t do anything in those kinds of situations.

Nathan: That’s great advice. But what about if the role is technical and you don’t understand the technical elements, should you need to understand that?

Eric: Yeah. It’s very, very hard to hire a technical role if you don’t have at least some understanding of what the role requires. So, yeah, if you’re a non-technical person, hopefully you have a technical cofounder who’s going to help you sort that out. Hiring a technical cofounder is very difficult and figuring out… And if you don’t have a technical cofounder, hiring, you know, a technical employee is even more difficult. So I would get that technical expertise into the team, you know, pretty soon.

Nathan: Okay. And when it comes to, I guess, like when you’re saying to scale your company and build out your team, how do you know when it’s time to input managers or a manager or manager of one of the teams or a team?

Eric: I mean there’s really not much of a rule of thumb for that. You know, I mean the truth is in most start-ups the CEO manages everybody until they can’t handle any more direct reports, and then start to organize. But, yeah, I don’t think there’s like a one-size-fits-all answer for that, I think it’s pretty context-sensitive.

Nathan: Yeah, no, that’s okay. But, like, 15, 20, 30 direct reports?

Eric: Oh, no, no one can have that many. So, like, the rule of thumb I use is I try to have a weekly one-on-one with all my direct reports every week.

Nathan: Yes.

Eric: If I have too many direct reports that I can’t have all the one-on-ones, then I know I have too many.

Nathan: Yes. Got you. And when it comes to, like, at a start-up it’s really important, you talk about speed. That was something that, you know, I learned. It was massive, it was a massive game-changer for me around, you know, speed and within teams and agile. And I’m curious how do you know when you’re pushing your team too hard and you’re working them too much, how do you know that gauge, or you as a company is pushing too much and doing too much?

Eric: So any start-up we talk a lot about the build-measure-learn feedback loop, and what we’re trying to do is optimize time through the loop. People always talk about doing too much, going too fast, like, and they don’t define, like, what does “too much” mean, what does “too fast” mean. So, like, these concepts wind up being pretty vague. With Lean Startup we tried to be really specific about what we’re trying…what is the velocity that needs to be measured. And it’s, you know, speed of experimentation throughput through the feedback loop.

So in that circumstance it’s best to use techniques. Like in Lean Startup we talk a lot about five whys as an automatic speed regulator. Where, you know, you can’t really trade quality for time. So if you’re cutting corners to go faster, you wind up creating problems that slow you down. So a lot of the mechanical techniques that are drawn from lean manufacturing are design, things like kanban and the Andon Cord and all that stuff. They’re designed to help us find that optimal pace for the marathon that we’re on.

Nathan: Got you. I see. And when it comes to project management, do you recommend kanban?

Eric: Yes.

Nathan: Got you. And would you be able to just briefly tell our audience why using the kanban framework is really important for managing projects?

Eric: Sure. Most product teams that I meet literally do not know if the work they’re doing today is making the product better or worse. It sounds so ridiculous to say and yet it’s true. They just assume that the product owner knows what the customer wants. And as long as they do what the product owner wants, then everything will be fine. But we as consumers of products know this is not true because so many products, when you get an update, you just say, “Oh god, they made it worse again?” I’m sure we all have had that experience, we know certain teams that just, like, they keep redesigning something that’s not broken and they keep making it more confusing without making it better.

So the antidote to that is to try and bring some discipline of validation into everything that we do. And the easiest way to do that for a team that’s already using story cards or some kind of storyboard flow control for how they build their team. Like a classic scrum board will have three columns on it, one that says “here’s the backlog, here’s the work in progress, and here’s what we’ve done.” A class way to add Lean Startup thinking for that kind of a board is to add a fourth column called “validated.” So after a story is done technically we don’t remove it from the board until we show that we have approved it by hypothesis attached to that card has been confirmed or denied.

And what’s nice about that is it forces us to remember to place a hypothesis against every story choice and it really puts the weight on the product owner to think more scientifically, and it helps the product owner and the whole team get better. Because part of the problem is we think we know what customers want, but when we’re wrong we don’t always get that feedback. So this gets a nice feedback loop going.

The insight from kanban would be that the more cards you have in play in the system the less learning you’re going to do and the worse your throughput is going to be because humans are bad at multitasking. So what you ought to do is say, “If I have five people on my team, then we’re only allowed to have five cards in every bucket at most, including the backlog and the validated bucket.” So think of the columns now as fixed-size buckets. So you can’t add something to the backlog without removing something. And if the “validated” column fills up and you’re not taking those cards off fast enough, then you won’t be able to add more technical stuff to the “in progress” column because the whole pipeline will back up. And that’s what you want, that forces you to pay attention to where the bottlenecks are in your process.

A lot of people listening may be thinking, “That sounds way too complicated for my team.” And that’s fine. You know, this is…every technique is kind of…has a certain overhead attached to it and only makes sense for teams of a certain size and a certain sophistication. So we throw these examples out as examples to say, “Oh, this how you could do it at scale,” but, you know, not necessarily how everybody would do it every time. And, you know, a five-person team just starting out can probably avoid…if they’re serious about validation in other ways, they may not need to track it this formally. But a lot of others find this really helpful.

So I don’t mean to say everyone has to follow the exact procedure I just laid out, but just to say, I think, that’s, like, one that is really defensible from a principle point of view. This is how to optimize for the speed of learning.

Nathan: Yeah, I love that. I love that framework and I’m really interested. Because one thing that we find is we try and break up the cards, like, as simplified as possible so we can kind of run the board. But, so, we find that if we do…if we would limit it to, you know, five cards per column, what we would find is some cards would turn into absolute mammoth, epic beasts. So we’d have to put in checklists and stuff. So that’s what use to just break up the cards. What are your thoughts on that?

Eric: Yeah, yeah. Certainly the…like, there’s a basic assumption that teams are good at estimating, and so story cards are of comparable size. And you definitely should, as soon as you realize that a story is bigger than you thought, you should always split it into multiple cards. And good hypotheses can help a lot with that because what happens is these stories tend to get big when the goal is vague.

So by tightening up what the goal is, you can tend to keep the stories under control. But, yeah, you don’t want to let…you don’t want to let any behemoths. And I know teams that have had different rules that they…you know, that cards are not allowed to stick around for more than a certain amount of time. So I even know teams that, like, they practice continuous deployment, and so all code as to be checked in, like, at the end of the day. So if you find yourself in a situation where you’re trying to carry code over to the next day, that’s a sign that the card is too large. And they have different, you know, heuristics and rules and have tips for how to prevent that from happening and say, “Oh, let’s,” you know, “let’s actually stop now and break it up,” or, “Let’s get as much done as we can today, but then, like, do all the, like, library and refactoring and behind the scenes work and just chuck that in, get that integrated, and then we’re work on the feature tomorrow.”

So it helps, it really helps drive what we call a batch size of work down, which is a very desirable thing to do.

Nathan: That makes sense. So let’s switch gears. I’m quite interested. So you said that the premise of The Startup Way, the reason that compelled you to write this book was you were starting to work with other start-ups and you were noticing they were having problems scaling. Can you give me some examples or some things that you’ve come in and done or some tweaks that you’ve made, I guess, operationally or recommendations and you’ve seen just ridiculous results, or some examples of that?

Eric: Yeah, sure. So like one team I was talking to the founder had graduated from Y Combinator, but now they’re company… I mean at Y Combinator they had me and two cofounders, the three-person company at Y Combinator, now they have like 250 employees, doing quite well. And he was complaining to me about he had this team and they’re supposed to working on this brand new product to take them into a totally new industry for the future, and they don’t ship anything and they’re going slow. And they’re just…they’re not thinking about it like a founder. They had spent… I checked in with them after, like, six months and they had basically not shipped anything.

Nathan: Yeah, wow.

Eric: The whole time they were just giving him status updates that everything was fine. And it was only when he really dug in that what they thought “fine” meant was, like, having meetings and making design requirement documents and talking to all the middle managers in the company to get approval and buy-in for all the things that they were going to do in the future. And he was really frustrated.

And I remember asking him if he had given those same excuses to Paul Graham when he was in Y Combinator, what would have happened. And he’s like, “Oh, Paul would have taken my head off. I mean he would have humiliated me in front of the whole class, you know, kind of thing. He would take no crap about something like that.” And I was like, “Right. But he would also”… He’s like, “But, you know what,” because he was reflecting on it, he’s like, “I never would have even gotten to that point because I would have known that he would get mad at me and he would have taught me earlier in the process part of the lesson and, you know, culture of the place was weekly check-ins and every weekly dinner we’d be showing off what we shipped and there was a message about making things that people want.”

So he realized that he had been immersed in this training program, effectively, right? This culture and accountability system that he had not replicated for his own employees. So now that people work for him, they didn’t go through Y Combinator, they weren’t there when his company was a tiny, scrappy upstart, they don’t know about Paul Graham or whatever. Like, they don’t have those support systems. So he realized that he had to treat his internal entrepreneurs the way that he had been treated. He actually built an internal Y Combinator program complete with a demo day and everything.

Nathan: Wow.

Eric: For his internal entrepreneurs to start thinking in that new way.

Nathan: Interesting. And what happened?

Eric: Worked pretty great. I can’t say more without making it pretty obvious what company I’m talking about, so, you know, I’ve got to respect confidentiality with these conversation.

Nathan: Yeah.

Eric: But I ask you to take my word for it that it worked out well. But the interesting thing to me was just the variety of crazy stuff that his employees started coming up with and, like, the real passion and innovation that they brought to their work in this new structure that they really weren’t doing before. Even though it was the same people and they had always been really mission-aligned and they love working at the company, it has very high employee satisfaction, and yet there was all this creativity that they felt like they were being denied the chance to, you know, do.

Nathan: That’s interesting. So, yeah, that’s actually…I had just kind of naturally thought that as your company grows and grows and grows, it just kind of…that just that’s avoidable, that it kind of becomes a corporate kind of structure and way of movement. But you’re saying that you can always protect and keep that start-up mentality, that scrappiness, even when you build, you know, a 200-people-plus organization.

Eric: Yeah, that’s right. And listen, what you’ve heard and, you know, what people believe about the inevitable decay and bureaucratization, whatever the word is there, the ossifying of the corporate structure, like, that is, to be fair, the most common belief and the most common occurrence. But, you know, if you just look at something like Amazon where Jeff Bezos has built that thing into an innovation factory, it’s hard for us to say that we don’t know there’s a better way available. Like, we know that we can do this, we don’t always know how. So the book is kind of an attempt to close that gap and say, “Hey, there’s a method to this if you want to follow in those footsteps.”

Nathan: Yeah, amazing. And just last question, across the start-ups that you have been working with and have kind of taken a strong peak in operationally and seen the behind the scenes of what’s going on and what’s compelled you to write The Startup Way. The leaders, I’m really curious around the leaders. Any commonalities or anything you’d like to share with our audience just as a finishing piece just on leadership, the importance?

Eric: Yeah, sure.

Nathan: Yeah.

Eric: The vast majority of leaders that I meet to talk to about these issues are not interested in change. They say they’re interested, they say they want innovation, they want their company to have start-up DNA, they want the scarcity mindset and intensity and they say all the right things, but they don’t really mean it. And the way you can tell they don’t mean it is that they don’t change their personal behavior to hold their own teams accountable in a different way, they don’t themselves ask to be held accountable in a different way, and especially they don’t change the deep systems of the corporation. They don’t change how people are promoted, compensated, how projects are funded, how resources are allocated, that all stays conventional. And then we claim that we want change, we claim that we’re a meritocracy, but then we don’t build the systems required to eliminate bias and to allow good ideas to come from anyone. So I think as leaders we have to ask ourselves, “Are we serious about this or not? What probably do we really think we’re solving? And do we want to create a lasting change or do we want to be forgotten by the next generation?”

Nathan: Awesome, man. Okay, well, look, we have to work towards wrapping up, but, so, where’s the best people can find out more about The Startup Way and your work?

Eric: Best place is thestartupway.com, and I’ll just give your listeners a little tip. There’s a bunch of bonus material and diagrams and case studies and a bunch of goodies, including some pretty cool offers to get some free stuff. But, anyway, check it out. If you go to, like, enter…there’s a place on the website where you can redeem a code. Every copy of the book in the U.S. hardcover edition, if you go to the very last page, there’s a unique code stamp in the book you can redeem online. But even if you don’t have the book or you got the e-book or something, you could just put in your e-mail address, a bunch of stuff is available for everybody. So thestartupway.com and check for the place where you can redeem the code.

Nathan: Awesome. Awesome, yeah. Okay, well, fantastic. Well, look, I just wanted to say thank you so much for your time and just the work that you do, Eric, you’ve made a massive impact on the way that we built out Foundr and you’ve saved us a lot of headaches and things that we would have done if we had have had the mentality of build it and they will come. And, yeah, you’ve been an absolute life-changer for me.

Eric: Oh, thank you so much. Thank you.

Nathan: And our team and everything that we do. So I just wanted to say thank you so much for everything you do and the work you do.

Eric: Thank you for your kind words, I really appreciate it.

Nathan: You’re welcome. Well, look, I hope you have a fantastic day and thank you so much for your time, Eric.

Eric: All right, take care.