marketing, positioning. Changing the product definition or specification only happened at discrete arranged milestones. The assumption was that your colleagues in engineering are on rails with a train that’s going to leave the station at a certain time, and your job is to meet with them every quarter or twice a year to say “Either you guys are on track and keep going, or I’m going to lay down in front of the tracks and blow this up and say start over.” So there wasn’t this integrated company-wide thing. The idea that you need to get outside the building and talk to customers, that is very powerful stuff, and Steve gets all the credit for that.
X: All right. So, the next part of the history is where I’m a little fuzzy. You were still at IMVU. You’re taking this course. You’re trying to figure out how these ideas overlap. And so what happened then? How did you and Steve start working together more closely? How did your ideas evolve in response to each other? What happened with IMVU?
ER: The truth is that the class was only four months long. We had already been working on IMVU for six months. We went to this course once a week. It wasn’t like we were in a continuous college seminar with Steve refining our ideas. We had no idea how to apply this. If I had any criticism of customer development as it was being taught at that time, it was that it was wildly impractical. Will and I would go to class. We were in Palo Alto and the class was in Berkeley, so we’ve got a long trip to get there. We would be arguing about whatever our problem of the day was all the way there. We would take the class. And then we would argue all the way back about how to apply what we had just learned to our problem. And five minutes after leaving Steve’s class, we already couldn’t agree on what we had just learned. It was crazy.
We weren’t like, “We’re ready to sign up for customer development.” We weren’t theoretical. The class was very theoretical. We had practical problems. So Steve’s biggest influence on IMVU was not through his work but because he was our advisor, and he was eventually on our board. So the theoretical integration happened later. We back-port it to that time, because we can understand now how we were, in building this company, also testing out a lot of new ideas, but we never talked about that. I remember the meeting like yesterday, when I was sitting in the conference room with Mike Maples at Floodgate. Steve was there, and it was the first time I had the courage to say, “Guys, let me draw you this diagram of Build, Measure, Learn, agile, customer development, and I’m going to call it Lean Startup, I think that’s what it should be called because of my knowledge of lean manufacturing.” That was 2008, years after I’d left the company. That was the first time we had a theoretical conversation about whether this was right or not.
X: But a big part of your pitch, your reputation and credibility, is that you ran IMVU along these lines, and that you learned lessons that evolved into the lessons you teach now. So can you go back and be a little more concrete about how you ran engineering at IMVU in a way that you eventually would call “lean”?
ER: Sure. The reason I want to draw this distinction is that, it was actually harder to learn how to talk about it than it was to learn how to do it. So the integration of theory and language all came very late in the process. And actually, that was a problem. That turned out to be a significant problem, which is part of what motivates me to do this. Because the idea of continuous deployment, I just intuitive felt like it was a good idea. Honestly, I don’t know where it came from, but to me it’s the most obvious thing in the whole world that you build products where the code is directly integrated into production and you basically take single-piece flow from manufacturing and you apply that to the way you do software development. Apparently other people have different intuitions. It was a shock to me that people felt it to be controversial. I just thought it was obvious. So we were doing that. We had to figure out how to make that work at IMVU, because I was a stubborn person, I wanted it to work that way, and it was my call. I was in charge. So I was like, “Listen, until you fire me, we are going to do it this way.” I’ve now worked with dozens of companies to try to get them to switch over to this system, and there’s always objections about things that might go wrong. “What about this, what about that.” Usually if I’m an outside consultant, those objections are enough to derail the whole thing. But I was in charge, and I said “We’re doing this.” So now instead of objections, let’s figure this out. What about quality issues. What about databases and schemas. We had to work out all of this stuff. There was no theory about that. There was no one we could turn to for help. But you know what? We had very smart people working for us, and they figured it out.
X: Were you also gathering customer feedback and iterating?
ER: Yes, but not at the speed it is done today. We were very clumsy. The part of Steve’s message that we were very skeptical of was this idea that
