67

Eric Ries

• Learning is better than optimization (the local maximum problem) 7 April, 2010, 8:55 pm
  Lean startups don’t optimize. At least, not in the traditional sense of trying to squeeze every tenth of a point out of a conversion metric or landing page. Instead, we try to accelerate with respect to validated learning about customers. For example, I’m a big believer in split-testing. Many optimizers are in favor of split-testing, too: direct marketers, landing page and SEO experts -- heck even the Google Website Optimizer team. But our interest in the tactic of split-testing is only superficially similar. Take the infamous “41 shades of blue” split-test. I understand and respect why optimizers want to do tests like that. There are often counter-intuitive changes in customer behavior that depend on little details. In fact, the curse of product development is that sometimes small things make a huge difference and sometimes huge things make no difference. Split-testing is great for figuring out which is which. But what do you learn from the “41 shades of blue” test? You only learn which specific shade of blue customers are more likely to click on. And, in most such tests, the differences are quite small, which is why sample sizes have to be very large. In Google’s case, often in the millions of people. When people (ok, engineers) who have been trained in this model enter most startups, they quickly get confused. How can we do split-testing when we have only a pathetically small number of customers? What’s the point when the tests aren’t going to be statistically significant? And they’re not the only ones. Some designers also hate optimizing (which is why the “41 shades of blue” test is so famous – a famous designer claims to have quit over it). I understand and respect that feeling, too. After you’ve spent months on a painstaking new design, who wants to be told what color blue to use? Split-testing a single element in an overall coherent design seems ludicrous. Even if it shows improvement in some micro metric, does that invalidate the overall design? After all, most coherent designs have a gestalt that is more than the sum of the parts – at least, that’s the theory. Split-testing seems fundamentally at odds with that approach. But I’m not done with the complaints, yet. Optimizing sounds bad for visionary thinking. That’s why you hear so many people proclaim proudly that they never listen to customers. Customers can only tell you want they think they want, and tend to have a very near-term perspective. If you just build what they tell you, you generally wind up with a giant, incoherent mess. Our job as entrepreneurs is to invent the future, and any optimization technique – including split-testing, many design techniques, or even usability testing – can lead us astray. Sure, customers think they want something, but how do they know what they will want in the future? You can always tell who has a math background in a startup, because they call this the local maximum problem. Those of us with a computer science background call it the hill-climbing algorithm. I’m sure other disciplines have their own names for it; even protozoans exhibit this behavior (it's called taxis). It goes like this: whenever you’re not sure what to do, try something small, at random, and see if that makes things a little bit better. If it does, keep doing more of that, and if it doesn’t, try something else random and start over. Imagine climbing a hill this way; it’d work with your eyes closed. Just keep seeking higher and higher terrain, and rotate a bit whenever you feel yourself going down. But what if you’re climbing a hill that is in front of a mountain? When you get to the top of the hill, there’s no small step you can take that will get you on the right path up the mountain. That’s the local maximum. All optimization techniques get stuck in this position. Because this causes a lot of confusion, let me state this as unequivocally as I can. The Lean Startup methodology does not advocate using optimization techniques to make startup decisions. That’s right. You don’t have to listen to customers, you don’t have to split-test, and you are free to ignore any data you want. This isn’t kindergarten. You don’t get a gold star for listening to what customers say. You only get a gold star for achieving results. What should you do instead? The general pattern is: have a strong vision, test that vision against reality, and then decide whether to pivot or persevere. Each part of that answer is complicated, and I’ve written extensively on the details of how to do each. What I want to convey here is how to respond to the objections I mentioned at the start. Each of those objections is wise, in its own way, and the common reaction – to just reject that thinking outright – is a bad idea. Instead, the Lean Startup offers ways to incorporate those people into an overall feedback loop of learning and discovery. So when should we split-test? There’s nothing wrong with using split-testing, as part of the solution team, to do optimization. But that is not a substitute for testing big hypotheses. The right split-tests to run are ones that put big ideas to the test. For example, we could split-test what color to make the “Register Now” button. But how much do we learn from that? Let’s say that customers prefer one color over another? Then what? Instead, how about a test where we completely change the value proposition on the landing page? I remember the first time we changed the landing page at IMVU from offering “avatar chat” to “3D instant messaging.” We didn’t expect much of a difference, but it dramatically changed customer behavior. That was evident in the metrics and in the in-person usability tests. It taught us some important things about our customers: that they had no idea what an avatar was, they had no idea why they would want one, and they thought “avatar chat” was something weird people would do. When we started using “3D instant messaging,” we validated our hypothesis that IM was an activity our customers understood and were interested in “doing better.” But we also invalidated a hypothesis that customers wanted an avatar; we had to learn a whole new way of explaining the benefits of avatar-mediated communication because our audience didn’t know what that word meant. However, that is not the end of the story. If you go to IMVU’s website today, you won’t find any mention of “3D instant messaging.” That’s because those hypotheses were replaced by yet more, each of which was subject to this kind of macro-level testing. Over many years, we’ve learned a lot about what customers want. And we’ve validated that learning by being able to demonstrate that when we change the product as a result of that learning, the key macro metrics improve. A good rule of thumb for split-testing is that even when we’re doing micro-level split-tests, we should always measure the macro. So even if you want to test a new button color, don’t measure the click-through rate on that button! Instead, ask yourself: “why do we care that customers click that button?” If it’s a “Register Now” button, it’s because we want customers to sign up and try the product. So let’s measure the percentage of customers who try the product. If the button color change doesn’t have an impact there – it’s too small, and should be reverted. Over time, this discipline helps us ignore the minor stuff and focus our energies on learning what will make a significant impact. (It also just so happens that this style of reporting is easier to implement; you can read more here) Next, let’s take on the sample-size issue. Most of us learn about the samples sizes from things like political polling. In a large country, in order to figure out who will win an election with any kind of accuracy, you need to sample a large number of people. What most of us forget is that statistical significance is a function of both sample size and the magnitude of the underlying signal. Presidential elections are often decided by a few percentage points or less. When we’re optimizing, product development teams encounter similar situations. But when we’re learning, that’s the rare exception. Recall that the biggest source of waste in product development is building something nobody wants. In that case, you don’t need a very large sample. Let me illustrate. I’ve previously documented that early-on in IMVU’s life, we made the mistake of building an IM add-on product instead of a standalone network. Believe me, I had to be dragged kicking and screaming to the realization that we’d made a mistake. Here’s how it went down. We would bring customers in for a usability test, and ask them to use the IM add-on functionality. The first one flat-out refused. I mean, here we are, paying them to be there, and they won’t use the product! (For now, I won’t go into the reasons why – if you want that level of detail, you can watch this interview.) I was the head of product development, so can you guess what my reaction was? It certainly wasn’t “ooh, let’s listen to this customer.” Hell no, “fire that customer! Get me a new one” was closer. After all, what is a sample size of one customer? Too small. Second customer: same result. Third, fourth, fifth: same. Now, what are the odds that five customers in a row refuse to use my product, and it’s just a matter of chance or small sample size? No chance. The product sucks – and that is a statistically significant result. When we switch from an optimization mindset to a learning mindset, design gets more fun, too. It takes some getting used to for most designers, though. They are not generally used to having their designs evaluated by their real-world impact. Remember that plenty of design organizations and design schools give out awards for designing products that never get built. So don’t hold it against a classically trained designer if they find split-testing a little off-putting at first. The key is to get new designers integrated with a split-testing regimen as soon as possible. It’s a good deal: by testing to make sure (I often say “double check”) each design actually improves customers lives, startups can free designers to take much bigger risks. Want to try out a wacky, radical, highly simplified design? In a non-data-driven environment, this is usually impossible. There’s always that engineer in the back of the room with all the corner cases: “but how will customers find Feature X? What happens if we don’t explain in graphic detail how to use Feature Y?” Now these questions have an easy answer: we’ll measure and see. If the new design performs worse than the current design, we’ll iterate and try again. But if it performs better, we don’t need to keep arguing. We just keep iterating and learning. This kind of setup leads to a much less political and much less arbitrary design culture. This same approach can also lead us out of the big incoherent mess problem. Teams that focus on optimizing can get stuck bolting on feature upon feature until the product becomes unusable. No one feature is to blame. I've made this mistake many times in my career, especially early on when I first began to understand the power of metrics. When that happens, the solution is to do a whole product pivot. "Whole product" is a term I learned from Bill Davidow's classic Marketing High Technology. A whole product is one that works for mainstream customers. Sometimes, a whole product is much bigger than a simple device - witness Apple's mastery of creating a whole ecosystem around each of their devices that make them much more useful than their competitors. But sometimes a whole product is much less - it requires removing unnecessary features and focusing on a single overriding value proposition. And these kinds of pivots are great opportunities for learning-style tests. It only requires the courage to test the new beautiful whole product design against the old crufty one head-to-head. By now, I hope you’re already anticipating how to answer the visionary’s objections. We don’t split-test or talk to customers to decide if we should abandon our vision. Instead, we test to find out how to achieve the vision in the best possible way. Startup success requires getting many things right all at once: building a product that solves a customer problem, having that problem be an important one to a sufficient number of customers, having those customers be willing pay for it (in one of the four customer currencies), being able to reach those customers through one of the fundamental growth strategies, etc. When you read stories of successful startups in the popular and business press, you usually hear about how the founders anticipated several of these challenges in their initial vision. Unfortunately, startup success requires getting them all right. What the PR stories tend to leave out is that we can get attached to every part of our vision, even the dumb parts. Testing the parts simply gives us information that can help us refine the vision – like a sculptor removing just the right pieces of marble. There is tremendous art to knowing which pieces of the vision to test first. It is highly context-dependent, which is why different startups take dramatically different paths to success. Should you charge from day one, testing the revenue model first? Or should you focus on user engagement or virality? What about companies, like Siebel, that started with partner distribution first?  There are no universally right answers to such questions. (For more on how to figure out which question applies in which context, see Business ecology and the four customer currencies.) Systematically testing the assumptions that support the vision is called customer development, and it’s a parallel process to product development. And therein lies the most common source of confusion about whether startups should listen to customers. Even if a startup is doing user-centered design, or optimizing their product through split-testing, or conducting tons of surveys and usability tests, that’s no substitute for also doing customer development. It’s the difference between asking “how should we best solve this problem for these customers?” and “what problem should we be solving? and for which customer?” These two activities have to happen in parallel, forming a company-wide feedback loop. We call such companies built to learn. Their speed should be measured in validated learning about customers, not milestones, features, revenue, or even beautiful design. Again, not because those things aren’t important, but because their role in a startup is subservient to the company’s fundamental purpose: piercing the veil of extreme uncertainty that accompanies any disruptive innovation. The Lean Startup methodology can’t guarantee you won’t find yourself in a local maximum. But it can guarantee that you’ll know about it when it happens. Even better, when it is time to pivot, you’ll have actual data that can help inform where you want to head next. The data doesn’t tell you what to do – that’s your job. The bad news: entrepreneurship requires judgment. The good news: when you make data-based decisions, you are training your judgment to get better over time.
• Kent Beck keynote, "To Agility, and Beyond" 4 April, 2010, 5:30 pm
  Kent Beck will give the opening keynote at the Startup Lessons Learned conference on April 23. Our mystery keynote is now revealed and I couldn't be more excited. Kent is a significant figure in the field of software development. To his credit are Extreme Programming, jUnit, patterns, TDD, the list goes on. His keynote will kick off the day as well as our module on the build phase of the fundamental feedback loop that powers all startups. In Kent's honor, we've extended earlybird pricing for conference tickets (one last time) through Monday, April 5.
• Six streaming locations 3 April, 2010, 10:43 pm
  Can't travel to San Francisco for the Startup Lessons Learned Conference on April 23, but still want to participate? Thanks to the support of organizers around the world, you can join in remotely - in most cases, free of charge. I'm excited to announce the first six confirmed simulcast locations: Delft, Netherlands http://sllconf-delft.eventbrite.com/   Provo, UT http://wsg-lsc.eventbrite.com/ Boulder, CO http://sllconf-boulder.eventbrite.com/ Chicago, IL http://www.meetup.com/Chicago-Lean-Startup-Circle/calendar/13056515/ Barcelona, Spain http://www.eventbrite.com/event/638921030 Vancouver, Canada http://sllyvrsimulcast.eventbrite.com/ Please RSVP so our organizers can plan capacity accordingly. We're offering this simulcast service free of charge to organizers; if you'd like to host a simulcast in your city, you can sign up to do so here. We'll continue to post links to new events to the conference website as we get them confirmed. If you're curious about whether there are others in your area who'd like to get together to watch, feel free to contact a local meetup or post a comment below. I want to thank everyone who has volunteered to host, and especially thank our simulcast organizer Erin Turner. If you have any questions, please feel free to leave a comment. Hope to see you on April 23.
• Interviews 2 April, 2010, 6:20 am
  Robert Scoble came by my office to learn about the Lean Startup and the Startup Lessons Learned Conference on April 23. By all accounts, the conversation was a success. I certainly had a great time, and the early Twitter reactions seem positive. Of course, you can judge for yourself. I've embedded parts one and two below: Part One: Part Two: And, as a special bonus, I've included a recent podcast episode of The Web 2.0 Show, in which we discuss Lean Startups and the upcoming Lean Startup Intensive at the Web 2.0 Expo. Enjoy:
• New conference website, speakers, agenda 29 March, 2010, 8:17 am
  The Startup Lessons Learned Conference on April 23 is fast approaching. Earlybird Admission pricing ends in just two days. We have a brand new website up at http://sllconf.com. We've got a new scholarship program up and running. Most importantly, we've announced a big chunk of the agenda for the day (go take a look). I want to say a few words about why I am so excited about this event. Traveling the past year, I have heard loud and clear that it's time for the Lean Startup movement to enter its next phase. We've gone from total obscurity to something people are beginning to misunderstand and even co-opt. People are starting to argue about who should get credit for coining the term. Congratulations. Being misunderstood is a big step up from being ignored. I believe it means we're achieving product/market fit for a set of ideas. And it's time to completely ignore the nonsense and start focusing on: how do we take this movement to the next level? Here's what you had to say about it. Almost a thousand of your weighed in on the last Lessons Learned reader survey (thank you!). When asked, you were pretty clear in your answers. Here's a tiny sample: "Case studies, case studies, case studies presented by real people. Lot's of opportunity for personal interaction with people that have or are adopting the methodology." "Detailed case studies of how it was done. Practical advice on how to do it in companies at all stages." "Case studies Serious entrepreneurs not wannabes actual nuts and bolts, I'm sold ont he phiilosophy debates of contentious issues - not just yes men" "Some of the core personalities of the group, a number of startups (who have already achieved fit etc and have success) who can talk from experience." I know one thing for sure: I don't have all the answers. The way forward requires getting everyone together in a room, and having a conversation about where we're headed. That's what this conference is for. The focus is on case studies and real entrepreneurs. Our goal is to create the most coherent startup conference ever. When I was a practicing entrepreneur, startup events usually made me crazy. You had a lot of conflicting advice and success theater. Tactics were discussed out of context, and there wasn't an overarching framework for figuring out what works for what kinds of companies, industries, and stages of growth. My aspiration with the Lean Startup methodology has always been to provide such a framework, so that we have more intelligent conversations about what works and what doesn't for startups. This event will be a chance to put that idea to the test. Each part of the program is organized around one phase of the Build-Measure-Learn feedback loop and begins with a keynote address from a heavy hitter: Steve Blank on Customer Development, Randy Komisar on "Getting to Plan B" and - a third person, not-yet-announced-but-extremely-cool-trust-me. Then, we'll talk case studies in each area, presented by practicing entrepreneurs who have actually grappled with the topic at hand. I've asked each presenter not to pull any punches and to, whenever possible, share real data: what worked, what didn't. We're in pursuit of the truth, not orthodoxy. These case studies range in size and scope: from pre-product/market fit to already exited, bootstrapped to venture-backed, solo practitioner to large organization. Each part of the agenda also features a difficult question. These are the big questions I've heard over and over again as I've traveled presenting the lean startup methodology: "Sure, sounds great for a five-person team, but how can such a fast-paced development process scale? Doesn't the communication overhead of a large team lead to chaos of overlapping experiments and continuously-deployed bugs?" "If you just throw a minimum viable product out the door to see what sticks, won't that necessarily be ugly and badly designed? Is design important to lean startups? What does viable mean, anyway?" "Sure, everyone knows that getting customer feedback is important. But can't I outsource that to a market researcher? And do I still need to get out of the building if I've got great metrics and surveys?" We'll tackle these questions head-on with a combination of practitioners and theorists. At the end of the day, you'll have the data and have heard the theories - it'll be up to you to make your own decisions and test them out for yourself. Well, not entirely by yourself, actually. I've mentioned before that this event is designed to be best-experienced by teams, not just individuals. So we've made a limited number of team tickets available, which give teams of up to four people the opportunity to experience the day together. We'll have special seating for teams combined with exclusive access to a set of mentors who have agreed to be part of the conference as well. Mentors will sit with the teams throughout the day, and be available to answer questions and help put what you're hearing in context. Most important, they can help you make a plan for how to translate the insights from the stage into action back at the office. Like the speakers, mentors are a mix of theorists and practitioners. We've just started to list the mentors on our new website, and will add more as we get closer to the event itself. This conference has been one of the most stressful things I've ever done. It feels surprisingly personal and surprisingly vulnerable. As an entrepreneur, I am used to having people attack my product or complain about my decisions (you can see the evidence here). But, in the past, being in a company gave me something to hide behind. Not anymore. For the conference, the most common criticism has been that it is too expensive, and therefore "not very lean." Here's an example from a recent Hacker News discussion: "how can you be a lean startup if you have to pay $699 to know how to be lean? $699 buys you months of server infrastructure."I think this is a fair question. Of course, readers of this blog know that the lean in "lean startup" doesn't refer to cost, but - rather - to Lean Thinking. Or, as Steve Blank put it, Lean Startups Aren't Cheap Startups. My fundamental belief is that by changing the way that we approach building startups, we can dramatically change our odds of success - and the magnitude of that eventual success as well. I think that's worth the price of admission and a better investment than marginally more infrastructure. Am I right? The verdict is in your hands. Maybe we won't get a huge crowd. If a relatively small number of highly-motivated entrepreneurs attend, then we'll have an intense and intimate conversation. Either way, I'm going to be satisfied. For those who cannot afford the ticket price, who don't think it's worth the price, or who cannot travel to San Francisco, there are other ways to participate. We have scholarship programs available to help with ticket prices. We're offering a live stream to event organizers around the world. Meetup groups, universities, incubators, and anyone else who wants to get together to watch is welcome to do so. We'll be listing these viewing parties on our website as we confirm them. If you'd like to host an event, please let us know using this form. If you have questions, please contact our simulcast organizer, Erin Turner.  The Lean Startup movement is already global (see the map). That's as it should be, as the new era of entrepreneurship that is now dawning is intrinsically global. Ideas, products, and capital flow easily across borders. People, not as much. Startups may be intellectually global but they are physically local, which explains the increasing importance of startup hubs around the world. My hope for this conference is that it will benefit the global community of entrepreneurs. For those who can travel to be part of the conversation in San Francisco, I thank you. I hope you'll take back what you've learned and share it in your own cities. For those who can host a local simulcast, I thank you. By creating a space for your startup community to congregate and share new ideas, you're enabling a new kind of economic growth. And most importantly, to everyone who contributes to this movement - by writing, asking hard questions, joining meetups and mailing lists, and above all creating companies - I thank you. See you in April.
• Startup Lessons Learned - the Conference (April 23, 2010 in SF) 28 March, 2010, 8:17 am
  Today we are opening up registration for the first ever Startup Lessons Learned Conference on April 23, 2010 in San Francisco. I'm incredibly excited. The event is being produced in partnership with Charles Hudson, who puts on many of Silicon Valley's top events, including the forthcoming Freemium Summit. The Startup Lessons Learned Conference is by-and-for entrepreneurs, and only entrepreneurs. We have a lineup of speakers who are primarily active practitioners of the lean startup methodology. They'll be speaking about their real-life experiences trying to put these ideas into practice. You'll also have a chance to hear from the leading lights of the lean startup movement, including Steve Blank, Sean Ellis, Dave McClure, and many more. I have spent a lot of time over the past few years experimenting with what helps startup teams adopt new practices. One pattern has been overwhelmingly clear: it works best when a cross-functional team hears about new ideas all at the same time. As a result, we've built this event to be best experienced by teams, not just individuals. We have special team tickets; these teams will have special seating at the event and special access to mentors, who can answer questions and suggest ways to incorporate ideas from the speakers into each team's company. This event is for present and future entrepreneurs only - not service vendors or investors. If you are working on new product development in any sized company, you are welcome to attend. Remember, a startup is "a human institution designed to create something new under conditions of extreme uncertainty." If that describes your job, you're welcome to attend. (We will reserve a limited number of spots for sponsors to attend; if you'd like to become a sponsor, please get in touch.) For those that are able to make the trip to San Francisco, I hope you'll make the effort. I think this is going to be a one of a kind event, and you'll be glad you came. That said, for those who cannot make the trip, we're working to provide simulcast venues in cities around the world. We'll have more details shortly. In the meantime, if you'd like to attend remotely, or volunteer to host a viewing, please sign up as part of this survey. And for those of you who have already volunteered, please stay tuned for details. A partial list of speakers and mentors is posted on the registration page. More will be posted as we're able to confirm them. If you'd like to nominate someone to be a speaker or mentor, please feel free to leave a comment on this post. We'll consider all nominees; when possible, please include a link to a video of them speaking or to a relevant blog post. Last, I always try to have a scholarship program for paid events, and this one is no exception. If you'd like to sponsor a scholarship for a deserving startup that can't afford to make the trip, please let me know. At past events, the generosity of these scholarships has been amazing, and has meant a whole host of interesting people were able to benefit who would not have been able to otherwise. To those who can make a donation, you have my thanks. We'll post details of how to apply for scholarships after we get a sense for how many we will be able to award.
• Two new scholarship programs for lean startups 28 March, 2010, 8:16 am
  Thanks to the generosity of sponsors, I'm pleased to be able to announce two scholarship programs for upcoming lean startup events. The first, sponsored by IMVU, will provide free tickets to deserving companies who want to attend the  Startup Lessons Learned conference on April 23. I'm especially grateful to IMVU which is, after all, where I first experimented with many lean startup practices. Now the company is growing, profitable, and proving that lean startups can scale. Oh, and did I mention that they're hiring? It's an exciting time to join, as IMVU is poised for a year of explosive growth. What better way to learn how to build a lean startup than to see one up close and personal? Right. Scholarship: you can apply here until April 12. I'm hopeful that other companies will step up and become scholarship sponsors, too. This conference will be the first of its kind: an opportunity to have a conversation about the future of the lean startup movement. We want everyone who can contribute to that conversation to be there, regardless of their ability to pay. To ensure that those who are regular contributors to the movement to be able to attend as well, I've given each Lean Startup Meetup leader a set of discount codes and a few half-price tickets to distribute to their members. Please get in touch with your local meetup if you'd like to learn more. The second scholarship, sponsored by TechWeb, will provide free passes to the entire Web 2.0 Expo, including the Lean Startup Intensive on May 3. When I agreed to setup the Lean Startup Intensive this year, I required that it include a scholarship program for deserving startups who couldn't otherwise afford the price of admission. TechWeb has decided to expand this program to provide scholarships for the whole Web 2.0 Expo. You can apply here until April 15 or until they receive 100 submissions--whichever comes first.   I look forward to seeing many of you at these events. If you have any questions or are interested in becoming a sponsor, please get in touch.
• Speed up or slow down? (for Harvard Business Review) 25 March, 2010, 5:42 pm
  Over at Harvard Business Review, I've been building up a series designed to introduce the Lean Startup methodology to a business-focused audience. This is the first post that moves into making specific process recommendations for product development. Here's an excerpt: The Startup's Rules of Speed - The Conversation - Harvard Business Review Every startup that achieves success eventually faces a critical moment — whether to speed up or slow down. It usually looks like this: the can-do attitude and high-bandwidth communication that characterized the first few iterations have produced magic. Everyone was in the flow; the team was hyper-productive. In many cases, they did the impossible, building a new product faster, cheaper, and better than anyone could have predicted. In the early days, chaos stayed under control. Duplicating efforts and stepping on toes was quickly resolved by short all-hands meetings. Firefighting was part of the fun of living on the edge. Defective prototype code was as often thrown out (because customers didn't want it) as it was fixed (when customers did). Hence, cutting corners often paid huge dividends. And with success came growth: in resources, staff and attention. And a certain amount of chaos reigned too. But as the team gets bigger, early mistakes become more costly. Pretty soon, a soul-searching meeting ensues. 'Are we going too fast?' 'Will the addition of process kill our innovative culture?' 'Well-functioning teams just don't make these kinds of mistakes, right?' This is the speed-up-or-slow-down moment.Read the rest of The Startup's Rules of Speed - The Conversation - Harvard Business Review ... You can view previous essays in this series here: Is Entrepreneurship a Management Science? Two Ways to Hold Entrepreneurs Accountable Beware of Vanity Metrics  For Startups, How Much Process Is Too Much?
• The new startup arms race (for Huffington Post) 22 March, 2010, 5:41 am
  The Huffington Post published an op-ed on the Startup Visa movement that I've been working on for some time. I've quoted from the article extensively below, but I hope you'll take a moment and read the whole thing. I believe we have a unique opportunity to pass the Startup Visa Act this year - if we continue to stay focused on delivering the message to lawmakers that this is something their constituents want. So, as a reminder, if this is something you support, please get involved. You can literally make a difference with as little as a tweet, by using 2gov at http://startupvisa.2gov.org/. Once you've done that, let us know if you want to do more. You can find a list of ways to get involved at StartupVisa.com. Thanks! The New Startup Arms Race America's future prosperity depends on our ability to maintain this lead. But today, it is getting harder and harder to maintain. A quick glance is the rear-view mirror reveals that other countries are catching up and at an alarming rate. Part of this is due to their determination to overtake us, but part is due to structural changes in the nature of entrepreneurship. Startups are the lifeblood of our economy. In the past two decades, they have accounted for nearly all the net job growth in our country. Many of these companies are started by entrepreneurs, and are now household names: Google, Yahoo, eBay and Intel. But many more are true American success stories, out of the limelight, quietly creating jobs and securing our future. Take the example of Indiana's Passageways. Paroon Chadha came to the US for his graduate education, and was bitten by the entrepreneurial bug immediately after school. He started Passageways Inc. immediately upon graduating, and has spent the last 8 years struggling to work around visa restrictions. Luckily for the rest of us, he was able to find his path to a green card, and now employs 24 Americans in West Lafayette, Indiana. For every success story like Paroon's, there are dozens -- hundreds -- of similar cases that end in failure. Like other industries -- from publishing to automobiles -- entrepreneurship is in the process of being disrupted by globalization. The cost of creating new companies is falling rapidly, and access to markets, distribution, and information is within the reach of anyone with an Internet connection. The result is a profound democratization of the digital means of production. [...] If the next Facebook, Google, or Amazon begins in another country, the economic growth that it sparks will benefit us, too. But the jobs will be created over there. The United States is locked in a new arms race for that most precious resource -- the future entrepreneurs upon whom economic growth depends. Substantial research shows that immigrants play a key role in American job creation. For example, over 25% of the technology companies founded between 1995-2005 had a key immigrant founder. These companies produced over $52 billion dollars in sales in 2005, and employed 450,000 workers that year. Similarly, 24% of all the patents filed in the US in 2006 had a foreign resident as inventor or co-inventor. If we allow other countries to welcome these immigrants, support them and nurture them, we will lose out in this race. We will not lose on their products -- after all, most of them are global. We will not necessarily harm investors, either: as capital is increasingly global, they will be able to invest wherever good ideas are born. The cost will be felt in jobs -- thousands of new jobs that could have been created here, but weren't. Read the rest of The New Startup Arms Race at Huffington Post. Special thanks to everyone who's helped advance this movement, especially Brad Feld, Shervin Pishevar, Dave McClure, Dave Binetti and Abheek Anand. And an extra special thanks to the volunteer copyeditors who reached out via twitter to help improve this piece.
• For Startups, How Much Process Is Too Much? (for Harvard Business Review) 11 March, 2010, 6:53 am
  In the latest article for my series in HBR, I discuss the problem of how to figure out how much process startups should have. I often hear that what makes startups effective is their complete lack of process, but I don't think this is correct. Process is not the same as bureaucracy. In fact, I believe process is a form of discipline. When done right, it can help startups accelerate even as they scale. You can view previous entries: Is Entrepreneurship a Management Science? Two Ways to Hold Entrepreneurs Accountable Beware of Vanity Metrics I'm a little late on the cross-post, but hope you'll enjoy it nonetheless. For Startups, How Much Process Is Too Much? - The Conversation - Harvard Business Review: Still, startups develop some kind of process — whether it's disciplined, haphazard, bureaucratic or empowering — because building a great product depends on it. They just need to balance process with innovation. Companies that insist on building a world-class infrastructure before shipping a product are doomed to 'achieve failure,' because they're starved of feedback for too long. I learned this lesson first hand in a previous company (read the sad story here). On the other hand, companies that take a 'just do it' attitude without any process at all are also taking a major gamble. High-profile startup Friendster had first-mover advantage in the social networking space, but created openings for competitors when it could not scale to meet demand. Finding the right balance requires an understanding of the fundamental feedback loop that powers all startups. Read the rest: For Startups, How Much Process Is Too Much? - The Conversation - Harvard Business Review