Eric Ries⁠’⁠ blog is called Lessons Learned, and for the software developer and entrepreneur turned business theorist, the phrase has at least a couple of meanings. There’s his career, which includes the lessons learned from a couple of failed startups before he succeeded with the social game and entertainment site, IMVU. And there is the influential management philosophy he helped forge―Lean Startup―which argues that companies must learn quickly from their own mistakes and “⁠pivot⁠”⁠ when necessary.

Ries grew up in San Diego, started programming on an IBM XT, and during high school, got good enough at Java to contribute to some books on the subject. He graduated from Yale with a major in computer science and an interest in philosophy. In 2007, BusinessWeek magazine named him among the best young tech entrepreneurs of the year. Ries was 28 and was already thinking about his theory of why some startups succeed while others don’t.

These days, the former software developer is writing not lines of code, but lines of text for a forthcoming book. “⁠This thing has totally taken over my life,⁠”⁠ he says. “⁠It started out as a blog and has grown into a movement. I never thought I’d make my money as an author, but now I spend my time writing, speaking and working with companies wherever I can.”

The idea of Lean Startup seems closely related to Agile development: quick iterations, fast feedback, lessons learned.

That’s how I began. My background is in software development, so I was trying to apply Agile development ideas more broadly. Agile is a good methodology; it’s very effective under certain circumstances. But at its root, Agile assumes we know the problem we are trying to solve, that somebody can give us authoritative answers about what the business needs. That may be true in the IT departments of large, established companies where Agile has its roots. But it’s not true in entrepreneurial situations where a big part of the challenge is figuring out who the customer is and what the product should be.

The Agile manifesto measures progress using working code, rather than plans and documents. That’s good: a line of working code is a great unit of progress. But in the world we live in where things are changing so quickly, learning is a more meaningful unit of progress, and code is a means to that end.

You launched your professional career contributing to books on Java.

I was only 16 at the time. Java got my attention because the compiler was free. This was at the time the Java boom produced an incredible amount of hype, with a huge demand for Java experts. There’s no such thing as an expert in a new language, so I concluded that I was much an expert as much as anybody else. I understood that no one knew my age; I would be judged by the content of what I said rather than by how I looked or my voice sounded.

I found my first writing job on Usenet, where I was applying to any job offers that seemed remotely plausible. Most people wanted to see my resume, but there was a publishing company with a Java book coming out, and they had an author drop out at the last minute. I wrote them that I was an expert on Java game programming, and instead of asking for my age, they asked for a sample chapter. To their credit, when they did eventually find out how old I was, they took it in stride. That lead to more writing. I was not deeply knowledgeable about any of those topics but I had a gift for explaining things to people as I was learning them myself.

When did you become an entrepreneur?

At Yale. I did a startup for my dorm. It was the dot.com boom; everyone was doing startups back then. I was over-confident. I really believed I knew how to build a great company. But there is something about failing consistently over the course of five years that gets you to wonder what’s wrong with this picture. There was something to be learned.

So I moved out to the Silicon Valley in 2001 to join a startup. I wanted to apprentice myself to the best entrepreneurs I could find. What I discovered to my chagrin was that the traditional Silicon Valley way of building companies didn’t work that much better than the junk I was doing in my dorm. They were just spending a lot more money. That, more than anything else, got me interested in new ideas about entrepreneurship. I would look at this assemblage of incredible talent, the smartest people you could find, and to watch them work on something for years that was doomed to failure.

I was lucky to have good mentors, who encouraged my thinking and gave me the opportunity to experiment with my own ideas. Will Harvey, who was the founder of one of the companies I had joined in Silicon Valley, became my co-founder at IMVU. He was willing to treat me as a co-equal even though I’m much younger, allowing me to run the technology team at IMVU the way I thought it should be run. That was the first working laboratory I had to put into practice of what I now think of as a new methodology.

Another mentor was Steve Blank, an entrepreneur who taught a class at the University of California, Berkeley on customer development. He would famously say that most startups fail not because of technology, but a lack of customers―and yet we manage the technology a lot more rigorously than we manage customers. In other words, he was thinking in a rigorous way about entrepreneurship, and he encouraged me to do the same. It was the right confluence of messages for me. I had had these ideas gestating in my mind, but it’s hard to put them into practice when you are trying to convince people to do something that seems crazy. I tried to put it into practice at IMVU, and, frankly, a lot of the things we did, people outside the company thought were nuts.

Like what?

One of the morst controversial things we did was what we call continuous deployment: the process of putting software into production up to 50 times a day. Between the time that a piece of code is checked into the main trunk and the time it is running averages something like 20 minutes.

This is Agile on steroids.

Right. It’s taking a lot of the Agile ideas to their logical conclusion. If you really value feedback and learning is your main goal, then the time to figure out if an idea is any good should be as short as possible. And just like the Toyota production system, the goal is not to run as fast as possible, but to run as fast as is productive. You want to be disciplined about driving waste and delay out of your system so that as the continuous improvements start to kick in, you get better and better at building the things.

I eventually came to understand that the goal is to drive down the batch size of our work, just as it is in manufacturing. We started to think of code that had been written but is not yet in customers⁠’⁠ hands as a kind of inventory. And having excess inventory leads to all the problems of traditional software development. Things don’t integrate, conflicts don’t get resolved, ideas grow stale. And most damaging, mistakes aren’t discovered until the next release window. If you are on a 30-day release cycle, it’s possible to make a mistake and not find out for four weeks.

How does that play out beyond the product? Marketing, for example?

For an early stage company, there’s really no difference between marketing and product. Our first version of IMVU took about six months, but as it turned out, our initial product strategy was all wrong, and customers hated it. We eventually figured out what we had done wrong―and so we did a “⁠pivot⁠”⁠ in order to make it more appealing. A lot of the software that I wrote in those days got thrown away, because, as it turned out, I had built a lot of features that customers didn’t want.

That’s the ultimate wasted effort. And to make myself feel better, I thought: well at least we learned some important things about customer demand. But then I had another thought: if that was the goal, why did it take six months? Couldn’t I have learned this same thing with less effort? Maybe I could have written less code. But maybe, I could have learned the same thing without writing any code. What if we created a single landing page that presented the value proposition for the product, rather than the product itself. That landing page―a kind of product spec put out for the world to see―is neither marketing nor product development, but is fundamentally a new thing: a way to do the minimum amount of work to learn the maximum.

You have written in your blog: “Each iteration leads to a pivot in which the company systematically changes some part of the vision to adopt to reality.”

That’s the idea. The hardest decision an entrepreneur can make is: should I pivot, or should I persevere? It’s not a formula: everyone has heard those stories of entrepreneurs who just just stuck it out through one more iteration and made the concept work. And there are others who just pivot around in a circle, going nowhere. What we’ve discovered in the Lean Startup movement is that if you’re disciplined about identifying and testing your hypotheses, that decision is much less agonizing―and often, much faster.

You argue that despite the name, the Lean Startup methodology is not just for startups.

I first started writing about this in 2008, and when I gave my first presentation at the Web 2.0 conference, I started out with a definition: “⁠A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.⁠”⁠ Notice that this says nothing about company size. If you qualify under that definition, you’re an entrepreneur, whether you know it or not.

Your ideas borrow from the Japanese. Have you received any feedback from Japan?

I gave a talk to Japanese entrepreneurs and investors, many of them young, who essentially asked: “⁠How do we reconcile this idea with the Japanese way?⁠”⁠ And I told them that I learned these ideas from the Toyota production system. And they looked at me like I was crazy―even crazier than the average American―because to them, the Japanese way was very bureaucratic, top-down, and non-innovative. They felt that these companies, including Toyota, had lost the agility of their earlier years. And that’s classic behavior of general management―when you get good at something, you tend to become fixated on doing it better and better.

The Toyota production system is a credit to Taiichi Ohno, W. Edwards Deming and others in Japan who figured out how to make it work―which is about applying science to every aspect of management to make it more efficient throughout the entire enterprise. But that methodology was created to answer a 20th century question: can it be built? In our era, the question is different. Should it be built? Traditional management is simply not equipped to answer that question. And I think there’s an opportunity for Toyota, as well as all the companies who have mastered the Toyota management paradigm, to take their thinking to the next level.