The following is an excerpt from HBS Professor Noam Wasserman’s new book, The Founder's Dilemmas: Anticipating and Avoiding the Pitfalls That Can Sink a Startup. Noam is one of a rare breed of business academics: he studies entrepreneurship using a rigorous empirical approach. The book taps Noam’s analyses of data on 10,000 founders, plus the personal stories of Evan Williams of Twitter, Tim Westergren of Pandora, and two dozen other founders.

As an example of the kind of insight that this data makes possible, take a look at this diagram, which is one of my favorites in the whole book:
Noam calls this the Rich vs King tradeoff, and it's a remarkable finding. On average, the founders who keep the most control over their company make the least amount of money. As with any data-based result, this raises more questions than it answers. For example, most entrepreneurs know that the most successful entrepreneurs - from Bill Gates to Jeff Bezos - kept tight control over their companies. We therefore seek to emulate their approach, to our own detriment, because we're often emulating the wrong things. Having the real facts helps us ask better questions. We should be asking not "how much control did Bill Gates seek?" but rather "what else is exceptional about his decisions that allowed him to escape the more common fate?" If you're interested in answering questions like this, read on.

I was lucky enough to get to read a version of the book when it was still in draft form. Now that the final version has come out, I'm excited to share a bit of it with you. At the time, I was asked to give an official endorsement of the book. Here's what I said: 

"If you're starting a new company, you probably already know that a crazy variety of landmines await you. What if you had a map that showed exactly where they are and how to avoid them? Having seen these dilemmas derail countless startups, I wish every entrepreneur and prospective founder would read this book." - Eric

The following is an exclusive excerpt which sets up a common pitfall regarding equity splits. In Noam’s dataset, 73% of founding teams split equity within a month of founding, a striking number given the big uncertainties early in the life of any startup. The majority of those teams set the equity in stone by failing to allow for future adjustments to equity stakes if there are major changes within the team or the startup.

After this excerpt, the book outlines specific solutions that help founders avoid this pitfall.

Setting the early equity split in stone is one of the biggest mistakes founders can make. With their confidence in their startup and themselves, their passion for their work and their mission, and their desire not to harm the fragile dynamic within the nascent founding team, cofounders tend to plan for the best that can happen. They assume that their early, high levels of commitment will last long into the future, rather than waning as the challenges of founding begin to sap their passion for the idea and for each other. They assume that no adverse events will change the composition of the team.They also tend to take a very short-term view of the factors that should affect equity splits. They assume that the tasks that they are performing during the early stage of startup development are the same tasks that will be performed during the next and very different stages. They assume that their skills will remain as valuable to the startup as they are right now. They overestimate the amount of value that they will build in the first months compared to the value they hope to build over the subsequent years, and thus overweight their past contributions compared to the future contributions that will be required of them. Each founder places more value on his or her own contributions than on the contributions of the other cofounders,knowing the cost and extent of his or own efforts in a way that he or she cannot know the cost and extent of others’ efforts.

But such a best-case approach is hazardous. Uncertainties abound. At the company level, founders learn about the flaws in their initial plans and adjust the startup’s strategy, business plan,and business model. Professor Scott Shane reports that “almost half(49.6 percent) of new firm founders indicated that their business ideas [had] changed between the time they first identified them and the time when they were surveyed about them.” Such adjustments can cause major changes in the obstacles that the startup faces, the skills needed to address those obstacles, and thus the roles that each founder (or perhaps a new founder or a nonfounder) will have to play in building the startup.

At the individual level, as the strategy and business model shift,the skills of some founders become more important than the skills of others and roles often shift. As each founder learns about the demands of building a startup, reflects on his or her motivations,and sees how well his or her abilities address the startup’s needs, his or her commitment to the startup may change. The founders also come to understand each other’s abilities and commitment at a far deeper level than was possible at the beginning. Yet founders tend to overestimate how much value they will build during those early days, which can cause even bigger problems when a cofounder’scontributions wane later on.

A founder’s personal life may also affect his or her commitment and contributions. At Ockham Technologies, all of the founders were aware of the imminent arrival of idea-person Ken’s first child. However, even Ken was unsure how this would affect his willingness to quit his full-time job and focus on building Ockham.Extreme and unexpected health problems can catch all parties by surprise. For instance, while Microsoft was still a private company, cofounder Paul Allen was diagnosed with Hodgkin’s lymphoma,which caused him to quit the company, leaving Bill Gates as the sole active founder during the crucial three years before it became a public company.

In such ways, even the most comfortable equity split can be thrown into disarray. For instance, when Robin Chase and her partner, Antje, founded the car-sharing startup Zipcar, they agreed with a quick handshake to split the equity 50–50. The team believed it had avoided destructive tension over the equity split and could now focus on building the startup. “We shook across the table,50–50,” Robin recalls, “and I thought ‘great.’” Robin had heard about other teams that had faltered because of tough equity-split negotiations, and she breathed a sigh of relief that she and Antjehad avoided such problems. Robin poured her heart and soul into the startup, making major contributions to its growth, and was fully expecting Antje to do the same. Antje, however, remained at her full-time job and, by the summer, was expecting her second child. Robin wondered when her partner would be able to become more involved, but, in the end, Antje never joined full-time. Knowing that Antje still owned the same percentage as she did ate away at Robin, who later reflected, “That was a really stupid handshake, because who knows what skill sets and what milestones and what achievements are going to be valuable as you move ahead. That first handshake caused a huge amount of angst over the next year and a half.” Eventually Antje left the company altogether while continuing as a shareholder.

The cost to fix such problems can be very high, ranging from Robin Chase’s “angst” to more tangible financial costs. At govWorks.com, founders Kaleil and Tom had a cofounder, Chieh,who put up $19,000, worked “after hours” for five months (he had kept his day job instead of joining govWorks full-time), and then dropped out. When the remaining cofounders were about to close their first round of financing, their potential funder, Mayfield, was not willing to close until Kaleil and Tom bought Chieh out and reclaimed his equity. The VCs were willing to do a $410,000 “sweetheart deal” to facilitate the buyout. However, Chieh wanted $800,000. Amid the pressure to close the round, Kaleiland Tom ended up settling with Chieh for $700,000, making up the $290,000 out of their own pockets. Kaleil felt he was “beingextorted.” Although the risks of this kind of outcome are real,teams often fail to address them proactively. In my dataset, half of the teams had neglected to include any dynamic elements (vesting, buyout terms, and the like) in their equity agreements, sentencing themselves to the same risks faced by the Zipcar and govWorks.com teams.     

How should founders deal with such developments? In short, by assuming when they do the initial split that things will change, even if the specific changes cannot be foreseen, and therefore structuring a dynamic equity split rather than the static splits used at Zipcar, govWorks, and many other startups. As important as it is to get the initial equity split right—by matching it as closely as possible thefounders’ past contributions, opportunity costs, future contributions, and motivations—it is equally important to keep it right; that is, to be able to adjust the split as circumstances change.

Copyright © 2012 by Princeton University Press. Reprinted by permission.
Read More »

I was very pleased to receive an advance copy of Venture Deals: Be Smarter Than Your Lawyer and Venture Capitalist the other day. After reading it, I've concluded that it's like having a super-mentor on your shelf.

I have been extraordinarily fortunate throughout my career to have been blessed with amazing mentors. Men like Will Harvey and Steve Blank have been there to help me, encourage me, and push me to do better. For any entrepreneur, these super-mentors are one of the secret weapons that can make a difference: answering difficult questions, making key introductions, or offering sage advice.

However, there is one thing that the best mentors do which is most important: they can help you figure out what the $@%@$ is going on. When things get really tricky, often we find ourselves asking the wrong questions, or not even knowing enough to ask.

When raising money, for example, you might think that most negotiations happen in a rational way, over just a few deal points that have a clear meaning. You might think that "company valuation" refers, naturally, to how much your company is - you know - valued. But this kind of thinking will get you in trouble fast. Because in reality, these negotiations hinge on hundreds of hidden factors, incentives, and sources of agency bias. Nothing is straightforward, especially if you haven't done it before. These are the moments when the truly great mentors stand out in their ability to cut through the BS and help you understand the motivations and systems that are driving seemingly incomprehensible behavior.

All of this is by way of saying that if you already have a mentor of the caliber of a Steve Blank or Brad Feld on speed-dial, you probably don't need to read Brad's new book Venture Deals.

What's that you say? You don't - or you're not sure? Well then, you absolutely, positively, without-any-doubt have to read Brad's new book Venture Deals. Here's why.

Book endorsements are a funny thing. I get asked all the time to endorse books, in the hopes that you all will buy them and read them. And I often want to help other authors, because I know just how hard it is to get people to give a new book a chance (you may have noticed that I've been pushing a certain book pretty hard lately).

But if you look at my past book reviews and the "recommended reading" widget in the sidebar on the right, you'll notice that I recommend very few books. That's because I have an iron-clad rule: I will not use this space to recommend any book that I do not personally believe will directly impact entrepreneurs in a positive way. This creates a lot of awkwardness, because so many people have sent me books that I genuinely like, but which I don't feel are appropriate to endorse.

I say all this because I want you to understand why I am writing this post. Brad Feld and I have a bit of a mutual admiration society going. He and I have worked together on the Startup Visa initiative. He's said nice things about me and my book. I think he's a great guy. I even contributed a chapter to his previous book, Do More Faster.

But none of that is enough to get me to recommend this new book, co-authored with Jason Mendelson.
In fact, when I received my advance copy, I was a little worried. I generally try and stay away from topics like "how to raise VC" or "how to sell your company" because the startup landscape is already saturated with tips and tricks. And reading a term sheet has all the entertainment value of watching dried paint get even drier.

But Venture Deals is quite a surprise: it's readable, engaging, and addresses issues way below the surface.

It is not a how-to manual or a collection of tips. It's an in-depth explanation of what the @$%$ is going on when an entrepreneur considers raising money or doing an M&A transaction. And even if you don't think you're going to do that for your startup, this is very valuable information to have - because you never know who might approach you in the future. This is a book you'll want to have handy, just in case.

I've dealt with a bunch of different kinds of investors over the years, from so-called "dumb money" all the way up. The hardest thing to understand when working with them is that they are subject to forces and incentives that are rarely disclosed openly. When I came to Silicon Valley, I was inducted into a body of accumulated wisdom about how to handle them. This is the same advice I hand down again to entrepreneurs who are seeking my counsel. That advice is completely consistent with what's contained in Venture Deals.

For example, the right way to think about a term sheet is as a negotiation over just two things: economics and control. Everything in a term sheet is negotiable - if and only if you already have sufficient leverage. (Do you know the sources of leverage in a VC deal? Wouldn't you like to?) There are many founder-friendly terms you can push for, from automatic acceleration to reduced vesting - but each risks reducing the alignment of interests between founders and investors. And even if you're an old pro at raising money, you're likely to find a few surprises in here. Are you sure you know the formula for how your VC reserves capital for your future rounds (I didn't)?

And even the most battle-tested entrepreneur would be forgiven if they were a little confused by the following bit of poetry in a term sheet:

Antidilution Provisions: The conversion price of the Series A Preferred will be subject to a narrow-based weighted average adjustment to reduce dilution in the event that the Company issues additional equity secuities...

Now even though us old pros know that there are different kinds of antidilution provisions, are you absolutely sure you remember which one is the good kind and which is the horrible kind that caused all those problems in 2001? Are you sure your lawyer will catch it if the formula isn't quite right? Wouldn't you rather be sure? I've lived through a crisis where a company's antidilution provisions kicked in and nobody could agree on how the formula was to be interpreted. I wish I'd had this book on my shelf back then.

Which brings me back to my claim at the top about having a super-mentor in book form. Venture Deals explains not just what to do but why it works that way.  Every VC term sheet I've ever seen has come with a claim that its terms are all "entirely standard" and "as simple as possible" - whether it was one page or a dozen pages long. That can be frustrating, but what do you do about it? Which terms really are standard for good reasons, which are standard for bad reasons, and which are just gotchas designed to skew the negotiation?

Venture Deals has negotiating tips, same as other books, but - much, much more importantly - its negotiating section is called What Really Matters? When you're in the thick of it, only a truly great mentor can tell you which provisions are negotiable, which are negotiable-but, and which are really non-negotiable. ("negotiable-but" means you can possibly win that fight, but it will damage your reputation in the process.)

Now, it's important to keep in mind that Brad and Jason are themselves VC's, albeit ones with an entrepreneur-friendly reputation. So you always have to take their advice - like anyone's - with a grain of salt. But they've thought of that, too. Throughout the book, they've given space for brief commentaries by an experienced entrepreneur, Matt Blumberg, CEO of Return Path. In several places he gives an important counterpoint to Brad and Jason's perspective. It's a combination that is unique to this book.

I hope all of you who are reading this - no matter where you live, no matter what kind of company you have - will one day get to make the pilgrimage to Sand Hill Road in Silicon Valley, or another famous startup hub. It's an exhilarating experience. But it's not without its risks. As the old saying goes, "watch your wallet." And bring your copy of Venture Deals.
Read More »

Brant Cooper and Patrick Vlaskovits have written a new book, The Entrepreneur’s Guide to Customer Development, which builds upon the foundational work of The Four Steps to the Epiphany, while improving accessibility, updating the ideas, and making it more actionable. I believe it is the best introduction to Customer Development you can buy.

As all of you know, Steve Blank is the progenitor of Customer Development and author of The Four Steps to the Epiphany. I have personally sold many copies of his book, and continue to recommend it as one of the most important books a startup founder can read. 

I used to give copies of Four Steps out to my employees, in the hopes that it would instantly indoctrinate them into the methodology of Customer Development. I just assumed that everybody would love the book as much as I did, and would instantly change their behavior based on what they read in a book. You can imagine how well that worked. Instead of that naive approach, I wish I'd had a book like this one, to help me figure out how to get started with customer development step-by-step. 

When I wrote a review of Four Steps on this blog in November, 2008, I did my best to be candid and warn of a few shortcomings:

And Steve is the first to admit that it's a "turgid" read, without a great deal of narrative flow. It's part workbook, part war story compendium, part theoretical treatise, and part manifesto. It's trying to do way too many things at once. On the plus side, that means it's a great deal. On the minus side, that has made it a wee bit hard to understand.

Brant and Patrick undertook a difficult challenge: to provide a generally accessible introduction to Customer Development, without diluting its impact or dumbing-down its principles. I think they've succeeded.

The Entrepreneur’s Guide is an easy read.  It is written in a conversational tone, doesn't take itself too seriously, and avoids extraneous fluff. It does a great job of laying out general principles and suggesting specific, highly actionable tactics. You can easily take from it whatever makes sense for your business, and leave the rest. And it's incredibly to-the-point: you can digest this book in a couple of hours.

While the customer development framework of Four Steps is universally relevant, The Entrepreneur’s Guide updates its practices for modern startups. Four Steps primarily centers its stories and case studies on B2B hardware and software startups. This new volume also tackles examples from the Internet and wireless startups of today, both B2B and B2C. And throughout, they maintain a thoroughly realistic take on the power - and limitations - of an entrepreneurship methodology:

Successful implementation of Customer Development, let alone simply believing in it, will not guarantee success for your business. Customer Development will help you – force you – to make better decisions based on tested hypotheses, rather than untested assumptions. The results of the Customer Development process may indicate that the assumptions about your product, your customers and your market are all wrong. In fact, they probably will. And then it is your responsibility, as the idea-generator (read: entrepreneur), to interpret the data you have elicited and modify your next set of assumptions to iterate upon.

Many “airport business books” urge entrepreneurs to never give in. They tell them to persist in their dream of building a great product and/or company, no matter what the odds are or what the market might be telling them – success is just around the corner. They tend to illustrate this sort of advice with inspiring stories of entrepreneurs who succeeded against all odds and simply refused to throw in the towel. While maintaining persistence and willpower is certainly good advice, Customer Development methodologies are designed to give you data and feedback you may not want to hear. It is incumbent upon you to listen.

The Entrepreneur’s Guide to Customer Development includes four powerful case studies/interviews with successful entrepreneurs who have taken iterative approaches to their respective startups that very much resemble the spirit of Lean Startups and Customer Development.  I found these to be particularly interesting and worthwhile.

At the heart of Brant and Patrick's interpretation of Customer Development is their belief that its fundamental teaching is to question assumptions. This gives them a hook with which to apply their ideas to a wide variety of situations. In other words, if particular examples in the book don’t apply to you directly, Brant and Patrick show you how to figure out what might work for you.  This is important, since every situation is different.  I'll give them the last word:

You are already skeptical of Customer Development and Lean Startups and the slew of emerging buzzwords and supple-to-the-point-of-meaningless terms. That’s great, more power to you; we applaud your skepticism. But be philosophically consistent: periodically take the time to question your own expertise and that of your friends, partners and investors. Make the effort to test your assumptions.

If there’s a shortcoming to this book, it’s that it focuses primarily on the Customer Discovery step in The Four Steps.  Here’s hoping they soon tackle Customer Validation. Well done, Brant and Patrick. I can't wait to see what's next. In the meantime, go buy a copy of The Entrepreneur´s Guide to Customer Development right now.

Read More »

If you've ever wondered why agile or lean development techniques work,The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen is the book for you. It's quite simply the most advanced product development book you can buy.


For those who hunger for a rigorous approach to managing product development, Donald Reinertsen's book is epic. Myths are busted on practically every page, even myths that are associated with lean/agile. For example, take the lean dictum of working in small batches. I push this technique quite often, because traditional product development tends to work in batches that are much too large. Yet it's not correct to say that batch sizes should be as small as possible. Reinertsen explains how to calculate the optimal batch size from an economic point of view, math and all. It's wonderful to have an author take these sorts of questions seriously, instead of issuing yet another polemic.

The book is structured as a series of principles, logically laid out and briefly discussed - 175 in all. It moves at a rapid clip, each argument backed up with the relevant math and equations: marginal profit, Little's law, Markov processes, probability theory, you name it. This is not for the faint of heart.

The use of economic theory to justify decisions is a recurring theme of the book. Its goal is to help us recognize that every artifact of our product development process is really just a proxy variable. Everything: schedules, efficiency, throughput, even quality. In order to trade them off against each other, we have to convert their impact into economic terms. They are all proxies for our real goal, maximizing an economic variable like profit or revenue.Therefore, in order to maximize the true productivity (aka profitability) of our development efforts, we need to understand the relationships between these proxy variables.

Just for the economic explanations, this book would be worth the price of admission. But it goes beyond that, including techniques for improving the economics of product development. Reinertsen weaves together ideas from lean manufacturing, maneuver warfare, queuing theory, and even the architecture of computer operating systems and the Internet. It's refreshing to see ideas from these different domains brought together in a coherent way:

If we limit ourselves to the relatively simple WIP [work-in-progress] constraints used in lean manufacturing, we will underexploit the power of WIP constraints. Instead, we will explore some of the more advanced ideas used in the world of telecommunications.

If we showed the Toyota Production System to an Internet protocol engineer, it is likely that he would remark, "That is a tail-dropping FIFO queue. That is what we started with on the Internet 30 years ago. We are now four generations beyond that method." I mention this to encourage you to look beyond the manufacturing domain for approaches to control flow.

Reinertsen is keenly aware of what makes product development different from other business functions, like manufacturing, that we sometimes use as a metaphor. Product development deals in designs, which are fundamentally intangible. This is why product development routinely creates disruptive innovation, because our ability to invent new products is limited only (well, primarily) by our capacity for imagination. And yet it is this same ephemeral nature that gives rise to the most difficult problems of product development: how to tell if we're making progress, the high variability of most product development tasks (e.g. will this bug take 5 minutes or 5 weeks to fix?), and the resulting extreme uncertainty that is, incidentally, the environment where startups thrive.

To motivate you to buy this book, I want to walk you through some of Reinertsen's indictment of the status quo in product development, which is based on his extensive interviews, surveys, and consulting work. He starts the book with twelve cardinal sins. See if any of these sound familiar:

1. Failure to correctly quantify economics.
2. Blindness to queues.
3. Worship of efficiency.
4. Hostility to variability.
5. Worship of conformance.
6. Institutionalization of large batch sizes.
7. Underutilization of cadence.
8. Managing timelines instead of queues.
9. Absence of WIP constraints.
10. Inflexibility.
11. Noneconomic flow control.
12. Centralized control.

Reinertsen is not pulling punches. For example, here's him discussing our collective blindness to queues:

To understand the economic cost of queues, product developers must be able to answer two questions. First, how big are our queues? Today, only 2 percent of product developers measure queues. Second, what is the cost of these queues? To answer this second question, we must determine how queue size translates into delay cost, which requires knowing the cost of delay. Today, only 15 percent of product developers know the cost of delay. Since few companies can answer both questions, it should be no surprise that queues are managed poorly today.

Or take this indictment of our worship of efficiency:

But, what do you product developers pay attention to? Today's developers incorrectly try to maximize efficiency ... Any subprocess within product development can be viewed in economic terms. The total cost of the subprocess is composed of its cost of capacity and the delay cost associated with its cycle time. If we are blind to queues, we won't know the delay cost, and we will only be aware of the cost of capacity. Then, if we seek to minimize total cost, we will only focus on the portion we can see, the efficient use of capacity.

This explains why today's product developers assume that efficiency is desirable, and that inefficiency is an undesirable form of waste. This leads them to load their porcesses to dangerously high levels of utilization. How high? Executives coming to my product development classes report operating at 98.5 percent utilization in the precourse surveys. What will this do? [This book] will explain why large queues form when processes with variability are operated at high levels of capacity utilization.

Or consider principle B9: The Batch Size Death Spiral Principle: Large batches lead to even larger batches:

The damage done by large batches can become regenerative when a large batch project starts to acquire a life of its own. It becomes a death march where all participants know they are doomed, but no one has the power to stop. After all, when upper management has been told a project will succeed for 4 years, it is very hard for anyone in middle management to stand up and reverse this forecast...

Our problems grow even bigger when a large project attains the status of the project that cannot afford to fail. Under such conditions, management will almost automatically support anything that appears to help the "golden" project. After all, they want to do everything in their power to eliminate all excuses for failure.

Have you had trouble buying a new piece of test equipment? Just show it will benefit the "golden" project and you will get approval. Have a feature that nobody would let you implement? Find a way to get it into the requirements of the "golden" projec. These large projects act as magnets attracting additional cost, scope, and risk...

At the same time, large batches encourage even larger batches. For example, large test packages bundle many tests together and grow in importance with increasing size. As importance grows, such test packages get even higher priority. If engineers want their personal tests to get high priority, their best strategy is to add them to this large, high-priority test package. Of course, this then makes the package even larger and of higher priority.

This snippet is characteristic of Reinertsen's writing style and reasoning. He shows how the actions of people inside traditional systems are motivated by their rational assessment of their own economics. By setting up the wrong incentives, we are rewarding the very behaviors that we seek to prevent. Reinertsen has a visceral anger about all that waste, and his stories are crackling with disdain for the people who manage such systems - especially when their actions are motivated by intuition, voodoo, or blindness. Startups are frequently guilty as charged - the 4-year death march example above could be written about dozens of venture-backed companies slogging it out in the land of the living dead.

Reinertsen does not speak about startups specifically - his book is meant to speak broadly to product development teams across industries and sectors. Yet his analysis of the sources of waste in development and the remedies that allow us to iterate faster are especially useful for startups. There is an important caveat, however. Product development in established companies and markets has a clear economic rationale to judge effectiveness and productivity. The goal is to increase profitability by making high-ROI investments in new products. To give one example, Reinertsen emphasizes the power of measuring the cost of delay (COD) of a new product. That is, in order to make economically rational decisions about cycle time for a given process, we should understand what it costs the company if the products produced by that process are delayed by, say, one day. Armed with that information, we can make rational trade-offs. Take one of Reinertsen's example:

Unhappy with late deliveries, a project manager decides he can reduce variability by inserting a safety margin or buffer in his schedule. He reduces uncertainty in the schedule by committing to an 80 percent confidence schedule. But, what is the cost of this buffer? The project manager is actually trading cycle time for variability. We can only know if this is a good trade-off if we quantify both the value of the cycle time and the economic benefit of reduced variability.

Does this sound familiar? Many of the startups I talk to - and their boards - seem to equate ability to "hit the schedule" with competence and productivity. Yet timely delivery of new features often comes at the expense of agility, especially if cycle times are long. That is often a bad trade (although, as I'm sure Reinertsen would hasten to add, not always!). For example, many startups would do better by removing buffers from their schedules, embracing the variability of their delivery times, and reducing their cycle times.

Even worse, and unlike their established counterparts, startups often experience a non-quantifiable cost of delay. In a truly new market, we face no meaningful competition, there are no tradeshows to present at, and customers are not clamoring for our product. This means that there are no external factors that argue for shipping product on any given day. A day delay has almost no cost, as far as profitability is concerned. Remember that startups operate by a different unit of progress: what I call validated learning about customers. Any activity that promotes learning is progress, and productivity needs to be measured with respect to that. And that's also where we need to modify some of the specific practices Reinertsen recommends. If the product development team can be engaged in activities that promote business learning at the expense of shipping - or even selling - product, that's a good trade. Hence the need for partitioning our resources into a separate problem team and solution team. As with any methodology, applying the principles faithfully may require modifying the practices to fit a specific context.

Let me close with an excerpt of Reinertsen at his best, using an unexpected example to illustrate the power of fast feedback to make learning more efficient:

It should be obvious that fast feedback improves the speed of learning. What may be less obvious is that fast feedback also increases the efficiency with which we generate information and learn new things. It does this by compressing the time between cause and effect. When this time is short, there are fewer extraneous signals that can introduce noise into our experiment.

Team New Zealand designed the yacht that won the America's Cup. When they tested improvements in keel designs, they used two virtually identical boats. The unimproved boat would sail against the improved boat to determine the effect of a design change. By sailing one boat against the other, they were able to discriminate small changes in performance very quickly.

In contrast, the competing American design team used a single boat supplemented by computer models and NASA wind tunnels. The Americans could never do comparison runs under truly identical conditions because the runs were separated in time ...

Team New Zealand completed many more cycles of learning, and they generated more information in each cycle. This ultimately enabled them to triumph over a much better funded American team. It is worth noting that Team New Zealand explicitly invested in a second boat to create this superior test environment. It is common that we must invest in creating a superior development environment in order to extract the smaller signals that come with fast feedback.

There's far more material in this book that I would love to be able to excerpt. Unfortunately, each principle builds on the previous ones so tightly that it's hard to form coherent excerpts without quoting the whole thing. And that's exactly my point. When we're ready, this book has a tremendous amount to teach all of us. It's not a beginner's guide, and it doesn't hold your hand. Instead, it tackles the hard questions head-on. I've read it and re-read it; for a process junkie like me, I just can't put it down. I hope you'll enjoy it as much as I have.

The Principles of Product Development Flow: Second Generation Lean Product Development

Read More »

When I wrote earlier about how to conduct a good technical interview, I had only a few things to say about how to assess if the candidate fits in with the team, including this:

This responsibility falls squarely to the hiring manager. You need to have a point of view about how to put together a coherent team, and how a potential candidate fits into that plan. Does the candidate have enough of a common language with the existing team (and with you) that you'll be able to learn from each other? Do they have a background that provides some novel approaches? Does their personality bring something new?

A few commenters have taken issue with the idea that it's solely the hiring manager's responsibility to assess fit, arguing correctly that the whole team should participate in the evaluation and decision. I completely agree. Still, I do think fit is a quality that requires special treatment, because it is the hardest attribute to evaluate.

Unlike the other attributes we look for in an interview candidate (like drive, brains or empathy) fit is not an individual quality. It's caught up in group dynamics. Worse, it has a self-referential quality to it. The very team that is making the assessment is being asked to assess itself at the same time as the candidate. How else can they tell whether the new team that will be created by the addition of this person will be superior to the team as it is presently constituted?

I have found James Surowiecki's book The Wisdom of Crowds particularly helpful in thinking through these issues. This book is Tipping Point-esque, full of anecdotes and interesting social science citations. Its central thesis is that, under the right circumstances, groups of people can be smarter than even their smartest single member. I find his observations compelling, and I feel good recommending the book to you, even though I know there are many among us who find "argument-by-anecdote" irritating. You don't have to buy the argument, but the facts and citations are worth the price of admission.

Let me briefly summarize the part of the book I find most helpful (leaving a few out, which aren't germane to today's topic). Not all crowds are wise. In order to get optimal results from a group-based effort, you need three things: diversity, Independence, and an objective method for aggregating results. For example, we conduct elections with a secret ballot, which ensures Independence (since nobody can directly influence your vote); we let everyone vote, which ensures diversity (since even extreme opinions can be heard); and we use a numerical count of the results (which, recent experiences notwithstanding, is supposed to mean that everyone's vote counts equally according to an objective formula). Similar mechanisms are at work in the stock market, Google PageRank, and guessing an ox's weight at the state fair.

Remove any of these essential ingredients, and you can find examples of groups gone bad: the Bay of Pigs invasion fiasco, market bubbles, and pretty much every one of Dilbert's team meetings.

Anyway, back to fit. Surowiecki has helped me in two ways:

1. Assessing fit in the context of what makes a good team. In order to improve the performance of a team, it's not enough just to keep adding smart people. You actually need to find a diverse set of people whose strengths and weaknesses complement each other. The problem most teams have with fit, in my experience, is they confuse it with liking. Many great engineers I've worked with (especially the type I talked about in the hacker's lament) seem to think that if they get along well with someone in an interview, they'll be a good addition to the team. This kind of homogeneity can lead to groupthink.
   
   
2. Putting together a process for helping a team assess fit. Another dangerous group dynamic in fit questions is that people are very sensitive to the opinions of their peers when talking about the group itself. In order to make an informed decision, the team needs a process of gathering and combining their opinions without having anyone's voice stifled.
   

For example, let's say you are on a team that prides itself in its all-hands-on-deck-at-all-hours style of working. There are a lot of great teams that work this way, preferring a series of sprints and lulls to a steady pace. Now let's say you're interviewing someone who doesn't seem to like to work that way. They work steady hours, but not for lack of drive; their references say they have exceptional output. Now picture the group meeting to talk about this prospective candidate. First up, the alpha-hacker on the team says something like "we should pass, this candidate is lazy."

Now it's your turn. Even if you are convinced that this candidate would make a great addition to the team, how much courage does it take to say so? You might convince the group, but you might not. And if you don't, will it raise suspicion about how dedicated you are? Will you be implicitly calling into question the validity of the team's values? Will they then be watching you for signs of laziness in the future? What about that vacation you've been planning to take... and so on. In my experience, there are plenty of situations where dissenting voices simply opt out. There's a clear danger to speaking up, but a pretty murky benefit.

If you find this line of reasoning confusing (nobody on my team feels that way) or paranoid (let's just all be rational), you may be surprised what the other people in the room are thinking. Take a look at some of the social science research in this area, like the Asch conformity experiments. In those, a group of people are asked to answer a simple question about their observations, one at a time. The first few people are actually actors, and they all give the same patently false answer. The experiment measures the likelihood that the last person in the sequence, the real experimental subject, will conform to what the previous people have said, or dissent. Even though the answer is obvious, and the other people in the room are all strangers, a surprising number of people choose to conform. I have found the pressure is much higher in situations where the answer is unclear, and the other group members are coworkers.

Combating these tendencies is the real job of the hiring manager. If that's you (or you are on a team whose hiring manager abdicates that responsibility), here are three suggestions that have worked for me to take advantage of the wisdom of crowds in hiring. Each of these are based in changes I've made to my hiring process in response to five whys analysis of previous hiring mistakes.

• Before you meet the candidate, spend time thinking about the strengths and weaknesses of your team. Try to brainstorm some archetypes that probably would interview badly but actually be successful in filling out your team. Having been through this exercise in advance can help you listen carefully to what team members say about the candidate, and see if their objections are simply fearing what is different, or if they have a more serious concern.
  
  One experience I had was with a candidate who was absolutely convinced that our development methodology wouldn't work. He spent an inordinate amount of time grilling us on exactly how we work and why, asking smart but tough questions. He made us nervous, but we took a risk and hired him anyway. After we hired him, he spent weeks driving the team crazy with his critical (but, we had to admit, accurate) eye. Then, all of the sudden, a remarkable thing happened. Another new hire started to complain about the way we worked. Our former critic promptly set him straight, shooting down his complaints with the same ruthless efficiency he had previously devoted to analyzing our work. He had been converted, and from that point on acted as "defender of the faith" far better than I ever could.
  

• Maintain strict Independence for each interviewer. Our rule was always that each interviewer was not allowed to talk any other interviewer once their session was concluded. The first time we'd exchange any words at all was during the end of the day assessment meeting. This prevents a previous interview from biasing a later interview. For example, I've seen situations where even a positive comment, like "wow, that candidate is smart!" cause disaster. The next interviewer, armed with an expectation of brilliance, chooses harder questions or becomes disappointed by an "only above average" performance.
  
  
• Aggregate results carefully. When sitting in a room talking about the candidate, I have had success with two precautions. First, we would always share our experiences in reverse-seniority order. That meant that the most junior person would be forced to speak first, without knowing anything about what his or her manager thought. As the hiring manager, I would speak last, and I'd do my best to avoid giving any indication in advance of what I thought.
  
  We'd also have a structured discussion in two parts: in the first part, each person talks only objectively about what happened in the interview, without giving opinions or passing judgment. Others are allowed to ask "clarifying questions" only - no leading questions or comments. Only in the second round does each person give their opinion about whether to hire the person or not. This helps get the facts on the table in an objective way. If our team had ever struggled to do it, I would have insisted on written comments shared anonymously. In other words: do whatever you have to do to get an objective discussion going.

If you've been the victim of groupthink in hiring, or have suggestions for ways to avoid it, please share. All of us are team members, family members, coworkers and leaders. Tell us what you've learned in those different contexts. Maybe it'll help someone else avoid the same mistakes.

Read More »

I've mentioned Net Promoter Score (NPS) in a few previous posts, but haven't had a chance to describe it in detail yet. It is an essential lean startup tool that combines seemingly irreconcilable attributes: it provides operational, actionable, real-time feedback that is truly representative of your customers' experience as a whole. It does it all by asking your customers just one magic question.

In this post I'll talk about why NPS is needed, how it works, and show you how to get started with it. I'll also reveal the Net Promoter Score for this blog, based on the data you've given me so far.

How can you measure customer satisfaction?
Other methods for collecting data about customers have obvious drawbacks. Doing in-depth customer research, with long questionnaires with detailed demographic and psychograpic breakdowns, is very helpful for long-range planning, interaction design and, most importantly, creating customer archetypes. But it's not immediately actionable, and it's far too slow to be a regular part of your decision loop.

At the other extreme, there's the classic A/B split-test, which provides nearly instantaneous feedback on customer adoption of any given feature. If your process for creating split-tests is extremely light (for example, it requires only one line of code), you can build a culture of lightweight experimentation that allows you to audition many different ideas, and see what works. But split-tests also have their drawbacks. They can't give you a holistic view, because they only tell you how your customers reacted to that specific test.

You could conduct an in-person usability test, which is very useful for getting a view of how actual people perceive the totality of your product. But that, too, is limited, because you are relying on a very small sample, from which you can only extrapolate broad trends. A major usability problem is probably experienced similarly by all people, but the absence of such a defect doesn't tell you much about how well you are doing.

Net Promoter Score
NPS is a methodology that comes out of the service industry. It involves using a simple tracking survey to constantly get feedback from active customers. It is described in detail by Fred Reichheld in his book The Ultimate Question: Driving Good Profits and True Growth. The tracking survey asks one simple question: How likely are you to recommend Product X to a friend or colleague? The answer is then put through a formula to give you a single overall score that tells you how well you are doing at satisfying your customers. Both the question and formula are the results of a lot of research that claims that this methodology can predict the success of companies over the long-term.

There's a lot of controversy surrounding NPS in the customer research community, and I don't want to recapitulate it here. I think it's important to acknowledge, though, that lots of smart people don't agree with the specific question that NPS asks, or the specific formula used to calculate the score. For most startups, though, I think these objections can safely be ignored, becuase there is absolutely no controversy about the core idea that a regular and simple tracking survey can give you customer insight.

Don't let the perfect be the enemy of the good. If you don't like the NPS question or scoring system, feel free to use your own. I think any reasonably neutral approach will give you valuable data. Still, if you're open to it, I recommend you give NPS a try. It's certainly worked for me.

How to get started with NPS
For those that want to follow the NPS methodology, I will walk you through how to integrate it into your company, including how to design the survey, how to collect the answers, and how to calculate your score. Because the book is chock-full of examples of how to do this in older industries, I will focus on my experience integrating NPS into an online service, although it should be noted that it works equally well if your primary contact with customers is through a different channel, such as the telephone.

Designing the survey
The NPS question itself (again, "How likely are you to recommend X to a friend or colleague?") is usually asked on a 0-10 point scale. It's important to let people know that 10 reperesents "most likely" and 0 represents "least likely" but it's also important not to use words like promoter or detractor anywhere in the survey itself.

The hardest part about creating an NPS survey is to resist the urge to load it up with lots of questions. The more questions you ask, the lower your response rate, and the more you bias your results towards more-engaged customers. The whole goal of NPS is to get your promoters and your detractors alike to answer the question, and this requires that you not ask for too much of their time. Limit yourself to two questions: the official NPS question, and exactly one follow-up. Options for the follow-up could be a different question on a 10-point scale, or just an open ended question asking why they chose the rating that they did. Another possibility is to ask "If you are open to answering some follow-up questions, would you leave your phone number?" or other contact info. That would let you talk to some actual detractors, and get a qualitative sense of what they are thinking, for example.

For an online service, just host the survey on a webpage with as little branding or decoration as possible. Because you want to be able to produce real-time graphs and results, this is one circumstance where I recommend you build the survey yourself, versus using an off-the-shelf hosted survey tool. Just dump the results in a database as you get them, and let your reports calculate scores in real-time.

Collecting the answers
Once you have the survey up and running, you need to design a program to have customers take it on a regular basis. Here's how I've set it up in the past. Pick a target number of customers to take the survey every day. Even if you have a very large community, I don't think this number needs to be higher than 100. Even just 10 might be enough. Build a batch process (using GearMan, cron, or whatever you use for offline processing) whose job is to send out invites to the survey.

Use whatever communication channel you normally rely on for notifying your customers. Email is great; of course, at IMVU, we had our own internal notification system. Either way, have the process gradually ramp up the number of outstanding invitations throughout the day, stopping when it's achieved 100 responses. This way, no matter what the response rate, you'll get a consistent amount of data. I also recommend that you give each invitation a unique code, so that you don't get random people taking the survey and biasing the results. I'd also recommend you let each invite expire, for the same reason.

Choose the people to invite to the survey according to a consistent formula every day. I recommend a simple lottery among people who have used your product that same day. You want to catch people when their impression of your product is fresh - even a few days can be enough to invalidate their reactions. Don't worry about surveying churned customers; you need to use a different methodology to reach them. I also normally exclude anyone from being invited to take the survey more than once in any given time period (you can use a month, six months, anything you think is appropriate).

Calculate your score
Your NPS score is derived in three steps:

1. Divide all responses into three buckets: promoters, detractors, and others. Promoters are anyone who chose 9 or 10 on the "likely to recommend scale" and detractors are those who chose any number from 0-6.
   
2. Figure out the percentage of respondants that fall into the promoter and detractor buckets.
3. Subtract your detractor percentage from your promoter percentage. The result is your score. Thus, NPS = P% - D%.
   

You can then compare your score to people in other industries. Any positive score is good news, and a score higher than +50 is considered exceptional. Here are a few example scores taken from the official Net Promoter website:

Apple	79
Adobe	46
Google	73
Barnes & Noble online	74
American Express	47
Verizon	10
DIRECTV	20

Of course, the most important thing to do with your NPS score is to track it on a regular basis. I used to look at two NPS-related graphs on a regular basis: the NPS score itself, and the response rate to the survey request. These numbers were remarkably stable over time, which, naturally, we didn't want to believe. In fact, there were some definite skeptics about whether they measured anything of value at all, since it is always dismaying to get data that says the changes you're making to your product are not affecting customer satisfaction one way or the other.

However, at IMVU one summer, we had a major catastrophe. We made some changes to our service that wound up alienating a large number of customers. Even worse, the way we chose to respond to this event was terrible, too. We clumsily gave our community the idea that we didn't take them seriously, and weren't interested in listening to their complaints. In other words, we committed the one cardinal sin of community management. Yikes.

It took us months to realize what we had done, and to eventually apologize and win back the trust of those customers we'd alienated. The whole episode cost us hundreds of thousands of dollars in lost revenue. In fact, it was the revenue trends that eventually alerted us to the magnitude of the problem. Unfortunately, revenue a trailing indicator. Our response time to the crisis was much too slow, and as part of the post-mortem analysis of why, I took a look at the various metrics that all took a precipitous turn for the worse during that summer. Of everything we measured, it was Net Promoter Score that plunged first. It dropped down to an all-time low, and stayed there for the entire duration of the crisis, while other metrics gradually came down over time.

After that, we stopped being skeptical and started to pay very serious attention to changes in our NPS. In fact, I didn't consider the crisis resolved until our NPS peaked above our previous highs.

Calculating the NPS of Lessons Learned
I promised that I would reveal the NPS of this blog, which I recently took a snapshot of by offering a survey in a previous post. Here's how the responses break down, based on the first 100 people who answered the question:

• Number of promoters: 47
• Number of detractors: 22
• NPS: 25

Now, I don't have any other blogs to compare this score to. Plus, the way I offered the survey (just putting a link in a single post), the fact that I didn't target people specifically to take the survey, and the fact that the invite was impersonal, are all deeply flawed. Still, all things considered, I'm pretty happy with the result. Of course, now that I've described the methodology in detail, I've probably poisoned the well for taking future unbiased samples. But that's a small price to pay for having the opportunity to share the magic of NPS.

I hope you'll find it useful. If you do, come on back and post a comment letting us all know how it turned out.

Read More »

Those of us who have had the privilege of working in the premier startup hub in the world often take its advantages for granted. Among those: plentiful financing and nerds, a culture that celebrates both failure and success, and an ethos of openness and sharing. It's useful to look back to understand how we got those advantages. It's not side-effect of some secret mineral in the water: it was painstakingly crafted by people who came before us. And what may surprise you is how many of those people were part of the military-industrial complex.

I think the absolute best reading on this subject is a book called Regional Advantage: Culture and Competition in Silicon Valley and Route 128 by AnnaLee Saxenian. It's an academic treatise that tries to answer a seemingly straightforward question: after World War II, why did Silicon Valley become the undisputed leader of the technology world, while Boston's Route 128 corridor did not. To an early observer, it would have seemed obvious that Route 128 had all the advantages: a head start, more government and military funding, and far more established companies. And although both regions had outstanding research universities, MIT was way ahead of Stanford by every relevant measure. However...

While both Stanford and MIT encouraged commercially oriented research and courted federal research contracts in the postwar years, MIT's leadership focused on building relations with government agencies and seeking financial support from established electronics producers. In contrast, Stanford's leaders, lacking corporate or government ties or even easy proximity to Washington, actively promoted the formation of new technology enterprises and forums for cooperation with local industry.

This contrast — between MIT's orientation toward Washington and large, established producers and Stanford's promotion of collaborative relationships among small firms — would fundamentally shape the industrial systems emerging in the two regions.

The book is really fun to read (how often do you see an academic tome crossed with a real whodunit?). It's important not just for historical reasons, but because we are often called upon to take sides in current debates that impact the way our region and industry will develop. Just to pick one: will software patents, NDA's and trade secrets laws make it harder for people to share knowledge outside of big companies? We need to work hard, as previous generations did, to balance the needs of everyone in our ecosystem. Otherwise, we risk sub-optimizing by focusing only on one set of players.

However, even that fascinating history is not the whole story. You might be wondering: who were those brilliant people who made the key decisions to mold Silicon Valley? And what were they doing beforehand? Steve Blank, who I've written about recently in a totally different context has attempted to answer these questions in a talk called "Hidden in Plain Sight: The Secret History of Silicon Valley." If you're in the Bay Area, you have the opportunity to see it live: he's giving the talk at the Computer History Museum next Thursday, November 20:

Hear the story of how two major events – WWII and the Cold War – and one Stanford professor set the stage for the creation and explosive growth of entrepreneurship in Silicon Valley. In true startup form, the world was forever changed when the CIA and the National Security Agency acted as venture capitalists for this first wave of entrepreneurship. Learn about the key players and the series of events that contributed to this dramatic and important piece of the emergence of this world renowned technology mecca.

If you can't make it, you can take a look at this sneak peak of the slides, courtesy of the author:

Steve Blank's "Secret History of Silicon Valley" talk at Computer History Museum 11-20-08

View SlideShare presentation or Upload your own.

In addition to learning who to thank (Frederick Terman and William Shockley), you'll get a behind-the-scenes look at World War II and the Cold War from an electronics perspective. Fans of Cryptonomicon will have a blast.

Read More »

When we build products, we use a methodology. For software, we have many - you can enjoy a nice long list on Wikipedia. But too often when it's time to think about customers, marketing, positioning, or PR, we delegate it to "marketroids" or "suits." Many of us are not accustomed to thinking about markets or customers in a disciplined way. We know some products succeed and others fail, but the reasons are complex and the unpredictable. We're easily convinced by the argument that all we need to do is "build it and they will come." And when they don't come, well, we just try, try, again.

What's wrong with this picture?

Steve Blank has devoted many years now to trying to answer that question, with a theory he calls Customer Development. This theory has become so influential that I have called it one of the three pillars of the lean startup - every bit as important as the changes in technology or the advent of agile development.

You can learn about customer development, and quite a bit more, in Steve's book The Four Steps to the Epiphany. I highly recommend this book for all entrepreneurs, in startups as well as in big companies. Here's the catch. This is a self-published book, originally designed as a companion to Steve's class at Berkeley's Haas school of business. And Steve is the first to admit that it's a "turgid" read, without a great deal of narrative flow. It's part workbook, part war story compendium, part theoretical treatise, and part manifesto. It's trying to do way too many things at once. On the plus side, that means it's a great deal. On the minus side, that has made it a wee bit hard to understand.

Some notable bloggers have made efforts to overcome these obstacles. VentureHacks did a great summary, which includes slides and video. Marc Andreeson also took a stab, calling it "a very practical how-to manual for startups ... a roadmap for how to get to Product/Market Fit." The theory of Product/Market Fit is one key component of customer development, and I highly recommend Marc's essay on that topic.

Still, I feel the need to add my two cents. There's so much crammed into The Four Steps to the Epiphany that I want to distill out what I see as the key points:

1. Get out of the building. Very few startups fail for lack of technology. They almost always fail for lack of customers. Yet surprisingly few companies take the basic step of attempting to learn about their customers (or potential customers) until it is too late. I've been guilty of this many times in my career - it's just so easy to focus on product and technology instead. True, there are the rare products that have literally no market risk; they are all about technology risk ("cure for cancer"). For the rest of us, we need to get some facts to inform and qualify our hypotheses ("fancy word for guesses") about what kind of product customers will ultimately buy.
   
   And this is where we find Steve's maxim that “In a startup no facts exist inside the building, only opinions.” Most likely, your business plan is loaded with opinions and guesses, sprinkled with a dash of vision and hope. Customer development is a parallel process to product development, which means that you don't have to give up on your dream. We just want you to get out of the building, and start finding out whether your dream is a vision or a delusion. Surprisingly early, you can start to get a sense for who the customer of your product might be, how you'll reach them, and what they will ultimately need. Customer development is emphatically not an excuse to slow down or change the plan every day. It's an attempt to minimize the risk of total failure by checking your theories against reality.
   
   
2. Theory of market types. Layered on top of all of this is a theory that helps explain why different startups face wildly different challenges and time horizons. There are three fundamental situations that change what your company needs to do: creating a new market (the original Palm), bringing a new product to an existing market (Handspring), and resegmenting an existing market (niche, like In-n-Out Burger; or low-cost, like Southwest Airlines). If you're entering an existing market, be prepared for fast and furious competition from the incumbent players, but enjoy the ability to fail (or succeed) fast. When creating a new market, expect to spend as long as two years before you manage to get traction with early customers, but enjoy the utter lack of competition. What kind of market are you in? The Four Steps to the Epiphany contains a detailed approach to help you find out.
   
   
3. Finding a market for the product as specified. When I first got the "listening to customers" religion, my plan was to talk to as many customer as possible, and build them as many features as they asked as possible. This is a common mistake. Our goal in product development is to find the minimum feature set required to get early customers. In order to do this, we have our customer development team work hard to find a market, any market, for the product as currently specified. We don't just abandon the vision of the company at every turn. Instead, we do everything possible to validate the founders' belief.
   
   The nice thing about this paradigm is it sets the company up for a rational discussion when the task of finding customers fails. You can start to think through the consequences of this information before it's too late. You might still decide to press ahead building the original product, but you can do so with eyes open, knowing that it's going to be a tough, uphill battle. Or, you might start to iterate the concept, each time testing it against the set of facts that you've been collecting about potential customers. You don't have to wait to iterate until after the splashy high-burn launch.
   
   
4. Phases of product & company growth. The book takes its name from Steve's theory of the four stages of growth any startup goes through. He calls these steps Customer Discovery (when you're just trying to figure out if there are any customers who might want your product), Customer Validation (when you make your first revenue by selling your early product), Customer Creation (akin to a traditional startup launch, only with strategy involved), and Company Building (where you gear up to Cross the Chasm). Having lived through a startup that went through all four phases, I can attest to how useful it is to have a roadmap that can orient you to what's going on as your job and company changes.
   
   As an aside, here's my experience: you don't get a memo that tells you that things have changed. If you did, it would read something like this: "Dear Eric, thank you for your service to this company. Unfortunately, the job you have been doing is no longer available, and the company you used to work for no longer exists. However, we are pleased to offer you a new job at an entirely new company, that happens to contain all the same people as before. This new job began months ago, and you are already failing at it. Luckily, all the strategies you've developed that made you successful at the old company are entirely obsolete. Best of luck!"
   
   
5. Learning and iterating vs. linear execution. I won't go through all four steps in detail (buy the book already). I'll just focus on the paradigm shift represented by the first two steps and the last two steps. In the beginning, startups are focused on figuring out which way is up. They really don't have a clue what they should be doing, and everything is guesses. In the old model, they would probably launch during this phase, failing or succeeding spectacularly. Only after a major, public, and expensive failure would they try a new iteration. Most people can't sustain more than a few of these iterations, and the founders rarely get to be involved in the later tries.
   
   The root of that mistake is premature execution. The major insight of The Four Steps to the Epiphany is that startups need time spent in a mindset of learning and iterating, before they try to launch. During that time, they can collect facts and change direction in private, without dramatic and public embarrassment for their founders and investors. The book lays out a disciplined approach to make sure this period doesn't last forever, and clear criteria for when you know it's time to move to an execution footing: when you have a repeatable and scalable sales process, as evidenced by early customers paying you money for your early product.
   

It slices, it dices. It's also a great introduction to selling and positioning a product for non-marketeers, a workbook for developing product hypotheses, and a compendium of incredibly useful tactics for startups young and old.

When I first encountered this book, my first impulse was as follows. I bought a bunch of copies, gave them out to my co-founders and early employees, and then expected the whole company's behavior would radically change the next day. That doesn't work (you can stop laughing now). This is not a book for everyone. I've only had luck sharing it with other entrepreneurs who are actually struggling with their product or company. If you already know all the answers, you can skip this one. But if you find some aspect of the situation your in confusing, maybe this will provide some clarity. Or at least some techniques for finding clarity soon.

My final suggestion is that you buy the book and skim it. Try and find sections that apply to the startup you're in (or are thinking of building). Make a note of the stuff that doesn't seem to make sense. Then put it on your shelf and forget about it. If your experience is anything like mine, here's what will happen. One day, you'll be banging your head against the wall, trying to make progress on some seemingly intractable problem (like, how the hell do I know if this random customer is an early adopter who I should spend time listening to, or a mainstream customer who won't buy my product for years). That's when I would get that light bulb moment: this problem sounds familiar. Go to your shelf. Get down the book, and be amazed that you are not the first person to tackle this problem in the history of the world.

I have been continually surprised at how many times I could go back to that same well for wisdom and advice. I hope you will be too.
Read More »