Startup 101

Lean Startup: Look Before You Leap

If you're thinking about creating a startup, do your homework and learn about lean startup. Don't spend six months coding a product; prove that people want to buy it first.

• By Patrick Foley
• 01/04/2012

Go for it! This is a great time to build a startup, and there's no substitute for just doing it.

But … there's also something to be said for preparation. The startup world has figured out quite a few things in the last five years, and the leaders of the startup community have been kind enough to write them down.

Eric Ries is carrying the banner for the most prominent movement in the startup world, "Lean Startup." Although rooted in the concepts of lean manufacturing, you can think of lean startup as an extension of agile software development principles to business.

Just as agile strives for tight iterations for software development, lean startup strives for a tight cycle of build-measure-learn. Instead of spending six months building something that you hope customers will buy, lean startup suggests building the smallest thing that you can measure effectively to learn if you are moving your business forward or if you need to "pivot" in a different direction.

Agile guru Kent Beck once described it to me this way: the most important business question is whether or not people will buy your product; so instead of building it, make a webpage with a "click here to buy" button and see if you can get people to click on it. If people click the button, then you ask for their email address to let them know when the product will be ready. If nobody clicks on it, then aren't you happy you didn't build the product?

Think about that for a second. That Big Idea of yours – how long would it take you to build it? Six months? A year? More? Have you proven that people will pay for it once you build it? How long would it take you to build a simple webpage describing your product – selling your product – with a "click here to buy" button? A day or two? If you can't sell it, why build it?

What are the consequences of spending six months or a year building something only to find out people don't actually want it (or don't want to pay for it)? For most people, it would be devastating. It would drain your finances and bruise your ego. By contrast, what are the consequences of finding out that nobody clicks on your landing page? Not much; it simply means you have to try again with another idea – you need to pivot – and because you only spent a day or two attempting to validate this idea, you probably still have the energy and resources to pivot toward another one.

Even when you build a simple Web page to validate your idea, you still have to figure out how to get people to visit it. Unless you're already a celebrity or have thousands of Twitter followers, that likely means "renting" traffic by paying for Google or Bing search terms. Rob Walling discusses this technique in detail in his book Start Small, Stay Small. Rob cautions that you have to plan for the cost of search terms as you decide what product to build, as this represents your cost to acquire customers.

Every commerce site has a "conversion rate": for every 100 visitors, let's say only one will buy; that's a 1 percent conversion rate. If you have an idea of your conversion rate (perhaps from people clicking on your Buy button) and you know how much it costs to generate 100 visitors (from paying Google or Bing), then you know how much you need to make from each customer who buys. If you test a 1 percent conversion rate for a $25 product, and it only costs $15-20 to get 100 visitors, that's a good sign you can profit.

On the other hand, if the cost of acquiring customers is greater than what you can charge those customers, then you will fail, no matter how great your idea seems. In practice, online businesses that would likely be found using very common or general search terms are incredibly difficult to pull off, because those search terms are expensive ("to-do list manager" and "twitter client" come to mind).

There's no reason to guess; you can prove whether or not people will pay a profitable price for your product before you even build it by creating a landing page and paying to drive traffic to it. If you can charge more than it costs to drive traffic, you have a winner. If not, it's time to pivot. That's lean startup in a nutshell.

Developers usually resist lean startup; when you have a great idea, you want to open Visual Studio and build it! You probably figure you'll worry about all that sales and business stuff after you've perfected your software. It doesn't usually work. Lean startup flips these activities around, and it takes some getting used to, just as it takes practice to get used to agile concepts like writing tests first and pair programming. Now you're not just building software, you're building a business.

To move your business forward, you have to learn. Just as agile prescribes building the "simplest thing that could possibly work," lean startup prescribes building the "minimum viable product" or MVP. You have to constantly ask yourself, "What is the absolute least I can build to test my next business hypothesis?" If you prove your hypothesis, go further in that direction. If you disprove it, you pivot into a new direction. Just as with agile iterations, early cycles of build-measure-learn should probably take a week or two, not six months.

These principles apply whether you're a one-person bootstrapper or a VC-funded hotshot. There's simply no reason to build something until you've proven that people will buy it -- and that customers will pay more than it costs to acquire them. Even though you're probably more comfortable programming, get the selling right first. I can't stress this enough: spend your upfront energy proving that you can make money, instead of writing code.

Lean startup is a movement with lots of variations and interesting voices. Eric Ries's book is a great overview. Eric built upon Steve Blank's customer development ideas as outlined in The Four Steps to the Epiphany. Other authors have built upon Eric's ideas. I'm particularly fond of Ash Maurya's Running Lean as a prescriptive guide to applying these principles, and there are many helpful blogs on these topics as well. At some point, you have to learn by doing; but it's awfully helpful to arm yourself with knowledge first. Learning the principles of lean startup will increase the likelihood that you'll succeed once you make the leap.

Please let me know if this column is useful. If it is, then next month, I'll address one of the most dreaded business activities for programmers: talking to customers.