Book Review: The Lean Startup

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
With The Lean Startup, Eric Ries has produced a truly interesting, engaging book that is valuable for anyone seeking to drive innovation. In fact, given the intense scrutiny that venture capitalists purportedly have towards startups these days, this book might actually be more applicable to larger organizations and those who want to be better intrepreneurs.

The Lean Startup, as the title suggests, guides the reader in the application of Lean principles in a software startup. A startup, according to Ries, is “… a catalyst that transforms ideas into products.” And the products that a startup builds, “are really experiments; the learning about how to build a sustainable business is the outcome of those experiments.”

As part of this Ries advises us to avoid sub-optimizing individual functions, favoring working through what he calls the Build-Measure-Learn feedback loop in a specific way. Ries’ point is that, “… the goal is not to produce more stuff efficiently. It is to—as quickly as possible—learn how to build a sustainable business.” In the context of applying the principles of the Lean Startup, what matters is how quickly you can get through the entire Build-Measure-Learn loop.

The first step is to enter the Build phase as quickly as possible with a minimum viable product (MVP), a minimum viable product being a minimalist implementation, and most likely lacking in features that “may prove essential later on.” I wrote about this approach in the latter half of a recent post, How to Fire a Business Bullet.

The goal is to generate feedback and data from real customers as quickly as possible in the form of validated learning. As part of this process, you may be surprised at what you discover. Customers don’t always value what you expect, and I cited an example from The Lean Startup in another post, Put Your Product Assumptions to the Test!

Once you have completed one Build-Measure-Learn loop, The Lean Startup tells us that we will face a choice: pivot the original strategy or persevere. A pivot can be essential to success, but it is not change for the sake of change. It is “…a special kind of structured change designed to test a new fundamental hypothesis about the product, business model, and engine of growth.”

Too often, companies stick with executing bad plans—doing the wrong thing well. As The Lean Startup points out, “there is no bigger destroyer of creative potential than the misguided decision to persevere. Companies that cannot bring themselves to pivot to a new direction on the basis of feedback from the marketplace can get stuck in the land of the living dead, neither growing enough nor dying, consuming resources and commitment from employees and other stakeholders but not moving ahead.”

For those of us involved with Agile software development, The Lean Startup provides an interesting perspective on user stories and customer personas: “The customer archetype is a hypothesis, not a fact. The customer profile should be considered provisional until the strategy has shown via validated learning that we can serve this type of customer in a sustainable way.”

Ries cites how Grockit modified its development process to reflect the need for validated learning. With Grockit’s new system, user stories were not considered complete until they had performed validated learning; validated being defined as “knowing whether the story was a good idea to have been done in the first place.”

Validated learning, The Lean Startup points out, is essential because—in the words of venture capital investor Shawn Carolan—“Startups don’t starve; they drown. There are always a zillion new ideas about how to make the product better floating around, but the hard truth is that most of those ideas make a difference only at the margins. They are mere optimizations. Startups have to focus on the big experiments that lead to validated learning. The engines of growth framework helps them stay focused on the metrics that matter.”

As those of us in the software industry are painfully aware, the process of building software is rarely smooth sailing. There is always room for improvement. Ries discusses the issue of quality and continuous improvement in The Lean Startup: “You cannot trade quality for time. If you are causing (or missing) quality problems now, the resulting defects will slow you down later. Defects cause a lot of rework, low morale, and customer complaints, all of which slow progress and eat away at valuable resources.”

Ries advises using, “…the paradoxical Toyota proverb, ‘Stop production so that production never has to stop.’ The key to the andon cord is that it brings work to a stop as soon as an uncorrectable quality problem surfaces—which forces it to be investigated.”

Ries uses a familiar technique as an incremental investment in evolving a startup’s process: the Five Whys:

“Let me demonstrate how using the Five Whys allowed us to build the employee training system that was mentioned earlier. Imagine that at IMVU we suddenly start receiving complaints from customers about a new version of the product that we have just released.

1. A new release disabled a feature for customers. Why? Because a particular server failed.
2. Why did the server fail? Because an obscure subsystem was used in the wrong way.
3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
4. Why didn’t he know? Because he was never trained.
5. Why wasn’t he trained? Because his manager doesn’t believe in training new engineers because he and his team are ‘too busy.’

What began as a purely technical fault is revealed quickly to be a very human managerial issue. In the example above, the answer is to fix the server, change the subsystem to make it less error-prone, educate the engineer, and, yes, have a conversation with the engineer’s manager.”

Ries also cautions us that, “The Five Whys requires an environment of mutual trust and empowerment. In situations in which this is lacking, the complexity of Five Whys can be overwhelming.” The Lean Startup acknowledges that the Five Whys can devolve into the Five Blames: “Instead of using the Five Whys to find and fix problems, managers and employees can fall into the trap of using the Five Blames as a means for venting their frustrations and calling out colleagues for systemic failures.”

Ries reminds us that, “the goal of the Five Whys is to help us see the objective truth that chronic problems are caused by bad process, not bad people, and remedy them accordingly.” When things go wrong, Ries says, “We face the age-old dilemma summarized by Deming: How do we know that the problem is due to a special cause versus a systemic cause? If we’re in the middle of adopting a new way of working, the temptation will always be to blame the new system for the problems that arise. Sometimes that tendency is correct, sometimes not. Learning to tell the difference requires theory.”

Overall, I found The Lean Startup to be very well written, and it paints an excellent picture on the subject of applying the principles of Lean thinking to software product development.