Venture Hacks

We don’t know a lot about organizing organizations.

We apply techniques like command and control, specialization, batch processing, hierarchy, and other other lessons we’ve learned from TV, our parents, previous jobs, school, the military, wherever.

But there are other ways to organize organizations. And we’re learning more about them every day.

Evolving Excellence writes about Sun Hydraulics, a company that’s organized in an extraordinary way:

“Their culture is really something to see.  A $170 million public company that manufactures high end hydraulic manifolds and valves, profitable since it was started in 1970, [with] six plants around the world employing roughly a thousand people.

“What’s unusual about that?  How about this:

• There is no organization chart
• There are no job titles or job descriptions
• No performance criteria
• No bonuses and no perks
• No regularly scheduled meetings
• No approval levels for capital or expense spending
• No goals
• No offices or high-walled cubicles
• If the peers accept the idea, then “management” is presumed to accept it — hence the need for very little management
• Every employee is simply expected to figure out where they fit

“There is one honorary job title: Plant Manager.  But it’s not what you think.  This facility, what amounts to a very large machine shop filled with heavy 5-axis CNC’s, has hundreds of live plants hanging from the ceiling.  The Plant Manager is the person in charge of maintaining the plants.”

Read the rest of the post on Evolving Excellence for some hints on how they organize under these conditions. More extraordinary organizations coming up.

Some recent highlights from our profiles on Twitter and FriendFeed:

“Morons! I know there’s nothing out there. That’s why I want to build the railroad!” – Dean Kamen, channeling J.P. Morgan

“Balance is a bad word. Work-life balance: what does that mean? Don’t balance work and life — integrate them.” – Me

“The truth is that promoting science isn’t just about providing resources — it’s about protecting free and open inquiry. It’s about ensuring that facts and evidence are never twisted or obscured by politics or ideology. It’s about listening to what our scientists have to say, even when it’s inconvenient — especially when it’s inconvenient.” – Obama [Also applies to intellectual honesty in startups.]

“Apple doesn’t make four billion semiconductors. Apple is only its ideas — which is only its people.” – Steve Jobs

“I would like to make the case for the ‘magic’ of management theory. Imagine a world where some scientists know Maxwell’s equations and others don’t. The scientists who know Maxwell’s equations can predict the future. Those who don’t are lost in the wilderness. That’s the world we live in today when it comes to the ‘equations’ of management and organizations. People who understand Peter Drucker and lean manufacturing are magicians compared to those who don’t. Or, at least, they have the potential to be magicians — unfortunately, you still have to wake up in the morning and do the work.” – Me

“The most prevalent loss to the economy doesn’t come from the planned crime, it comes from the little fudging that good people do just by a little bit.” – Dan Ariely

“One should guard against preaching to young people success in the customary form as the main aim in life. The most important motive for work in school and in life is pleasure in work, pleasure in its result, and the knowledge of the value of the result to the community.” – Einstein

“Valuations are down because investors want them to be down. Because, really, what else could it possibly be?” – Me

You can find many more of these quotes on Twitter and FriendFeed.

Check out our new archives. They look like this:

We’ve gone through every single one of our 142 posts and (1) renamed some, so they summarize their contents more effectively and (2) filed all of them in the appropriate categories. Most of the posts are filed in more than one category.

If you’re just getting started, check out our posts on starting up, lawyers, and pitching. If you’re negotiating a term sheet, you might like our posts on auctions, boards of directors, and vesting. If you’re busy executing, check out our posts on lean and advisors.

The archives contain 75 categories in alphabetical order and, within each category, posts are in chronological order.

The old archives will stay online, but they’ve been out-of-date for quite a while and are now deprecated.

So, how can we make our archives more useful to you?

The number and quality of comments on Venture Hacks is steadily increasing. This is most awesome; we really like comments. Thanks for commenting and please keep ’em coming. We read and moderate every one.

So prospective contributors don’t have to comment into a black hole, we’ve adapted these moderation guidelines from Edward Tufte’s epic thread on Moderating internet forums:

1. Accept comments with good spelling, grammar, and formatting; that advance the quality of the discussion; and are civil. Focus on the quality of the discussion for the reader—whether a comment agrees or disagrees with us is irrelevant (of course).
2. Silently and lightly correct minor spelling errors, punctuation errors, or poor formatting in otherwise good comments.
3. Let the quality of the posts and existing comments serve as a standard for new comments.
4. Don’t accept partially meritorious comments if the overall effect of the comment is to lower the quality of the discussion.
5. Quickly make final decisions about whether we’re going to accept a comment.
6. Delete accepted comments if we later decide they don’t advance the quality of the discussion.
7. Try to follow these guidelines when we write posts on Venture Hacks or comment on other sites.
8. Thank commenters and highlight good comments.

What do you think? Are we missing anything?

Related: Edward Tufte’s Moderating internet forums.

Raising money is like finding a black swan.

It seems like you will forever keep hearing “no”, “let’s keep talking”, or “find a lead.” Or worse, you sign a term sheet and it blows up before you can close it.

It seems like you’ll never raise money, until one day—boom—you meet the right investor, he says yes, you negotiate a deal, and suddenly there’s money in your bank account.

What’s a black swan?

A black swan is a highly improbable, high impact, and unpredictable event. Nassim Nicholas Taleb popularized the idea in his book, The Black Swan: The Impact of the Highly Improbable.

9/11 was a black swan. It was hard to predict, it was highly improbable, and it changed the world—black swans define the future.

Once you see enough white swans, you start assuming all swans are white—until you see a black one. Once you get enough nos, you start assuming every investor will say no—until you get a yes.

The nos don’t matter.

The chances of raising money are low. You don’t know when or if it will happen, who will invest, or how much you will raise.

(The exception to this rule are the chosen ones: “obviously” fundable companies that are founded by successful entrepreneurs, companies that are making money by the truck load, or have cured cancer, or whatever.)

There will be no precedent for a yes. If someone looks at your string of nos, they won’t suggest that you’ll get a yes tomorrow—they’ll predict more nos. But just because you’re getting a lot of nos today doesn’t mean you will get a no tomorrow. The past is an indicator of the future—up until the moment you find a black swan.

If you’re looking for a black swan, ignore the nos.

Searching for black swans can be a big waste of time.

I’ve seen an entrepreneur sleep on my couch for months while he tried to raise money. It seemed like he had no hope—until he suddenly raised money from Big Firm X.

Many entrepreneurs implicitly understand this. They know that raising money is rare, unpredictable, and important to their business. So they spend months and months searching for a black swan.

But perpetual fund-raising is a bad way to raise money. Investors like to invest in working businesses—which means you need to work on the business—not spend the next 6 months raising money.

The problem with black swan processes is that they don’t always yield black swans. Sometimes they just give you white swans until you or your company dies. Black swans aren’t guaranteed—they’re the opposite of guaranteed: low probability and unpredictable.

How to find black swans.

Here are a few ways to search for black swans:

1. The Chosen One Strategy: Wait until you’re obviously fundable before you raise money. Keep building value until investors come to you.
2. The Hobby Strategy: Keep working on the business while you raise money as a hobby. Spend less than 25% of your time fund-raising so you can focus on activities that have a greater chance of creating value.
3. The Efficient Strategy: Raise money full-time and test the market very efficiently through focus, timeboxes, and lessons learned.

The Chosen One strategy is the best if you don’t need the money right now. Instead of trying to solve the black swan problem, this strategy dissolves it. If you do need the money right now, stop and seriously think about how to build the business without the money—remember, fund-raising is low probability and unpredictable if you’re not one of the chosen ones.

The Hobby strategy is awful. Don’t even bother—just work on the business instead. Raising money is a full-time job for at least one of the founders. If possible, also get your co-founder on the job part-time, so you can pair, like detectives trying to solve a crime.

The Efficient strategy is the best way to find black swans if you can’t or won’t execute the Chosen One strategy. There are three pieces to this approach: focus, timeboxes, and lessons learned.

1. Focus

Raise money full-time.

Pick up the phone and get introductions to investors from middlemen. Call in every favor you have and explain why the middleman will look good by making an introduction. Get the middleman to focus on making a single great introduction. Three weak email introductions won’t do anything but one strong phone call might.

This is a lot of work just to get 10 or 15 introductions. And you haven’t even met any investors yet. That’s why we say fund-raising is a full-time job.

2. Timebox

Put time limits on each step of the fund-raising process.

If you aren’t getting good introductions in 1-2 weeks, quit fund-raising and start executing Plan B. If you aren’t getting good meetings in 3-4 weeks, quit fund-raising and start executing Plan B. If you aren’t doing partner’s meetings in 5-6 weeks, quit fund-raising and start executing Plan B. If you aren’t signing a term sheet in 7-8 weeks—you know what to do.

And don’t start raising money until you have a Plan B—a Plan B is the simplest way to create a deadline and scarcity by fiat.

3. Lessons Learned

As you raise money, get honest, high-quality feedback from investors, advisors, etc. Once you get enough feedback and nos, stop raising money, fix your team, product, market, and traction, and try again.

It’s hard to get high-quality feedback from anyone period. Most people, even effective ones, don’t give good advice. Honest feedback from investors is particularly hard because they don’t like calling your baby ugly.

Try saying something like this when you get a no:

“Thanks. Yeah, I completely understand. We want to make this business work. What would we have to accomplish to make this business interesting to you?”

Optimism

One more thing. Optimism: you can’t raise money without it. The most effective way to stay optimistic is to find the right wife for your startup (also known as a co-founder).

Fund-raising isn’t a part-time job. It’s a black swan that you should avoid entirely or chase efficiently with focus, timeboxes, and lessons learned.

What do you think?

Thanks to Charles River Ventures for sponsoring Venture Hacks.

After our first post on CRV’s sponsorship, people suggested we make the sponsorship more “real”. We are down with that.

So here’s an e-mail that George Zachary from CRV sent me—I’m sharing it with his permission. It gives a good sense that CRV is “open for business”:

From: George Zachary
To: Nivi
Date: Thu, Nov 6, 2008

Nivi,

Sorry for the delay amigo.  Just been s-w-a-m-p-e-d with 3 new investments for CRV in the last 2-3 weeks. We are closing docs on one of them today/tomorrow.  I issued a term sheet on another last Friday that’s now signed and in major diligence/docs mode.  And just about to shake hands on a 3rd probably tomorrow.   All are consumer internet.

Probably the busiest 2-3 week period I have ever had since 1995 in venture.

Also, prepping for my annual LP meeting in Boston which runs from this coming Monday through Wednesday.  So, swamperoo’d.

Apologize on the delay.

The text looks good with one exception.  “Initial investment can be as small as $100K…”  instead of the $25K.

Thank you for doing this!

What is new with you?

Thank you and sorry for my humongous delay,
George

“We do use agile methodologies at Heroku—I developed my own (informal) style of agile at the last company I founded, and brought that forward to this venture.”

– Adam Wiggins, Founder, Heroku

I first learned about lean startups in an excellent book called Agile Software Development—learn more about it in our review.

The second step in my lean journey was a book called Extreme Programming Explained. It is dirt cheap (you can buy the first edition for a penny) and the entire book is accessible to non-programmers. If you buy it, try to get the first edition—the second edition isn’t as good as the first.

The subtitle of this book is “Embrace Change”—here are a few excerpts to whet your appetite…

The Driving Metaphor

“Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way.

“This is the paradigm for Extreme Programming (XP). Stay aware. Adapt. Change.

“Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change.”

What is XP?

“To some folks, XP seems like just good common sense. So why the “extreme” in the name? XP takes commonsense principles and practices to extreme levels.

• If code reviews are good, we’ll review code all the time (pair programming).
• If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
• If design is good, we’ll make it part of everybody’s daily business (refactoring)…
• If integration testing is important, then we’ll integrate and test several times a day (continuous integration).
• If short iterations are good, we’ll make the iterations really, really short—seconds and minutes and hours, not weeks and months and years (the Planning Game).

“When I first articulate XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.”

What XP promises

“To programmers, XP promises that they will be able to work on things that really matter, every day. They won’t have to face scary situations alone. They will be able to do everything in their power to make their system successful.  They will make decisions that they can make best, and they won’t make decisions they aren’t best qualified to make.

“To customers and managers, XP promises that they will get the most possible value out of every programming week. Every few weeks they will be able to see concrete progress on goals they care about. They will be able to change the direction of the project in the middle of development without incurring exorbitant costs.”

If you’ve already read this book, please let us know how you liked it. And if you haven’t, what are you waiting for?

Here are the latest and greatest posts from Twitter (RSS) and FriendFeed (RSS). We use FriendFeed for the longer stuff and Twitter for the shorter stuff!

On specialization in lean startups:

“Specialization is for insects.” – Robert Heinlein

“Break the ‘union mindset’ of specialization. Ask everyone to attack the bottleneck wherever it is.” – Bernie Thompson

Kayak’s CEO on stealing a page out of Google’s playbook:

Steve Hafner: “[At Kayak], we are of the mentality that for every dollar which could be placed into marketing we would rather place it into engineering and make the product better…”

Sramana Mitra: “So you have built traction [for Kayak] with organic word of mouth?”

Steve Hafner: “It is a page out of Google’s playbook. Build a great technology, syndicate that out to other affiliates like AOL who already have audience and then keep innovating on the product to make folks come back to you directly.”

(From Entrepreneur Journeys Volume 1)

Zappos‘ CEO on culture over customer service:

“Your company culture and your company’s brand are really just two sides of the same coin… You may think that our number 1 priority [at Zappos] is customer service but it’s actually not. Our number 1 priority for the company is company culture… The reason why we ended up selling [LinkExchange]… it wasn’t a fun place to go to work for anymore… we didn’t know… to look for culture fit when we hired people.” – Tony Hsieh

Random stuff:

“90% of the salespeople out there are below average because performance is a curve, not a line.” – Seth Godin [Good advice for any group, not just salespeople!]

“A lot [of] what’s written about Silicon Valley… is actually part of a sales pitch… for the venture ecosystem.” – Sean Murphy

“Spending our cash is the same as spending our equity.” – Jason Goldberg

I just finished reading Certain to Win. It’s about the warfare strategy of John Boyd, as applied to business. In war, you build your team and dismantle the enemy. In business, you build your team, delight the customer, and incidentally dismantle the enemy.

You might know John Boyd as the OODA Loop guy. I never really “got” the OODA Loop so, based on Eric Ries’ recommendation, I read this book.

In a software startup, the OODA Loop looks like this: (1) Come up with an idea, (2) Code it, launch it, (3) Learn from usage data. Keep repeating the loop, each time using the Learnings to influence your next idea. This is the Idea-Code-Data loop.

As you eliminate waste in a lean startup, you can repeat the loop at a higher tempo than the competition; serve customers more effectively; and incidentally sow panic, paralysis, and surrender in the competition. For example, the Obama campaign used high tempo OODA Loops to win the most “market share” in the 2008 presidential election.

This might seem abstract or too obvious to be useful, so here are some of my favorite passages from the book—they should fill in some of the puzzle.

On agility and playing chess with half the pieces:

“Go find the best chess player you can and offer to play for $1,000 under the following conditions:

• Your opponent moves first
• You move twice for every move of his or hers.

“In fact, you can even offer to give up some pieces, to make it more fair. You will find that, unless you are playing somebody at the grandmaster level, you can give up practically everything and still win. Keep the knights and maybe a rook.

“This is a graphic illustration of how the smaller side, using agility, can overcome a large disadvantage in numbers. Does it strike you as far-fetched and removed from what happens in the real world? Consider that Honda and Toyota can bring out a new model in roughly 2 years, with superb quality, while it still takes Detroit at least a year longer…

“The idea that operating at a quicker time pace than one’s opponent can product psychological effects offers a way out of the “bigger (or more expensive) is better” syndrome. An opponent who cannot make decisions to employ his forces effectively—his command and staff functions become paralyzed by bickering and bureaucracy, for example—is defeated before the engagement begins, no matter how many weapons sit in his inventory. In this way, one could truly achieve Sun Tzu’s goal of winning without fighting. [Ed: If you move fast enough, every enemy is effectively incompetent.]“

On shaping the market through agility:

“With a strategy this powerful, your aim is not to respond to but to create the market conditions that you want…

“Customers often want things because competitors have dangled them in their faces… such “discovery of customer wants” does not provide the basis for strategy; it represents a failure of strategy…

“The essence of Boyd’s strategy in business competition is to shape ourselves and the marketplace to improve our capacity… to survive on our terms—generally at the expense of our competitors.”

On planning and strategy:

“Strategy is merely a scheme for creating and managing plans…

“There is nothing wrong with planning… generate and discard many of them as you cycle within your OODA loops.”

On not following the rules:

“The Americans would be less dangerous if they had a regular army.” – British General Frederick Haldimand, Boston, 1776

On culture as a long-term competitive advantage:

“Herb Kelleher, chairman and recently retired CEO of Southwest Airlines, brags that competitors could copy the details of his sytem—direct (as opposed to hub-and-spoke) routings, no reserved seats or meals, one type of aircraft, etc.—but they couldn’t copy the culture, the vibrant esprit de corps, because “they can’t buy that.” So far his words have been prophetic, at least as far as the other US major airlines are concerned.”

Related: Mike Cassidy: Speed as THE primary business strategy

“We can acquire knowledge from doing something incorrectly, but only if we can determine the cause of the error and correct it.”

– Russell Ackoff

Summary: It’s never too late to start applying five whys, even if you’re saddled with zillions of lines of legacy code. Just start asking why whenever you find a problem—you’ll automatically start fixing the 20% of underlying issues that cause 80% of your problems. Five whys was first discovered by Toyota—if it can work for cars, it can work for you.

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.

In Part 1, I described how to use five whys to discover the root cause of problems, make corrections, and build an immune system for your startup. In Part 2, I explained how to get started with five whys and how IMVU built a startup immune system by applying five whys for months and years. In this final part, I’ll describe how to apply five whys to legacy startups.

It’s never too late to start asking why.

When I explain five whys to entrepreneurs and big-company types alike, I sometimes get this response: “Well, sure, if you start out with all those great tools, processes and TDD from the beginning, that’s easy! But my team is saddled with zillions of lines of legacy code and… and…”

So let me say for the record: we didn’t start with any of this at IMVU. We didn’t even practice TDD across our whole team. We’d never heard of five whys, and we had plenty of “agile skeptics” on the team. By the time we started doing continuous integration, we had tens of thousands of lines of code that wasn’t under test coverage.

But the great thing about five whys is that it has a Pareto principle built right in. Because the most common problems keep recurring, your prevention efforts are automatically focused on the 20% of your product that needs the most help. That’s also the same 20% that causes you to waste the most time. So five whys pays for itself awfully fast, and it makes life noticeably better almost right away. All you have to do is get started.

If it works for cars, it can work anywhere.

So thank you, Taiichi Ohno. I think you would have liked seeing all the waste we’ve been able to drive out of our systems and processes, all in an industry that didn’t exist when you started your journey at Toyota.

And I especially thank you for proving that this technique can work in one of the most difficult and slow-moving industries on earth: automobiles. You’ve made it hard for any of us to use the most pathetic excuse of all: “Surely, that can’t work in my business, right?” If it can work for cars, it can work for you.

What are you waiting for?

“For every dollar spent in failure, learn a dollar’s worth of lesson.”

– Jesse Robbins, Amazon’s former Master of Disaster

Summary: Get started with five whys by applying it to a specific team with a specific problem. Select a five whys master to conduct a post mortem with everyone who was involved in the problem. Email the results of the analysis to the whole company. Repeatedly applying five whys at IMVU created a startup immune system that let our developers go faster by reducing mistakes.

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.

In Part 1, I described how to use five whys to discover the root cause of problems, make corrections, and build an immune system for your startup. So…

How do you get started with five whys?

I recommend that you start with a specific team and a specific class of problems. For my first time, it was scalability problems and our operations team. But you can start almost anywhere—I’ve run this process for many different teams.

Start by having a single person be the five whys master. This person will run the post mortem whenever anyone on the team identifies a problem.

But don’t let the five whys master do it by himself; it’s important to get everyone who was involved with the problem (including those who diagnosed or debugged it) into a room together. Have the five whys master lead the discussion and give him or her the power to assign responsibility for the solution to anyone in the room.

Distribute the results of five whys to the whole company.

Once that responsibility has been assigned, have that new person email the whole company with the results of the analysis. This last step is difficult, but I think it’s very helpful. Five whys should read like plain English. If they don’t, you’re probably obfuscating the real problem.

The advantage of sharing this information widely is that it gives everyone insight into the kinds of problems the team is facing, but also insight into how those problems are being tackled. If the analysis is airtight, it makes it pretty easy for everyone to understand why the team is taking some time out to invest in problem prevention instead of new features.

If, on the other hand, it ignites a firestorm—that’s good news too. Now you know you have a problem: either the analysis is not airtight, and you need to do it over again, or your company doesn’t understand why what you’re doing is important. Figure out which of these situations you’re in, and fix it.

What happens when you apply five whys for months and years?

Over time, here’s my experience with what happens.

People get used to the rhythm of five whys, and it becomes completely normal to make incremental investments. Most of the time, you invest in things that otherwise would have taken tons of meetings to decide to do.

You’ll start to see people from all over the company chime in with interesting suggestions for how you could make things better. Now, everyone is learning together—about your product, process, and team. Each five whys email is a teaching document.

IMVU’s immune system after years of five whys.

Let me show you what this looked like after a few years of practicing five whys in the operations and engineering teams at IMVU. We had made so many improvements to our tools and processes for deployment, that it was pretty hard to take the site down. We had five strong levels of defense:

1. Each engineer had his/her own sandbox which mimicked production as close as possible (whenever it diverged, we’d inevitably find out in a five whys shortly thereafter).
2. We had a comprehensive set of unit, acceptance, functional, and performance tests, and practiced TDD across the whole team. Our engineers built a series of test tags, so you could quickly run a subset of tests in your sandbox that you thought were relevant to your current project or feature.
3. 100% of those tests ran, via a continuous integration cluster, after every checkin. When a test failed, it would prevent that revision from being deployed.
4. When someone wanted to do a deployment, we had a completely automated system that we called the cluster immune system. This would deploy the change incrementally, one machine at a time. That process would continually monitor the health of those machines, as well as the cluster as a whole, to see if the change was causing problems. If it didn’t like what was going on, it would reject the change, do a fast revert, and lock deployments until someone investigated what went wrong.
5. We had a comprehensive set of nagios alerts, that would trigger a pager in operations if anything went wrong. Because five whys kept turning up a few key metrics that were hard to set static thresholds for, we even had a dynamic prediction algorithm that would make forecasts based on past data, and fire alerts if the metric ever went out of its normal bounds. (You can read a cool paper one of our engineers wrote on this approach.)

A strong immune system lets you go faster by reducing mistakes.

So if you had been able to sneak into the desk of any of our engineers, log into their machine, and secretly check in an infinite loop on some highly-trafficked page, somewhere between 10 and 20 minutes later, they would have received an email with a message more-or-less like this:

“Dear so-and-so, thank you so much for attempting to check in revision 1234. Unfortunately, that is a terrible idea, and your change has been reverted. We’ve also alerted the whole team to what’s happened, and look forward to you figuring out what went wrong. Best of luck, Your Software.”

OK, that’s not exactly what it said. But you get the idea.

Having this series of defenses was helpful for doing five whys. If a bad change got to production, we’d have a built-in set of questions to ask: Why didn’t the automated tests catch it? Why didn’t the cluster immune system reject it? Why didn’t operations get paged? And so forth.

And each and every time, we’d make a few more improvements to each layer of defense. Eventually, this let us do deployments to production dozens of times every day, without significant downtime or bug regressions.

In Part 3, I’ll show you how to apply five whys to “legacy” startups.

You’ll probably learn more from this clip than two years at Harvard Business School. From HBO’s The Wire:

(Video: The Wire)

I bet you didn’t know this is Obama’s favorite TV show.

“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.

“We are using Pivotal Tracker to manage all of our new web apps under development, this thing rocks.”

– Ezra Zygmuntowicz, Founder, Engine Yard

“It’s a relief to open Tracker at the start of the day and focus on the next most important task.”

– Aaron Peckham, Founder, Urban Dictionary

No matter what you’re using for project management, take a close look at Pivotal Tracker. I’ve tried Bugzilla, Trac, Basecamp, FogBugz, Microsoft Project, and Lighthouse—and Tracker is the best for my needs. I’ve shown Tracker to many startups and many have made the switch.

10 reasons I like Tracker.

1. It’s free.
2. It’s hosted.
3. It’s a joy to use. It’s the iPod of project management software. It’s all drag-and-drop and clickity-clack and it just works.
4. It’s multi-user. Your co-founder in North Korea can make changes in Tracker and you will see them instantly. No page reloads.
5. It’s for lean startups. The building block in Tracker is a story: an increment of customer value that you deliver with minimal waste.
6. It’s about completing your next most important task—not maintaining mile-long to-do lists, Gantt charts, and lists of bugs.
7. It’s transparent. Everybody on the team knows what everybody else is working on, their priorities, and their accomplishments.
8. It’s in sync with reality. It doesn’t take time to keep your requirements and schedule in sync with reality, even if your business priorities change daily.
9. It doesn’t do much. No, it doesn’t do dependencies and critical paths. It just keeps you focused on delivering value to customers.
10. It’s powerful as hell. Tracker hides a lot of technology under a simple interface. It’s a serious Javascript-intensive web application that’s in the same league as Gmail and Google Maps.
11. Bonus reason: Everything is on one page—there’s no need to navigate around (unlike other project management tools). More Gmail, less Hotmail.

If it isn’t clear by now, Tracker isn’t a bug manager posing as project management software.

If you’re already lean, Tracker is a no-brainer. If you’re not lean, Tracker is a good way to start getting lean.

What do other folks say about Tracker?

Read the testimonials from people who are using Tracker. I particularly like this one from Aaron Peckham, the founder of Urban Dictionary:

“I leave Tracker open all day. I use it for documenting, estimating and prioritizing things that need to be done. It’s a relief to open Tracker at the start of the day and focus on the next most important task. It keeps me from getting distracted and having too many things going at the same time. It also serves as documentation of what I’ve completed in the past—to show that I’m making good use of my time.”

Want more opinions? See what people are saying about Pivotal Tracker on Twitter.

What do you think about Tracker?

If you give Tracker a try, please let us know what you think!

We’ve updated the presentation in A quick and dirty guide to starting up. The new presentation includes the notes that accompany each slide.

I’ve also included the new presentation below. Watch it in full screen mode for maximum pleasure. The full screen button is at the bottom right of the embed and it looks like this: .

(Slides: A Quick And Dirty Guide To Starting Up (pdf))

Here are some of my favorite quotes from the presentation:

“We are faced with insurmountable opportunities.” – Pogo

The most important thing: idea intelligence connections experience determination.

Ideas, and therefore NDAs, are worthless.

“… as in all matters of the heart, don’t settle.” – Steve Jobs, on picking co-founders

Co-founders are the biggest failure mode for startups.

“If you are facing in the right direction, keep walking.” – Buddha, on focusing your time in a startup

Markets are relatively efficient, so your first product is probably wrong.

We’ve updated the presentation in Our top 10 term sheet hacks. The new presentation includes the notes that accompany each slide.

I’ve also included the new presentation below. Watch it in full screen mode for maximum pleasure. The full screen button is at the bottom right of the embed and it looks like this: .

(Slides: Top 10 Term Sheet Hacks (pdf))

We use Twitter (RSS) to share great quotes, brief thoughts, and links. If you like this blog, you’ll like our Twitter feed. Here are some of the latest and greatest tweets:

Epic post on how to demo from Wufoo: How We Prepare a Demo.

Startup compensation studies from 2008 and 2007 for IT and Life Sciences.

What the office of a lean startup looks like: An XP Team Room.

“Revenue… first… then… traction… is the safest way to grow a business but also the hardest move to make.” – Fred Wilson

“Write a blog, not a business plan.” – Dharmesh Shah

Don’t start a company if you’re not willing to start another one if this one fails. You can’t land on the moon with one shot.

In fund-raising, the exam comes before the lesson. Exam = Term sheet. Lesson = The multi-year consequences of the deal.

How to use an audience to get your way when you’re negotiating.

FriendFeed (RSS) is another good place to get more Venture Hacks in your life. Here are some of the latest and greatest from FriendFeed:

“IMVU… shipped in 6 months. Charged from day 1. No press releases. Shipped 20 times a day. 2007 revenues of $10M.” - Steve Blank and Eric Ries

“You’re going to have a hard enough time convincing your management team to work on the problem that you’ve decided to pursue, let alone having competitors go steal your idea and do the exact same thing.” – Dharmesh Shah

We’re going to try something new here: sponsorships. We hope this experiment will be effective for you and our sponsors. Send us your feedback.

We would like to welcome our first sponsor, Charles River Ventures. And I would like to thank George Zachary from CRV for working with me to get this done. You’ll find the sponsorship near the top right of our website. It looks like this:

You’ll also see occasional messages from our sponsors in our blog and Twitter feeds.

If sponsorships are useful to our readers, they’ll be useful to our sponsors. And if they’re not useful to you, they won’t be useful to our sponsors. Let us know what you think as this experiment progresses.

Here’s a message from CRV that describes what they do and how they do it:

“CRV’s approach to investing is simple: we seek out visionary entrepreneurs, and give them the support they need to build great companies from the ground up. It’s our job to enable startups. Not second-guess them.

“Our initial investment can be as small as $100,000, or as large as $5 million. The bulk of our investments have been to companies with fewer than 10 employees—many have as few as 2 or 3. We don’t require a complete management team, since we can often help in bringing the right talent to the mix.

“Unlike many venture firms, we don’t lurk on the sidelines waiting for a strong lead investor to step up. When we believe in a project, we want to be the lead investor.

“The best way to get our attention is not with a 100-page business plan. A concise executive summary, an expense budget for the first two years, the revenue model, and a PowerPoint presentation are the materials we’re interested in seeing. It helps if one of our portfolio companies, or a member of our contact network recommends you.

“Since 1970, we have helped startups turn their ideas into real, viable businesses. Companies like Cascade, CIENA, ChipCom, NetGenesis, Parametric Technology, Sonus, Speechworks, Stratus Computer, Sybase, Vignette and dozens more have realized stunning success with our backing and support.

“But our greatest successes, we believe, are the ones that lie ahead.”

William Pietri left a great comment on Books for Entrepreneurs: Agile Software Development (emphasis added):

“Great to see these approaches getting more attention in the startup world. I’ve been soaking in both agile methods and startup companies a long time, and I think they go perfectly together. They provide just enough structure to make everybody effective, without unnecessary constraints or process bloat.

“One of my clients, sidereel.com started with an XP-ish process from the first week. They had an alpha for investors in 2 months, a private beta in 3, and a public beta in 4 months. Now they’re happily funded, up to a dozen people, and just shy of Alexa 1000 site. Weekly iterations meant they always had new progress to show potential investors. And being able to change direction easily meant they could try a lot of things out and invest heavily in areas the users liked.

“Speaking of which, I and a colleague are interested in trying out some variations of the Planning Game with a couple of user-focused startups. If any VH readers want to be guinea pigs, we’re looking for Bay Area teams that are early in the process, actively struggling to put together a product plan, and have both business and technical people involved full time. If there’s anybody here that meets those criteria, just drop me a line. My email address is my first name at my domain name [scissor.com].”

Also check out An XP Team Room, where William walks us through the offices of a lean startup in gory detail:

“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 this 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)

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!