Books Posts

“When confronted with a problem, have you ever stopped and asked why five times?”

Taiichi Ohno

Summary: Whenever you find a defect, ask why five times to discover the root cause of the problem. Then make corrections at every level of the analysis. By applying five whys whenever you find a defect, you will (1) uncover the human problems beneath technical problems and (2) build an immune system for your startup.

This is a guest post by Eric Ries, a founder of IMVU and an advisor to Kleiner Perkins. Eric also has a great blog called Startup Lessons Learned.

Taiichi Ohno was one of the inventors of the Toyota Production System. His book, Toyota Production System, is a fascinating read, even though it’s decidedly non-practical. After reading it, you might not even realize that there are cars involved in Toyota’s business. Yet there is one specific technique that I learned most clearly from this book: asking why five times. I believe this is a critical lean startup technique.

When something goes wrong, we tend to see it as a crisis and seek to blame. A better way is to see it as a learning opportunity. Not in the existential sense of general self-improvement. Instead, we can use the technique of asking why five times to get to the root cause of the problem and make corrections.

Ask why five times whenever you discover a defect.

Here’s how it works. Let’s say you notice that your website is down. Obviously, your first priority is to get it back up. But as soon as the crisis is past, have the discipline to conduct a post-mortem in which you start asking why:

  1. Why was the website down? The CPU utilization on all our front-end servers went to 100%.
  2. Why did the CPU usage spike? A new bit of code contained an infinite loop!
  3. Why did that code get written? So-and-so made a mistake.
  4. Why did his mistake get checked in? He didn’t write a unit test for the feature.
  5. Why didn’t he write a unit test? He’s a new employee, and he was not properly trained in Test Driven Development (TDD).

Make five corrections.

So far, this isn’t very different from the kind of analysis any competent operations team would conduct for a site outage. The next step is this: you have to commit to making a proportional investment in corrective action at every level of the analysis. So, in the example above, we’d have to take five corrective actions:

  1. Bring the site back up.
  2. Remove the bad code.
  3. Help so-and-so understand why his code doesn’t work as written.
  4. Train so-and-so in the principles of TDD.
  5. Change the new engineer orientation to include TDD.

Making corrections builds your startup immune system.

I have come to believe that this technique should be used for all kinds of defects, not just site outages. Each time, we use the defect as an opportunity to find out what’s wrong with our process, and make a small adjustment.

By continuously adjusting, we eventually build up a robust series of defenses that prevent problems from happening. This approach is at the heart of breaking down the “time/quality/cost, pick two” paradox, because these small investments cause the team to go faster over time.

5 whys uncovers the human problems beneath technology problems.

In the example above, what started as a technical problem actually turned out to be a human and process problem. This is completely typical. Our bias as technologists is to focus on the product part of the problem, and five whys tends to counteract that tendency.

It’s why, at my previous job, we were able to get a new engineer completely productive on their first day. We had a great on-boarding process, complete with a mentoring program and a syllabus of key ideas to be covered. Most engineers would ship code to production on their first day.

Make your corrections proportional to the cost of the defect.

We didn’t start with a great program like that, nor did we spend a lot of time all at once investing in it. Instead, five whys kept leading to problems caused by an improperly trained new employee, and we’d make a small adjustment. Before we knew it, we stopped having those kinds of problems altogether.

So it’s important to remember the proportional investment part of the rule above. It’s easy to decide that when something goes wrong, a complete ground-up rewrite is needed. It’s part of our tendency to focus on the technical and to overreact to problems.

If you have a severe problem, like a site outage, that costs your company tons of money or causes lots of person-hours of debugging, go ahead and allocate about that same number of person-hours or dollars to the solution.

The budget for corrections should be, in total, proportional to the cost of the defect that triggered the five whys. So, if the site was down and five people burned a whole day on it, maybe five man-days of fixing is appropriate. But if the problem cost three customers 25 cents each, maybe only a few hours is appropriate.

But always have a maximum, and always have a minimum. For small problems, just move the ball forward a little bit. Don’t over-invest. If the problem recurs, five whys will give you a little more budget to move the ball forward some more. You can keep your cool because five whys will be there if the problem recurs.

In Part 2, I’ll describe how to get started with five whys.

“In a startup no facts exist inside the building, only opinions.”

Steve Blank

Summary: In Four Steps to the Epiphany, Steve Blank lays out a customer development process that complements a startup’s product development process. This post includes video and slides where Steve explains the ideas in his book.

About a year and a half ago, Marc Andreessen described The Four Steps to the Epiphany by Steve Blank as the “best book for tech entrepreneurs this year.” Marc wrote:

“Steve Blank is a super-experienced Silicon Valley technology entrepreneur… a dude with serious street cred…

“In a nutshell, Steve proposes that companies need a Customer Development process that complements their Product Development Process. And he lays out exactly what he thinks that Customer Development process should be. This goes directly to the theory of Product/Market Fit that I have discussed on this blog before—in this book, Steve provides a roadmap for how to get to Product/Market Fit.

“Buy it, read it, keep it under your pillow and absorb it via osmosis.”

I bought it, read it, couldn’t absorb it, put it on the shelf, and ignored it.

Fortunately, I’ve recently found a great talk and slides from Steve Blank that provide a more gentle introduction to customer development. Be gentle Steve

The talk

How Alan Michaels took Convergent Technologies from zero sales to a $400M exit in four years by discovering his customers:

Why most startups don’t need VPs:

Why most startups fail:

(Videos: Acting on Customer Discovery, No VP’s in a Start-up, Assessing Customer and Market Risks)

Go to Stanford’s Entrepreneurship Corner to see the rest of the videos from Steve’s talk. Or listen to audio of the talk, which includes segments you won’t see in the videos.

The Slides

Here are the slides from another talk by Steve. They roughly complement the videos above.

(Slides: The Customer Development Methodology (pdf))

Back to the book

I’m going to take another stab at reading The Four Steps to the Epiphany and I hope you join me. I’ll let you know how it goes—please do likewise!

Update: Also read Eric Ries’ excellent What is customer development?.

“For heavens sake, if you haven’t gotten comfy with Agile techniques and thinking, get on it right now.”

Tim Bray, Editor of XML 1.0

Summary: Start learning how to be lean by reading Agile Software Development. It isn’t the cheapest book in the world but it’s one of the cheapest investments you will make in your startup. It includes 14 simple and counterintuitive practices that will help you engineer your engineering and product teams. This post includes several excerpts from the book.

In Lean startups find their moment, we defined lean as the never-ending process of eliminating waste. We described its benefits: eliminating waste makes your business fast, cheap, high quality, and effective—yes, all the good stuff, all at once. We defined waste as anything that is not absolutely necessary for creating customer value. And we described the two greatest wastes: overproduction and inventory.

We also said that lean probably seems abstract so far. Time to make it more concrete.

Agile Software Development

We first learned how to be lean from a book called Agile Software Development by Robert “Uncle Bob” Martin. Uncle Bob is one of the creators of agile and agile is just another word that software developers use instead of lean. This isn’t the cheapest book in the world but it’s one of the cheapest investments you will make in your startup.

Chris Sepulveda recommended this book when we hired Pivotal Labs to help us with software development. I remember having one of those aha! moments when I first read it, “Oh, so this is how you quickly translate a founder’s vision into happy customers (hint: it isn’t by specifying the requirements up front). This is how you deliver software on time (hint: it isn’t by working overtime). This is how you eliminate bugs (hint: it isn’t with QA). This is how you make developers effective (hint: it isn’t by putting them in a quiet room by themselves). This is how you know when you’ll be done (hint: it isn’t with a Gantt chart). This is how you engineer an engineering and product team.”


Here’s a excerpt of the simple, lightweight practices in Agile Software Development:

“User Stories

“In order to plan a project, we must know something about the requirements but we don’t need to know very much… we only need to know enough about a requirement to estimate it.

“The specifics of a requirement are likely to change with time, especially once the customer [the founder or product manager] begins to see the system come together. There is nothing that focuses requirements better than seeing the nascent system come to life. Therefore, capturing the specific details about a requirement long before it is implemented is likely to result in wasted effort…

“The Planning Game

“The essence of the planning game is the division of responsibility between business and development. The business people (a.k.a. the customers) decide how important a feature is, and the developers decide how much the feature will cost to implement.

“At the beginning of each iteration [an iteration is one week], the developers give the customers a budget, based on how much they were able to get done in the last iteration. The customers choose stories whose costs total up to, but do not exceed that budget.

“With these simple rules in place, and with short iterations and frequent releases… the customers will be able to determine how long their project will take and how much it will cost.

“Simple Design

“An [agile] team will probably not start with infrastructure. They probably won’t select the database first. They probably won’t select the middleware first. The team’s first act will be to get the first batch of stories working in the simplest way possible. The team will only add the infrastructure when a story comes along that forces them to do so.

“You aren’t going to need it. An [agile] team seriously considers what will happen if they resist the temptation to add infrastructure before it is strictly needed. They start from the assumption that they aren’t going to need that infrastructure.

Test-Driven Development

“All production code is written in order to make failing tests pass. First we write a test that fails because the functionality for which it is testing doesn’t exist. Then we write the code that makes that test pass.

“Once a test passes, it is added to the body of passing tests and is never allowed to fail again. This growing body of tests is run several times per day, every time the system is built. If a test fails, the build is declared a failure. Thus, once a requirement is implemented, it is never broken. The system migrates from one working state to another and is never allowed to be inoperative for longer than a few hours.”

And here’s a pdf of Chapter 1 that I got from Uncle Bob’s website.

By themselves, these practices actually have too many flaws to be effective. Agile Software Development includes the nine remaining practices that you need to make an agile process work.

Parts of this book are for anyone, and parts are for developers. If you’re a founder or a product manager, read everything up to and including Chapter 3. If you’re a developer (I’m not), I’m guessing you should read everything up to and including Chapter 7—or read the whole book.

So what does any of this have to do with eliminating waste? More on that later.

This is the first in an ongoing series called Books for Entrepreneurs. We’ll use these posts to recommend books that we’ve found useful as entrepreneurs (duh).

Our first book is Bargaining for Advantage by G. Richard Shell. Richard is a professor at Wharton and this is my favorite negotiation book period. It synthesizes the principled negotiation of Getting to Yes with the psychology of persuasion in Influence.

Jim Pitkow recommended this book while we were raising Songbird‘s Series A. Since then, I have referred to it again and again while writing posts for Venture Hacks and answering questions from entrepreneurs.

Make sure you don’t read this book if these questions are irrelevant to you: Should I be the first to open? Should I open optimistically or reasonably? What sort of concession strategy works best?

Here’s a small sample of what you’ll find in Bargaining for Advantage:

What is leverage?

Everybody talks about leverage in negotiations but very few people know what it means. My favorite chapter, “Leverage” defines it (emphasis added):

A better way to understand leverage is to think about which side, at any given moment, has the most to lose from a failure to agree… the party with the most to lose has the least leverage; the party with the least to lose has the most leverage.

“Leverage often flows to the party that exerts the greatest control over and appears most comfortable with the present situation.

“To gain real leverage, you must eventually persuade the other party that he or she has something concrete to lose in the transaction if the deal falls through.

Positive leverage: Every time the other party says “I want” in a negotiation, you should hear the pleasant sound of a weight dropping on your side of the leverages scales. [Positive leverage is the ability to provide things your opponent wants.]

Negative leverage: Threat leverage [that] gets people’s attention because… potential losses loom larger in the human mind than do equivalent gains. But a word of warning is in order: Making even subtle threats is like dealing with explosives. [Negative leverage is the ability to hurt your opponent.]

Normative leverage: [Normative leverage is the ability to apply general norms or your opponent’s standards and norms to advance your position.] You maximize your normative leverage when the standards, norms, and themes you assert are ones the other party views as legitimate and relevant to the resolution of your differences. Attack [your opponent’s] standard only as a last resort.

This way of thinking about leverage also points to more sophisticated ways of enhancing your leverage that go beyond just improving your BATNA. Your goal is to alter the situation (or at least the other party’s perception of the situation) so you have less to lose, the other side has more to lose, or both.”

Bargaining for Advantage includes detailed examples that make the theory of leverage concrete.

Read the book to learn about opening, making concessions, closing, the rogue’s gallery of tactics, …

Related: The Monk and the Riddle, Inside Intuit.

More wisdom from Randy Komisar‘s The Monk and the Riddle (emphasis added):


“So why were they doing this? Why was it worth their time? I am always amazed that venture capitalists don’t ask that question. Perhaps at this point everyone assumes it’s obvious: to get rich.

“Passion and drive are not the same at all. Passion pulls you toward something you cannot resist. Drive pushes you toward something you feel compelled or obligated to do. If you know nothing about yourself, you can’t tell the difference. Once you gain a modicum of self-knowledge, you can express your passion…

[Passion] is the sense of connection you feel when the work you do expresses who you are. Only passion will get you through the tough times… It’s the romance, not the finance that makes business worth pursuing.

“I can’t get excited by a business whose biggest idea is making money.”

Venture Capital

“Most VCs (even if they insist otherwise) simply don’t have the time to give close management attention to the companies they’ve funded. In addition, in contrast to the original VCs, who often gathered years of operating experience prior to becoming venture capitalists, many partners in today’s firms have no executive management experience. They could be working on Wall Street as easily as on Sand Hill Road.”

“I have never seen a company fail for having too much money. Dilution is nominal, but running out of money is terminal.”


[Mediocrity is] the biggest risk of all in Silicon Valley… Instead of managing business risk to minimize or avoid failure, the focus here is on maximizing success. The Valley recognizes that failure is an unavoidable part of the search for success.

“[Excellence] should be your primary measure of success… not simply the spoils that come with good fortune. You don’t want to entrust your satisfaction and sense of fulfillment to circumstances outside your control. Instead, base them on the quality of what you do and who you are, not the success of your business per se.”


“Management is a methodical process; its purpose is to produce the desired results on time and on budget. It complements and supports but cannot do without leadership, in which character and vision combine to empower someone to venture into uncertainty. Leaders must suspend the disbelief of the constituents and move ahead even with very incomplete information.

Many ideas in this Valley happen against all common sense. It’s good when entrepreneurs are a little bit deaf and blind, but if they’re completely deaf and complete blind—and many are—they’re unlikely to learn enough from the market and their advisors to make their vision a reality.”

Randy KomisarI’m reading Randy Komisar‘s book, The Monk and the Riddle.

He wrote it before he became a partner at Kleiner Perkins and I like his description of the Rocket Ship model of investing (emphasis added):

“Over the last several years… a new investment model has taken hold. Fill each startup with rocket fuel as fast as possible and blast it into space. The ones that fly, fly, and if the rest of them blow up, c’est la vie.

“In fact, the Rocket Ship Model of startup investment has recently produced many of the most prominent Valley successes. But for every one of them, there are many potentially viable companies that might have eventually prospered if they had been incubated longer.

When too much money is pumped too fast into a startup, there’s no room for mistakes. The initial product and the initial fix on the market have to be right. There’s no way these companies can stop and reconsider what they’re doing with out a great deal of pain.

“You have to be able to survive mistakes in order to learn, and you have to learn in order to create sustainable success. Once the market is understood and the product is fully developed, then move fast and hard.”

Some more snippets from the book:

“[Angels] pay for the privilege of helping the company.”

“If I invest, I am prone to think like an investor, favoring my return over what’s best for the team and often its long-term business.”

“In a privately held startup I don’t favor the investors over the founders. This is probably the crucial way my thinking differs from a VC’s.”

“Business is one of the last remaining social institutions to help us manage and cope with change.”

“The rules of business are like the laws of physics, neither inherently good nor evil, to be applied as you may. You decide whether your business is constructive or destructive.”

doerr.pngThere is lots of wisdom in John Doerr‘s (Kleiner Perkins) introduction to Inside Intuit (emphasis added):

“Inside Intuit is a tale of missionaries, not mercenaries. It’s about a founding team that prevails through tenacity, frugality, and an obsession with the customer experience…

“Kleiner Perkins first learned about Intuit in 1985… But when it came to large numbers of households using their home computers to manage their checkbooks, we just couldn’t see it…

Neither [of the founders] had created a new product nor started a company from scratch, let alone single-handedly faced nearly forty competitors. So when Intuit’s flagship product, Quicken, began to take off in the marketplace, my partners and I at Kleiner Perkins… took notice.

…the “bake-off” [that founder Scott Cook] staged to help him choose from an array of eager potential investors really distinguished him from the crowd. More than a dozen venture capitalists vied to get a piece of Intuit. Cook and his team tested each finalist with a new, pressing, real problem: What should Intuit do if Microsoft entered the personal finance market to compete with Quicken?

“…we soon saw that Intuit differed in more ways than merely its approach to venture fund-raising. At the first Intuit board meeting I attended, I was surprised: more than half the meeting took place at Intuit’s tech support center, listening to tech reps answer customers’ product questions and fix their problems. Cook’s uniquely intense focus on happy customers and firsthand customer feedback impresses me to this day…

“Cook has an unusual ability to ask the right questions (which my partner Vinod Khosla insists is more important than getting the right answers; in business, there are often several right answers).

“In 1993, Cook realized before any of the rest of us that Intuit needed a new CEO to help the company reach the next level. How unusual, I thought at the time, for a company founder to know and admit that he might be holding his company back…

“Great CEOs are great teachers… What is unusual about Intuit is that… three leaders are all still actively engaged in building the company. As CEO, [Steve] Bennett has “the last call,” setting the tempo, directing the team. As chairman of the board, [Bill] Campbell [former CEO] holds sway from an off-campus office, advising the team, turning up on campus, and walking the halls. And Cook, as founder and chairman of the executive committee [and former CEO] provokes and celebrates strategy rethinking, inspires innovations, and continues, as ever, to obsess on the customers. As a leadership trio, they are unique in Silicon Valley.

“Not every businessperson aspires to be an institution-builder. Some simply want the freedom to be their own bosses, to achieve financial independence, to call the shots. Others want to solve problems and push the boundaries with their solutions; they work hard to “change the game” by innovating, rethinking, or breaking the rules. And yet, for all their efforts, business to them will always be just that—a game.

“For still others, however, and they’re a rare breed indeed, business is about striving for something more fundamental: to alter and improve their customers’ lives. These people aim to create companies that will transcend their creators, that will remain strong and productive from generation to generation. They aim to build lasting innovation…

I’ve always been awed by entrepreneurs, by how little they have to work with when they start and by how much they sometimes accomplish.

Related: Bill Cambell interviews Danny Shader of Good Technology.