Running Lean, 2nd Edition

Introduction

What Is Running Lean?

We live in an age of unparalleled opportunity for innovation. With the advent of the Internet, cloud computing, and open source software, the cost of building products is at an all-time low. Yet, the odds of building successful startups haven’t improved much.

Most startups still fail.

But the more interesting fact is that, of those startups that succeed, two-thirds report having drastically changed their plans along the way.^[1]

So, what separates successful startups from unsuccessful ones is not necessarily the fact that successful startups began with a better initial plan (or Plan A), but rather that they find a plan that works before running out of resources.

Up until now, finding this better Plan B or C or Z has been based more on gut, intuition, and luck. There has been no systematic process for rigorously stress-testing a Plan A.

That is what Running Lean is about.

Running Lean is a systematic process for iterating from Plan A to a plan that works, before running out of resources.

Why Are Startups Hard?

First, there is a misconception around how successful products get built. The media loves stories of visionaries who see the future and chart a perfect course to intersect it. The reality, however, rarely plays out quite as simply. Even the unveiling of the visionary computer, the iPad, in Steve Jobs’ words was years in the making, built on several incremental innovations (and failures) of software and hardware.

Second, the classic product-centric approach front-loads some customer involvement during the requirements-gathering phase but leaves most of the customer validation until after the software is released. There is a large “middle” when the startup disengages from customers for weeks or months while they build and test their solution. During this time, it’s quite possible for the startup to either build too much or be led astray from building what customers want. This is the fundamental dilemma described by Steve Blank in The Four Steps to the Epiphany, in which he offers a process for building a continuous customer feedback loop throughout the product development cycle that he terms Customer Development.

And finally, even though customers hold all the answers, you simply cannot ask them what they want.

If I had asked people what they wanted, they would have said faster horses.

—Henry Ford

A lot of people cite the preceding quote and declare it hopeless to talk to customers. But hidden in this quote is a customer problem statement: had customers said “faster horses,” they would really have been asking for something faster than their existing alternative, which happened to be horses.

Given the right context, customers can clearly articulate their problems, but it’s your job to come up with the solution.

It is not the customer’s job to know what they want.

—Steve Jobs

Is There a Better Way?

Running Lean provides a better, faster way to vet new product ideas and build successful products:

• Running Lean is about speed, learning, and focus.

• Running Lean is about testing a vision by measuring how customers behave.

• Running Lean is about engaging customers throughout the product development cycle.

• Running Lean tackles both product and market validation in parallel using short iterations.

• Running Lean is a disciplined and rigorous process.

Running Lean references an array of methodologies and thinkers. Three of the most important follow.

Customer Development

Customer Development is a term coined by Steve Blank and is used to describe the parallel process of building a continuous feedback loop with customers throughout the product development cycle. It is defined in his book, The Four Steps to the Epiphany.

The key takeaway from Customer Development can best be summed up as:

Get out of the building.

—Steve Blank

Most of the answers lie outside the building—not on your computer, or in the lab. You have to get out and directly engage customers.

Lean Startup

Lean Startup is a term trademarked by Eric Ries and represents a synthesis of Customer Development, Agile Software Development methodologies, and Lean (as in the Toyota Production System) practices.

The term Lean is often misunderstood as “being cheap.” While “being Lean” is fundamentally about eliminating waste or being efficient with resources, that interpretation is not completely misguided because money happens to be one of those resources.

However, in a Lean Startup, we strive to optimize utilization of our scarcest resource, which is time. Specifically, our objective is maximizing learning (about customers) per unit time.

The key takeaway from Lean Startup can best be summed up around the concept of using smaller, faster iterations for testing a vision.

Startups that succeed are those that manage to iterate enough times before running out of resources.

—Eric Ries

Bootstrapping

Bootstrapping is more commonly understood as a collection of techniques used to minimize the amount of external debt or funding needed from banks or investors. Too often, people confuse bootstrapping with self-funding. A stricter definition is funding with customer revenues.

However, I subscribe to a much more philosophical definition of bootstrapping put forward by Bijoy Goswami:

Right action, right time.

Startups are inherently chaotic, but at any given point in time, there are only a few key actions that matter. You need to just focus on those and ignore the rest.

What Will This Book Teach You?

In this book, you’ll learn:

• How to first find a problem worth solving, before defining a solution

• How to find early customers

• When is the ideal time to raise funding

• How to test pricing

• How to decide what goes into Release 1.0

• How to build and measure what customers want

• How to maximize for speed, learning, and focus

• What is product/market fit

• How to iterate to product/market fit

Is This Book for You?

If you are an entrepreneur considering building a new product, or if you already have a product and you want to raise your odds of making it successful, this book is for you.

Running Lean is for:

• Business managers

• CEOs

• Developers and programmers who are interested in becoming successful entrepreneurs

• Bloggers, cofounders, small-business people, writers, musicians—anyone who’s creative and interested in starting a new business project

• Innovators

• Startup founders

How Is This Book Organized?

This book is organized into four parts. The parts are meant to be read in order, as they outline the chronological steps required to apply Running Lean to your product—from ideation to product/market fit. Even if you already have a product launched, I recommend starting from the beginning. You will not have to spend as much time going through the stages, and this exercise will help you baseline where you currently are and formulate your next actions.

Each part ends with gating criteria that will help you decide if you’re ready to move on to the next one.

Part 1: Roadmap

Part I provides an overall roadmap of the Running Lean process. Specifically, it describes the three core meta-principles that capture the essence of Running Lean and ends with a short case study that helps illustrate these principles in action.

The rest of the book covers each of the following meta-principles in detail in three parts.

Part 2: Document Your Plan A

Part II walks through the process of documenting your initial vision (or Plan A) using a portable one-page format called Lean Canvas. Your Lean Canvas will serve as your product’s tactical map and blueprint.

Part 3: Identify the Riskiest Parts of Your Plan

Part III helps you identify which aspects of your plan to focus on first. It lays some groundwork on the different types of risks startups face, shows you how to prioritize them, and prepares you to start the process of testing and experimentation.

Part 4: Systematically Test Your Plan

Part IV outlines the four-stage process for systematically stress testing your initial plan and shows you how to iterate from your Plan A to a Plan That Works.

About Me

I bootstrapped my most recent company, WiredReach, in 2002, and sold it in late 2010. Throughout that time, I built products in stealth, attempted building a platform, dabbled with open sourcing, practiced “release early, release often,” embraced “less is more,”^[2] and even tried “more is more.”

The first realization early on was that building in stealth is a really bad idea. There is a fear, especially common among first-time entrepreneurs, that their great idea will be stolen by someone else. The truth is twofold: first, most people are not able to visualize the potential of an idea at such an early stage, and second (and more importantly), they won’t care.

The second realization was that startups can consume years of your life. I started WiredReach with just a spark of an idea, and before I knew it, years had passed. While I’ve had varying levels of success with the products I built, I realized that I needed a better, faster way to vet new product ideas.

Life’s too short to build something nobody wants.

And finally, I learned that while listening to customers is important, you have to know how to do it. I used a “release early, release often” methodology for one of my products, BoxCloud, and launched a fairly minimal file-sharing product built on a new peer-to-web model we had developed in 2006. After we launched, we got covered by a few prominent blogs and dumped some serious cash into advertising on the DECK network (primarily targeted at designers and developers).

We started getting a lot of feedback from users, but it was all over the place. We didn’t have a clear definition of our target customer and didn’t know how to prioritize this feedback. We started listening to the most popular (vocal) requests and ended up with a bloated application and lots of one-time-use features.

Around that time, I ran into Steve Blank’s lectures on Customer Development, from which I followed the trail to Eric Ries’s early ideas of the Lean Startup. I had dreamt the big vision, rationalized it in my head, and built it and refined it the long, hard way. I knew customers held the answers but didn’t know when or how to fully engage them. That’s exactly what Customer Development and Lean Startup were attempting to address.

I was sold.

Why This Book?

I was determined to test these techniques on my next product (CloudFire) but ran into many early challenges when trying to take these concepts to practice.

For one, Steve Blank’s book was written for a specific type of business, enterprise software, which made it hard to carry over many of the tactics to my products. Also, while Eric Ries was sharing his retrospective lessons learned from working at IMVU, IMVU was no longer a startup. With a technical staff of 40 people and more than $40 million in revenue, what you saw was a fully realized Lean Startup machine, which was at times daunting.

I had more questions than answers, which prompted my two-year journey in search of a better methodology for building successful products. The product of that journey is Running Lean, which is based on my firsthand experiential learning building products and the pioneering work of Eric Ries, Steve Blank, Dave McClure, Sean Ellis, Sean Murphy, Jason Cohen, Alex Osterwalder, and many others who I reference throughout the book.

I am thankful to the thousands of readers who subscribed to my blog, left comments week after week, sent me notes of encouragement to keep on writing, and subjected their products to my testing. This book was really “pulled” out of me by them.

Field-Tested

As a way to test the content for this book, I started speaking and teaching Running Lean workshops. I have shared this methodology with hundreds of startups and worked closely with many of them to test and refine it.

Whereas my blog is a near-real-time account of my lessons learned, this book benefits from retrospective learning and from reordering and refining steps for a more optimal workflow.

I am applying this new workflow to my next startup, which is also a by-product of my blogging and learning over the past year. As of this writing, I have sold WiredReach and am in the process of building and launching a new startup, Spark59.

Disclaimers

Practice Trumps Theory

You get a gold star not for following a process, but for achieving results. One of the things that particularly drew me to the Lean Startup methodology is that it is a meta-process from which more specific processes and practices can be formulated. The same principles used to test your product can and should be applied to test your tactics when taking these principles to practice.^[3]

Everything in this book is based on first-hand experiential learning and experimentation on my own products. I encourage you to rigorously test and adapt these principles for yourself. The legal, financial, and accounting aspects of launching a company are outside the scope of the book. When the time comes, it is important to get competent professional advice about financing and structuring your company and its intellectual property assets.

There Are No Silver Bullets

No methodology can guarantee success. But a good methodology can provide a feedback loop for continuous improvement and learning.

That is the promise of this book.

---

^[1] John Mullins and Randy Komisar, Getting to Plan B (Boston, MA: Harvard Business Review Press, 2009).

^[2] A product development philosophy popularized by 37signals.

^[3] There is no room for faith in a Lean Startup: http://www.ashmaurya.com/2011/02/do-you-have-faith-in-lean-startups/.