My Take on "Lean Startups"

It seems like the "Lean Startup" movement has been sweeping through the valley over the past few years. I've spent quite a bit of time working with Lean Methodologies, both in building software startups and because that's a big part what I studied in grad school, so I'm going to weigh in. Basically, Lean is pretty cool, but it's not some kind of magical panacea for all the problems startups face. Like any tool, it works well when used properly, but it's also easy to misuse.

What is All This Lean Stuff Anyways?
For the unininitiated, Lean basically came out of Toyota following World War II. Japan was pretty resource drained from fighting and losing the war, so they had to think creatively in order to rebuild their country. Toyota wanted to make cars, but they didn't have nearly as many machines as Ford or GM. So, rather than having a different machine to make each part, they needed one machine to make a whole bunch of different parts. And in order to make that work, they had to be able to quickly switch that machine from making (for example) one body panel to another. Through the application of creative thinking, they managed to drastically reduce the switchover time. Not only did this make the operation much more efficient, it made it much more flexible. This sort of thinking revolutionized Toyota's operations, to the point where they were kicking the US auto manufacturers' butts by the late 80s.

I'm not going to go too much into the specifics of the "Lean Tools," but Lean basically involves opening your eyes, figuring out what is broken, and figuring out how to fix it. We see broken things hundreds of times a day, ruminate on them for a second, and then immediately forget about them (because that's what we're programmed to do). When you "become Lean," you actually try to fix these problems as they happen.

Q: But if we tried to fix every broken thing, wouldn't we never get anything done?
A: Well, thanks for asking. Actually, every worker at Toyota has a cord he can pull to stop the assembly line, and he is encouraged to pull it whenever needed. At first, this leads to a lot of line stops, but eventually all of the simple problems are ironed out, and everything works a lot more smoothly than it used to.

And that's basically it. There are a lot of "tools" that have been developed to help us apply Lean in the real world, but those are just gravy, and aren't strictly required. Basically, if you are methodically observing and fixing broken things, you are trending towards Lean.

The first one to introduce this stuff to a wider audience was Eli Goldratt with The Goal, but I guess that Steve Blank's "Four Steps To The Epiphany" was the way that most people in Silicon Valley were introduced. Honestly, none of us actually read past the first couple of chapters, but every self-respecting entrepreneur has a copy on his bookshelf (and has recommended it to at least two friends). But I guess that wasn't enough, so Eric Ries recently released "The Lean Startup." I personally own at least 7 copies (mostly purchased to get the freebies). If you are interested in actually learning the principles in a hands-on way, there is "The Lean Startup Machine," a weekend-long practical bootcamp.

So how exactly does "Lean" apply to product development? Basically, it comes down to simplifying and testing your assumptions before you spend months or years building it. Figure out whether anyone actually wants the freaking thing before you spend your life savings paying engineers to code it for you. As Paul Graham says, "build something people want." The trick is that you need to figure out what that something is before you can build it. And that can be easier said than done.

Why Easier Said Than Done?
So, the biggest wrinkle is that none of this quite as straightforward as it seems. When you actually go out and ask your potential customer what he/she wants, he probably will tell you that he doesn't know. He's too busy worrying about how to do his job to figure out how to do yours. If you're lucky, he will be able to enumerate what his biggest problem is, but a lot of people can't even do that. Most likely, when you ask, your customer will mention some peripheral problem that isn't even close to the biggest one out there. Steve Spear (who is an expert on implementing Lean in healthcare systems) takes the following approach to identifying problems - he follows doctors around for a day, and writes down all of the things that are broken as they happen. Then he figures out which problems are the most disruptive, and solves those.

So here's how I would start - first you figure out the problem you want to solve, and you figure out the minimum possible product that could solve that problem (aka Minimum Viable Product or MVP). So you build the MVP (and by "build", you could just mock it up), and you show it to people as soon as possible. You could even tell people about it before you have built anything, and see how excited they are. Basically, if people (and by "people", I mean the people who write the check) are excited by whatever you show them, you keep going, and move on to the next phase. If not, you take a step back, or maybe even start over. There are probably going to be a lot of these - a lot of startups don't get to the good stuff until they hit their fourth or fifth idea.

You Can't Always Bootstrap
 So once you build your MVP, and people like it, now what? In some cases, you can get people to actually use that product and potentially even pay for it. This can make for a great business model - a bunch of successful companies have been built this way (Github, 37 Signals, Bingo Card Creator). The problem is that none of these businesses were completely new - hosted Git was just Git repackaged in an easier to use package, while Bingo Card Creator replaced desktop software. It's likely that if you're actually doing something all new, there are going to be leaps of faith. This is where Lean starts to break down - it isn't always viable to bootstrap every business. At some point, you have to take a gamble and throw in a bunch of resources to get from MVP to the product that people will actually pay for. For example, if you are going to create a new automobile company, there is going to be a lot of upfront investment before you can build your first car.

When I attended Lean Startup machine in San Francisco at the beginning of the year, Dave McClure was one of the kickoff speakers, and he summed up all this stuff pretty well. He said something along the lines of "We don't know if this Lean stuff works. But it definitely does seem to do good job at showing us which ideas won't work."

Setting Up an Experimental Framework
Mark Pincus of Zynga puts it well when he talks about building an experimental framework. Instead of worrying about making your company instantly profitable, or about lining up about customers before you have product to sell (both of these are nice IF you can do them), set up the product development cycle as a series of tests. At any point, you should be working systematically towards putting your product through the next predefined test. The actual set of tests will vary based on what the product is, but there should always be a plan on the table.

For example, the first test could be "Do people seem excited when I talk about this?" Then you could build a paper prototype (or simple usable prototype), and see whether people still seem interested. Then you add a few more features, and see whether you can get them to agree to use the product. Then you add the features they need to use the product, and see whether you can actually get them to pay for it. Then you try to figure out a reasonable model for customer acquisition. And so on and so forth. 

If a test passes, you keep going. Whenever a test fails (and tests will fail a lot), you will realize that you have made some incorrect assumptions. At that point, you figure out whether to pivot to a different set of assumptions or to throw the product out. The early tests will hopefully be a lot cheaper and quicker than the later tests. That way, you have failed quickly with the ideas that aren't going to make it.The goal is to minimize your downside, and spend as many or your resources as possible on the most promising ideas. And that's how Lean applies to product development at startups.