67

Eric Ries

• 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:
• Why vanity metrics are dangerous 23 December, 2009, 9:55 am
  In a previous post, I defined two kinds of metrics: vanity metrics and actionable metrics. In that post, I took it for granted that vanity metrics are bad for you, and focused on techniques for creating and learning from actionable metrics. In this post, I'd like to talk about the perils of vanity metrics. My personal favorite vanity metrics is "hits." It has all the worst features of a vanity metric. It violates the "metrics are people, too" rule: it counts a technical process, not a number of human beings. It's a gross number, not per-customer: one hit each from a million people is a very different thing than a million hits from just one person. Most normal people don't understand it: what counts as a hit, anyway (an image, a page, a JS file...)? And it has no built-in measure of causality: if we get a million hits this month, what caused them? How could we generate more hits? Are those hits all of equal value? Since each of these questions requires diving into a different sub-metric, why not just use those metrics instead? That's the essence of actionable metrics. But actionable metrics are more work. So it's reasonable to ask: what's wrong with vanity metrics, at least as a proxy for customer behavior? If hits are bigger this month than last month, that's progress. Why do we need to ask hard questions about the metric, if it's at least directionally correct? When we rely on vanity metrics, a funny thing happens. When the numbers go up, I've personally witnessed everyone in the company naturally attributing that rise to whatever they were working on at the time. That's not too bad, except for this correlate: when the numbers go down, we invariably blame someone else. Over time, this allows each person in the company to live in their own private reality. As these realities diverge, it becomes increasingly difficult for teams to reach consensus on what to do next. If those teams are functionally organized, the problem is amplified. If all the engineers work on the same thing at the same time, and all the marketers do the same, and QA, and ops, all the way down the line, then each department develops its own team-based private reality. Now picture product prioritization meetings in such a company. Each team can't believe those idiots down the hall want to try yet another foo project when it's so evident that foo projects always fail. Have you ever built one of those charts that shows a metric over time, annotated with "key events" that explain what happened to the numbers at key inflection points? If you never have, you can create your own using Google Finance. Go ahead and try it, then come back. You've just experienced vanity metrics hell. Everyone knows those charts are totally unpersuasive. At best, they can only show correlation, not causation. Sure I can build a stock chart, like this one, that shows that eBay's stock price went into a four-year decline immediately after "eBay Inc Acquires Dutch Company Marktplaats.nl." But do you really believe that's what caused eBay's problems? Of course not. At worst, these kinds of vanity metrics can be easily used for gross distortions. And that potentiality can cripple companies at just those key moments when they need to understand their data the most. Let me take an example from a company that was going through a tough "crossing the chasm" moment. They had just experienced two down quarters after many quarters of steady growth. Naturally, they had just raised money, and their new investors were understandably pissed. The company struggled mightily with how to explain this bad news to their board. They were accustomed to measuring their progress primarily by gross revenue compared to their targets. When the numbers started to go down, they started to investigate. It turned out that, during the course of the decline, one customer segment was losing customers while another was gaining customers. It's just that the declining segment's customers were more valuable. In retrospect, I can see the irony of the situation perfectly. This decline was actually the result of the company successfully executing its strategy. The customers on their way out were more valuable in the short-term, but the new customers coming in were where the real growth was going to happen in the long-term. Unfortunately, the magnitude of the shift, and the relative values of the two segments, took the company by surprise. Guess how well those board meetings went. All of the sudden, now that the company was struggling, new metrics were being used to judge success. The vanity charts appeared, showing the changes the company had made to its strategy and the subsequent changes in customer behavior broken down by segment. All very reasonable, well designed, well argued. In other words, a total disaster. This board had no way to know if they were hearing real insight or just well-crafted excuses. The insight turned out to be correct (it's always clear in hindsight). Too bad several of the executives making that presentation weren't around to be vindicated. The whole situation could have been avoided if the company had used actionable metrics to set and evaluate goals from the start. The strategy changes could have been rolled out gradually, segment by segment, in controlled trials. The data from those trials could have been used to predict the future effects, and allowed the company to make smarter decisions. Actionable metrics don't guarantee you'll make good decisions. But at least you can have facts in the room at the time. And that's my metrics heuristic. Consider a team's last few critical decisions. Not the ones with carefully choreographed discussion and a formal agenda. Those are the easy meetings. I'm talking about the adhoc crisis decisions, the periodic product prioritization meetings, and the failure post-mortems. How much actionable data was in the room at the time? With data, teams have an opportunity to improve their decision making over time, systematically training their intuition to conform to reality. Without it, they're just rolling the dice. And that's why vanity metrics are dangerous.
• Speaking 2010: Webstock, GDC, Web 2.0, and more 6 February, 2010, 2:48 pm
  I've been trying hard to cut back on travel in 2010 so as to have more time for writing. I started to feel like my blog became too much of a travel diary last year - and I still have many videos and presentations from last fall that I haven't shared yet. If you'd like to see me speak this year, there are only a few opportunities scheduled. Next week, I'll be in New Zealand for Webstock 2010. I'll be giving a day-long workshop as well as a keynote address.They've got a great programme; my workshop will be on Monday, February 15 and my keynote will be Friday, February 19. I'll also be stopping by Kiwi Foo. If you're at either event, please do come say hello. In March, I'll be speaking at the Game Developers Conference in San Francisco. Since we'll have a game-oriented crowd, I'll be talking more about my "virtual worlds" background than I normally do. I often get asked how lean startup ideas can work for the video game industry - which is, of course, where I originally started working on them. The talk itself will be Tuesday, March 9 at 11:15am. In April, stay tuned for word on the Startup Lessons Learned Conference, which will also be held in San Francisco. Rather than make a premature announcement, I'll invite you to take the survey and help us make the event better. In May, I'll be giving a keynote address at the Web 2.0 Expo in San Francisco. I'm especially excited about this, because last year's Expo was the very first time I'd given the lean startup presentation to a large audience. The enthusiastic reception that day was part of what gave me the confidence to leap into this job full-time. I'm quite grateful to everyone who attended, and to the organizers who made it possible. This year, lean startups will be a big part of the Web 2.0 Expo. In addition to my keynote, Steve Blank will be speaking. There's also a one-day Lean Startup Intensive on the first day of the conference (May 3). This will be a kind of "lean startup all-stars" event featuring a number of speakers and panels. Watch this blog for details. You can register for the intensive here. Thanks to the support of TechWeb, we'll be organizing a scholarship program for this event (stay tuned). Last, there are five large-scale sponsorship spots open for the event. If you've ever wanted to be a sponsor of a big event like the Web 2.0 Expo, but don't want to have your logo lost in the sea of sponsors, perhaps this would be a good choice. To get more info about sponsorship, you can contact Susan Young. And, if you can't make it to any events this year, you can still catch the video. For example, here's the video of my talk last month at Twiistup in Los Angeles (slides are posted here): I try to post event-related updates to Twitter, but if you want to subscribe to my event-specific plans directly, I'm trying Plancast (a new startup founded by a friend). You can subscribe to my plans here. Last, for those who are following the Startup Visa movement, we're planning a trip to DC in early March. If you'd like to participate, you can subscribe for updates on our Plancast page.
• Lo, my 18891 subscribers, who are you? 25 January, 2010, 12:29 am
  Way back when I first started blogging, I was amazed to have any subscribers at all. In fact, when I crossed the five subscriber threshold, I was moved to write about my excitement and about the advantages of having a pathetically small number of customers. And, in the survey that was attached, I learned a lot of useful information about how to make this blog better. Since then, I've tried to make it a regular habit to collect real data about what you think. Welcome to the latest installment. Since the last time, your support has been overwhelming: your ranks have grown almost a full order of magnitude. To all of you who've taken the time to subscribe, who have convinced a friend to subscribe, or even talked your co-workers into it, let me say thank you. Your support makes everything I do possible, and I won't ever get tired thanking you for it. For those who have been readers for some time, the survey below will seem familiar. I sometimes use these surveys to test new product ideas and even to engage in some customer validation. Today is no exception. If you're curious, please take the survey to learn more. I don't want to say anything here that would bias the results. As usual, I'll share what I learn and how it affects what I'm up to next. Thanks again for stopping by. Without further ado: Click here to take survey
• What is Lean about the Lean Startup? 16 December, 2009, 3:08 pm
  The first step in a lean transformation is learning to tell the difference between value-added activities and waste. That foundational idea, so clearly articulated in books like Lean Thinking, is what originally led me to start using the term lean startup. I admit that I haven't always done such a good job emphasizing this connection; after all, there's an awful lot to the lean startup theory, and I'm always struggling with how best to explain it fully. Luckily, I've had some excellent backup. The following is a guest post for Startup Lessons Learned by the legendary Kent Beck. One of the most amazing things about the past year has been the opportunity to meet many legends and personal heroes. And yet, I have a confession to make. Many of these heroes have proved disappointing: some have been defensive, stand-offish, and downright mean. Not so with Kent Beck.  Longtime readers will recall how I first met him. I was giving my first-ever webcast on the lean startup. For those who've heard it, it contains a length discourse on the subject of agile software development and extreme programming, including its weaknesses when applied to startups. Now, this webcast was packed, hundreds of people were logged in. The chat stream was flying by in my peripheral vision, a constant distraction, hard to focus on. As I'm pontificating about agile, I see the name Kent Beck in my peripheral vision. I was truly terrified, and I almost completely lost my train of thought. Was that really the Kent Beck? I assumed he was there to refute my critique of extreme programming, but nothing could be further from the truth. In fact, of all the gurus and leaders I've had the chance to meet, he has been by far the most open-minded. He instantly understood what I was saying, and since that first encounter, our exchanges have made me a lot smarter.  So when he weighed into a recent thread on the Lean Startup Circle mailing list on this very subject, I asked if he would expand his comments into a guest post. The following is the result. - Eric Names matter. By pulling in a web of associations, names help people quickly assess ideas. Chosen well, they draw attention from people likely to appreciate the ideas they identify. There is a dark side to naming. When a name is misused, as with some of the claims to "agility" extant, the initial interest is followed by disappointment when customers discover there is no corned beef between the slices of rye. It's tempting to ride the coattails of a popular idea by using a word with momentum, but in the end it backfires for the idea and the word. The naming question has been raised about the "lean" in Lean Startups. Are lean startups really lean or was the word chosen because it is widely recognized and popular? I had a background in lean manufacturing (book knowledge, anyway) and lean software development (hands on) before encountering Lean Startups. When I read Eric's blog I immediately felt at home: the principles were the same even though some of the practices were different. The foundation of TPS (Toyota Production System) is that people need to be (and feel) productive and society needs people to produce value. This value is evident in Lean Startups. We are all engaged in creating valuable (we hope) services for society in some form or other and simultaneously meeting our own need to feel significant and productive. Another basic principle of TPS is respect for people. One form of respect is not wasting the time of people who are creating new products and services. Another form of respect is inviting customers to be part of the process of creating those products and services. At times on this lean startup mailing list I hear an undercurrent of "ha, ha, I got you to give me feedback on this fake landing page even though I gave you nothing in return," which is a violation of this principle of respect. Overall, though, Lean Startups seems far more respectful to me than the "build something big and shove it down customers throats" model I have participated in (and failed with) over and over. TPS focuses on eliminating waste. Rather than try to create value faster (I'm thinking of Charlie Chaplin in "Modern Times" or Lucille Ball's Candy Factory scene), a lean organization creates more value by eliminating waste. This principle appears throughout Lean Startups, starting with the biggest waste of all in a startup--building something no one uses. A TPS tactic that familiar in lean startups is reducing inventory. If you can split a feature in half and get good feedback about the first half, do it. The lack of inventory enables quick changes of direction, something seen in Lean Startups in the pivot and in TPS in the ability of a single production line to create multiple vehicles. I haven't seen an equivalent of the systematic elimination of work-in-process inventory in Lean Startups, however. (Those who are interested in work-in-process might want to take a look at Work in small batches and Continuous deployment - Eric) Some specific TPS practices appear in Lean Startups. A/B testing is set-based design. 5 Whys is straight out of the Toyota playbook. Conversion optimization is a form of kaizen. Whether practices work directly is not as important as whether the principles are alive, though. I see the lean principles throughout Lean Startups. Is the "lean" in Lean Startups an illegitimate attempt to steal some of the "lean foo"? I don't think so. It doesn't look precisely like manufacturing cars, but the principles are shared between the Lean Startups and a lean manufacturing system like TPS, and to some extent even the practices. I expect the cross-fertilization to continue, even as Lean Startups discover what is unique about the startup environment and what calls for a unique response.
• The Lean Startup Intensive at Web 2.0 Expo SF (May 3, 2010) 12 April, 2010, 5:41 am
  I'm discovering the truth of the old saying, "when it rains, it pours." I keep waiting for the tide of interesting people, opportunities, and ideas to ebb - but so far it has done nothing but accelerate. Thank you all so much. Just one year ago, I gave my first big conference talk at the 2009 Web 2.0 Expo in San Francisco. I had no idea what to expect, and the response was truly humbling. So I am particularly excited that the Lean Startup is a big part of this year's Web 2.0 Expo. Steve Blank and I are both giving keynotes in the main conference track. And for those who want more than just the overview, we're offering the Lean Startup Intensive on the first day of the conference: May 3, 2010. We've built the Intensive into an all-star program designed to give a comprehensive overview of the methodology, taught by its leading practitioners. Unlike the conference on April 23, the Intensive does not assume any prior knowledge of lean startups, and is designed for a wide audience. Anyone who's thinking of attending the Expo will get something out of it. I believe it will be the first time each of the following speakers will be presenting a full session back-to-back: Steve Blank, Dave McClure, Sean Ellis, Hiten Shah, Dan Martell, as well as an investing panel which we'll announce soon. Here's an excerpt from the official program: “A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.” All entrepreneurs face the same fundamental challenges: How do we know if we’re making progress? How do we know if customers will want the product we’re building? And, if they do, how do we know what kind of value we can create with it? But because every startup also strives to become an institution, answering these questions requires more than just disciplined thinking at the whiteboard. It requires the coordination of many different people, working in concert to answer them. In other words, it requires management.[...] This event brings together the leading thinkers and practitioners of the Lean Startup movement. The goal is to provide a complete introduction to the theory as well as a grounding in advanced techniques that you can put to immediate use. This program is designed for people who have a stake in creating great products: engineers, designers, product managers, marketers and businesspeople—from companies of any size. And, of course, for present or future entrepreneurs who are hoping to do more than punch a lottery ticket. Read the rest here... I'm incredible excited about the lineup, and think it'll provide the world's first comprehensive introduction to these ideas. If you're thinking of attending the Web 2.0 Expo, I hope you'll consider spending your first day with us.  To sweeten the deal, we also have a special 25% discount code which you can use for either the Intensive itself or for a whole Expo pass. The code is websf10ls25 and can be redeemed here. And there are still a (very) few application spots open for a complete conference pass scholarship; details are available here. So yes, there are two major lean startup events coming up in San Francisco in the next month. Both are going to be amazing, so take your pick. And, as always, if you do decide to stop by, please say hello and let me know you're a reader. I'm looking forward to meeting you.
• Case Study: Continuous deployment makes releases non-events 18 January, 2010, 1:45 am
  The following is a case study of one entrepreneur's transition from a traditional development cycle to continuous deployment. Many people still find this idea challenging, even for companies that operate solely on the web. This case presents a further complication: desktop software. Without being able transparently modify the software in situ, is it still possible to deploy on a continuous basis? Read on to find out. Ash Maurya is the founder of WiredReach, a bootstrapped startup that he has been running for seven years. Recently, he was bitten by the lean startup bug and has started writing about his experiences attempting to apply lean startup and customer development principles. I've previously named his post Achieving Flow in a Lean Startup as one of my favorite blog posts of 2009.  What follows is his own account of the challenges he faced as well as the solutions he adopted, lightly edited for style. If you're interested in contributing a case study for publication here, consider getting started by adding it to the Lean Startup Wiki case study section. -Eric Of all the Lean Startup techniques, Continuous Deployment is by far the most controversial. Continuous Deployment is a process by which software is released several times throughout the day – in minutes versus days, weeks, or months. Continuous Flow Manufacturing is a Lean technique that boosts productivity by rearranging manufacturing processes so products are built end-to-end, one at a time (using singe-piece flow), versus the more prevalent batch and queue approach. Continuous Deployment is Continuous Flow applied to software. The goal of both is to eliminate waste. The biggest waste in manufacturing is created from having to transport products from one place to another. The biggest waste in software is created from waiting for software as it moves from one state to another: Waiting to code, waiting to test, waiting to deploy. Reducing or eliminating these waits leads to faster iterations which is the key to success. My transition to Continuous Deployment Prior to adopting continuous deployment, I used to release software on a weekly schedule (come rain or shine) which I viewed as pretty agile, disciplined, and aggressive. I identified the must-have code updates on Monday, official code cutoff was on Thursday, and Friday was slated for the big release event. The release process took at least half a day and sometimes the whole day. Dedicating up to 20% of the week on releasing software is incredibly wasteful for a small team. This is not counting the ongoing coordination effort also needed in prioritizing the ever-changing release content for the week as new critical issues are discovered. Despite these challenges, I fought the temptation to move to a longer bi-weekly or monthly release cycle because I wanted to stay highly responsive to customers (something our customers repeatedly appreciate). Managing weekly releases got a lot harder once I started doing customer development. Spending more time outside the building, meant less time for coding, testing, and deploying. Things started to slip. That is when I devised a set of work hacks to manage my schedule (described here) and what drove me to adopting Continuous Deployment. My transition from staged releases to continuous deployment took roughly 2 weeks. I read Eric Ries' 5 step primer to getting started with Continuous Deployment and found that I already had a lot of the necessary pieces. Continuous integration, deployment scripts, monitoring, and alerting are all best practices for any release process - staged or continuous. The fundamental challenge with Continuous Deployment is getting comfortable with releasing all the time. Continuous deployment makes releases non-events and checking in code is synonymous with triggering a release. On the one hand, this is the ultimate in customer responsiveness. On the other hand, it is scary as hell. With staged releases, time provides a (somewhat illusory) safety net. There is also comfort in sharing test responsibility with someone else (the QA team). No one wants to be solely responsible for bringing a production system down. For me neither was a consideration. I didn't have time or a QA team. I took things easy at first - made small changes and audited the release process maniacally. I started relying heavily on functional tests (over unit tests) which allowed me to test changes as a user would. I also identified a set of events that would indicate something terribly going wrong (e.g. no users on the system) and built real-time alerting around them (using nagios/ganglia). As we built confidence, we started committing bigger and multi-part changes, each time building up our suite of testing and monitoring scripts. After a few iterations, our fear level was actually lower than how we used to feel after a staged release. Because we were committing less code per release, we could correlate issues to a release with certainty. These days, we never wonder if unexpected errors could have been introduced as a result of a large code merge (since there is no branching. We also rely on more testing and monitoring automation, which is way more robust and consistent than what we were doing before. All that said, mistakes are still made and we commit bad code now and then. None that have taken the system down (not yet anyway). Rather than seeing these as a shortcoming of the process, we view it as an opportunity to build up our Cluster Immune System. We try and follow a Five Whys approach to keep these errors from recurring. There is always some action to take: writing more tests, more monitoring, more alerts, more code, or more process. Looking back, struggled to balance the opposing pulls of "outside the building" versus "inside the building" activities. Adopting Continuous Deployment has allowed me to build "flow" into my day which allows me to do both. But easier releases are not the only benefit of Continuous Deployment. Smaller releases lead to faster build/measure/learn loops. I've used these faster build/measure/learn loops to optimize my User Activation flow, delight customers with "near-instant" fixes to issues, and even eliminate features that no one was using. While it is somewhat easier to continuously deploy web based software, with a little discipline, desktop based software too can be built to flow. Here's how I am implement continuous deployment for my desktop-based application (CloudFire). My Continuous Deployment process Don't push features If you've followed a customer discovery process, identified a problem worth solving, and built out your minimum viable product, DON'T keep adding features until you've validated the MVP, or more specifically the unique value proposition of the MVP. Unneeded features are waste and not only create more work but can needlessly complicate the product and prolong the "customer validation" phase. Every new feature should ideally be pulled by more than one customer before showing up in a release. Build in response to a signal from the "customer", and otherwise rest or improve. As a technologist, I too love to measure progress based on how much stuff I build. But instead of channeling all my energy towards building new features, I channel roughly 80% of it towards measuring and optimizing existing features. I am not advocating adding no features at all. Users will naturally ask for more stuff and your MVP by definition is minimal and needs more love. Just don't push it. Code in small batches I've previously described my 2 hour blocks of maker time for maximizing my work "flow". Prior to starting any maker activity, I clearly identify what needs to get done (the goal) and sketch out how it needs to get done (the design). It is important to point out that the goal of the maker activity need not be a user facing feature or even a complete feature. There is inherent value in committing incremental work into production to diffuse future integration surprises. During the maker activity, I code, unit test, and create or update functional tests, as needed. At the end of the maker activity, I check-in code which automatically triggers a build on a continuous integration server that is then run through a battery of unit and functional tests. The artifacts created at the end of the build are installers for mac and windows (for new users) along with an Eclipse P2 repository (OSGI) for automatic software updates (for current users). The release process takes ~15 minutes and runs in the background. Prefer functional tests over unit tests whenever possible I don't believe in blindly writing unit tests just to achieve 100% code coverage as reported by some tool. To do that I would have to mock (simulate) too many critical components. I deem excessive unit testing a form of waste. Whenever possible, I rely on functional tests that verify user actions. I use Selenium, which lets me control the application on multiple browsers and OS platforms, just as a user would. One thing to be wary of is that functional tests are longer running than unit tests and will gradually increase the release-cyle-time. Parallelization of tests with multiple test machines is a way to address this. I am not at that point yet but Selenium Grid looks like a good option. So does Go Test It. Always test the User Activation flow After the integration tests are run and the software packaged, I always verify my User Activation flow before going live. The user activation flow is the most critical path towards achieving initial user gratification or product/market fit. My user activation flow is automatically tested on both a mac and windows machine. Utilize automagic software updates A major challenge with desktop-based (versus web-based) software is propagating software updates. Studies have shown that users find traditional software update dialogs annoying. To overcome this, I am using a software update strategy that works silently without ever interrupting the user, much like an appliance. Google Chrome utilizes a similar update process. The biggest risk with this approach is that users will find it Orwellian. So far no one has complained, and many users like the auto-update feature. It helps that CloudFire, being a p2web app, runs headlessly with a browser-based UI. This is how the software update process currently works: At the end of each build, we push an Eclipse P2 repository (OSGI) which is a set of versioned plug-ins that make up the application. Because the application is composed of many small plug-ins, coupled with the fact that we commit small code batches, the size of each software update can be downloaded quickly. Every time the user starts up the application, it checks for a new update, downloads and installs one if available. Depending on the type of update, it could take effect immediately or require an application restart. If an application restart is required, we wait until the next user initiated relaunch of the application or trigger one silently when the system is idle. If the application is already running, it periodically polls for new updates. If an update is found, it is also downloaded and installed in the background (as above) without interrupting the user. Alerts and monitoring I use nagios and ganglia to implement both system and application level monitoring and alerting on the overall health of the production cluster. Examples of things I monitor are the numbers of user activations, active users, and aggregate page hits to user galleries. Any out-of-the-norm dip in these numbers immediately alerts us (via twitter/SMS) to a potential issue. Application level diagnostics Despite the best testing, defects still happen. More testing is not always the answer as some defects are intermittent and a function of the end-user's environment. It is virtually impossible to test all combinations of hardware, OS, browsers, and third party apps (e.g. Norton anti-virus, Zone Alarm, etc.). Relying on users to report errors doesn't always work in practice. To compensate, we've had to build  basic diagnostics right into the application itself. They can notify both the user and us of unexpected errors, and allow us to pull configuration information and logs remotely. We can also do remote rollbacks this way. Tolerate unexpected errors exactly once Unexpected errors provide the opportunity to learn and bullet-proof a system early. Ignoring them or implementing quick-and-dirty patches inevitably lead to repeat errors which are another form of waste. I try and follow a formalized Five Why's process (using our internal wiki) for every error. This forces us to really stop, think, and fix the right problem(s). My continuous deployment process is summarized below: So why is Continuous Deployment so controversial? Eric has addressed a lot of the objections already on his blog. One that I hear a lot is the belief that you need a massive team to pull off continuous deployment. I would argue that the earlier in the development cycle and the smaller the team, the easier it is to implement a continuous deployment process. If you are a start-up with a MVP, there is no better time to adopt a continuous deployment process than the present. You don't yet have hundreds of customers, dozens of peers, or dozens of features. It is a lot easier to lay the groundwork now with time on your side. If you enjoyed Ash's writing in this case study, I suggest you subscribe to his blog. -Eric
• Amazing lean startup resources 12 January, 2010, 4:11 pm
  A year ago, there was no lean startup movement. The term was known by maybe a few dozen people. Being an evangelist for these ideas earned me a regular diet of funny looks and patronizing comments. At that time, my wildest dreams did not include even a fraction of what's happened since. I continue to believe that the explosion of interest in the lean startup has very little to do with me. Rather, I see it as a reflection of a worldwide openness to new ideas about entrepreneurship. Recent economic events, technological change, and the rapid diffusion of information about the old models have combined to help us all realize just how important entrepreneurship is - and just how little we really know about it. Beyond my own efforts on this blog (and more), there is now an amazing variety of resources for lean startup practitioners. For those that are following me on Twitter, you've probably seen many of these. But I wanted to create a centralized directory. If you are attempting to apply lean startup ideas in your own business - you are not alone. The Lean Startup Wiki (hosted by long-time lean startup pbWorks) contains a number of resources, including links to case studies, meetups, tools, and people who have volunteered to help. It's a wiki, feel free to consume and enhance it. Rich Collins organized the Lean Startup Circle mailing list, the most robust discussion forum for lean startup ideas anywhere, with over two thousands members already. For the many entrepreneurs that send me cold emails asking for me to review a business plan or answer a strategic dilemma: I'm much more likely to answer if you've already tried getting an answer on the mailing list. You'll probably get a better result, anyway. The #leanstartup hashtag on twitter has become a firehose of information, but seems to feature great new links almost every day. I also use it to collect feedback from all my talks and presentations, so it's a great place to find out what real people think about the ideas. Rich also organized the first Lean Startup Meetup right here in San Francisco. The SF Meetup now has over five hundred members, and has spawned many other meetup events. There's probably one in a city near you. Some of the most active: SF, New York, DC, Chicago - but there are many more listed here. I also recommend SKMurphy's excellent Bootstrappers Breakfast series, which is now in multiple cities. Not coincidentally, they were one of the first organizations to host me as a speaker. If you want to create or join a meetup near you, just leave a note in the appropriate section of the meetup directory. There are efforts underway in more than a dozen cities to start a regular meeting. If you need a first speaker, I'm happy to join by skype. There are also an impressive array of bloggers writing about these ideas. When I first started blogging, the startup blogging mafia immediately came to meet me and find out who I was: Dave McClure, Andrew Chen, Sean Ellis and Venture Hacks. My success is due in no small part to their early and enthusiastic endorsement. And Steve Blank (a long-time mentor) has made the leap to blogging in impressive fashion. Yet beyond these usual suspects are a huge number of up-and-coming bloggers, most of whom are practicing entrepreneurs willing to share their lean startup stories. Some of my favorites: Ash Maurya (whose Achieving Flow in a Lean Startup was one of my favorite posts of 2009), Brant Cooper, CindyAlvarez, Laura Klein, Kevin Dewalt, Giff Constable - and I must be missing many more. Have a favorite who I overlooked? Please share in a comment. Last, I've tried to keep this blog updated with events, slides, audio, video and books that are helpful as well.  Did I miss anything? Please feel free to use the comments on this post to share any and all resources you've found helpful. Most of all, thank you for your continuing support. Together we can change our  industry for the better.
• Business ecology and the four customer currencies 14 December, 2009, 5:58 am
  Lately, I’ve been rethinking the concept of “business model” for startups, in favor of something I call “business ecology.” In an ecosystem, each participant acts according to its own imperatives, but these selfish actions have an aggregate effect. Some ecosystems are stable, others malign, and others grow and prosper. A successful startup strives for this latter case. I think this concept is necessary in order to answer the truly vexing startup questions, like: “Should startups charge customers money from day one?” Let’s begin with the four customer currencies. I had a lot of use for this concept back when I worked on game design and virtual worlds. In order to maintain game play balance, game designers have to take into account the needs of customers who have an excess of four different assets: time, money, skill, and passion. If players with more money than others can simply buy their way to the top of the heap, a multiplayer game fails – because this makes the game un-fun for other players. The same is true if kids who have an unlimited amount of time on their hands are guaranteed the top spot – this isn’t going to be very fun for the busy professionals who want to play only casually. Chess is only fun for those who have the requisite skill to play well – and even then, only if there are ranking systems to make sure that players of relatively equal skill play each other. If you could buy a higher chess ranking or, worse, simply grow it by logging more hours, that would ruin the system for everyone. And passionate players are often the backbone of game communities – especially online. They run the clubs, forums, groups and mailing lists that make the game more fun overall. If they are barred from participating (say, because they lack the skill needed to prevent advanced players from killing them all the time), the game is worse off. Each of these four currencies represents a way for a customer to “pay” for services from a company. And this is true outside of games. Constructing a working business model is a form of ecosystem design. A great product enables customers, developers, partners, and even competitors to exchange their unique currencies in combinations that lead to financial success for the company that organizes them. Here’s the ecosystem we built at IMVU, just to give one example. We cultivated a passionate community that nurtured a skilled set of developers. Those developers create an incredible variety of virtual goods: 3D models, textures, homepage stickers, music, and much more – more than three million in total last time I checked. This variety entices millions of end-users to invest their time and passion with IMVU, providing many incentives for a small fraction of those users to become paying customers. Those paying customers provide IMVU with sufficient profits to reinvest in the core experience for everyone. It’s a working, growing, ecosystem. Having a balanced ecosystem is what game designers strive for. But startups strive for something else: growth. Thus, business ecology is concerned with both ecosystem design and finding a driver of growth for that ecosystem. In a previous post, I covered the three main drivers of growth: Paid, Sticky, and Viral. When a startup finds a working value-creating ecosystem that supports one of these drivers of growth, watch out. They’re off to cross the chasm. And this is why questions like “Should a company charge money from day one?” are nonsensical. Some companies definitely should. Others definitely shouldn’t. In order to tell which is which, you have to understand the unique ecology of the business in question.  Let’s look at some examples: In a traditional business, customers pay money for a physical artifact (a product) or a service. Companies use that money to market the product or service to more customers. This is the simplest ecosystem and simplest driver of growth. A business that strives for something like this should absolutely be charging money from day one, in order to establish baselines for their two key metrics: CPA (the cost to acquire a new customer) and LTV (the lifetime value of each acquired customer). In other words, the minimum viable product is designed to answer the question: does the product generate enough demand and margin to support a growing ecosystem?   Now consider a traditional media business. By paying money to content creators (ie writers, producers, talent), the business uses builds up assets that are of interest to other consumers. Those other consumers pay for this content sometimes with money, but more often with their attention. This attention is valuable to yet another set of people: namely, the traditional businesses (see above) who are using marketing to grow, and are looking to advertise to new prospects. The value of the attention that the media company collects determines how profitable it is. In the old days, these media companies would then themselves plow this profit back into marketing and advertising, and grow. Today, many of these businesses are suffering because the ecosystem no longer balances thanks to the Internet. (Sorry about that.) If you’re starting a new media company, does it make sense to charge from day one? Probably not – you need to be finding an audience, making sure that audience will trade you their attention for your content, and – most importantly – establishing a baseline for how much that attention is worth to advertisers. A minimum viable product in this category must answer the question: does my media content or channel command the attention of a valuable audience? Let’s look at a viral growth company, like Facebook. They are a classic case of a company that doesn’t seem to care about charging customers money. Here’s Andrew Chen’s description: “it strikes me that consumer internet companies often don’t care much whether or not they have viable businesses in the short run. If you are building a large, viral, ad-support consumer internet property, you just want to go big! As soon as possible!” This is a common sentiment, but I don't agree. I think it uses the phrase “viable business” in too narrow a sense. When Facebook launched early-on at college campuses, it was immediately apparent that they had a viable business, even though they weren’t charging customers for anything. Why? Because they were collecting truly massive amounts of attention and they had an amazing driver of growth. Those two factors made it relatively easy for them to raise enough money to avoid having to build a profitable business in the short term. But that doesn’t mean they didn’t have a viable one. The ecosystem worked, and was growing. Figuring out how to turn that attention into cash seems to have been pretty obvious to Mark Zuckerberg. For a true viral ecosystem, the minimum viable product is designed to answer the question: can I unlock viral growth mechanics while still keeping my ecosystem alive? As many viral companies have found to their chagrin, quite a few viral products are fundamentally useless. Although they grow, they don’t actually collect enough of any customer currency to be viable. In fact, the viral metaphor is actually more apt than many people realize, once you look at it from an ecological perspective. Facebook is actually quite rare – many other viral products didn’t really build their own working ecology: they colonized someone else’s. That was true for Paypal cannibalizing eBay, YouTube and MySpace, and could still be true of Slide, Zynga, or RockYou – we’ll see. Now, Andrew’s excellent piece that I quoted from above correctly diagnoses two situations where consumer internet companies often get in trouble: They focus too much on short-term revenue, getting caught in a local maximum via constant optimization. They aren’t really engaged in customer development, they aren’t getting inside their customers’ heads, and they aren’t crafting a robust ecosystem. For a consumer internet company in particular, this is often due to a lack of design thinking. They get focused solely on growth. This isn’t helpful either, as countless companies have shown. If you haven’t figured out the ecosystem, growth is useless – whether it is a acquisition-only viral loop, like Tagged, or an advertising blitz like countless dot-bombs. Let’s consider one last example, a sticky-growth company like eBay or World of Warcraft. Here the goal is to create a product whose ecosystem makes it hard for customers to leave. eBay offers their customers an opportunity to monetize their skill and passion via online trading for hard currency. World of Warcraft offers beautifully balanced and addictive game play, for which customers trade all four currencies in bewildering combinations. Like eBay, these investments are best understood as trades between players, which is what makes multiplayer game design so much harder than its single-player counterpart. What these products all have in common is the question their minimum viable product is attempting to answer: does this product have high natural retention built-in? Understanding the four customer currencies allows us to avoid these problems, and also unify a number of different concepts that have been floating around. Take the minimum viable product, for starters. How should the word viable be understood? Here’s the original definition I proposed for MVP: “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” Of course, this begs the question: what are we trying to learn? Now I think I can answer this question with some certainty: we want to learn how to construct a business ecology harnessed to the right driver of growth. And how do we validate that learning? By creating a model of the ecosystem we want, and showing that actual customer behavior conforms to that model. And, of course, if customers don’t behave the way we expect, it’s time to pivot. That necessarily means that different types of startups will be seeking to learn different things. Minimum viable product is a tactic for mitigating risk. It doesn’t say anything about which risks it should be used to mitigate. Startup founders need to use their own judgment to ask: which is the riskiest assumption underlying my business plan? In each of the ecosystem examples I gave above, the tactics of the minimum viable product are quite different. In some cases, Tim Ferriss-style landing page tests will suffice. Others require Steve Blank-style problem/solution presentations. And others require an early product prototype. The level of design required will vary. The level of engineering quality will vary. The amount of traditional business modeling will vary. And now we can answer the biggest question of all: how do we know it’s time to scale? Or, to borrow Steve Blank’s formulation, how do we know it’s time to move from Customer Validation to Customer Creation? I think I have a solid answer here too: when we have enough data that shows our business ecology is value-creating and also ready to grow via a specific driver of growth. Founders struggle with this question. Successful startups don’t. In almost every case I’m aware, the question never had to be asked. When an ecosystem is thriving and growing, it takes work just to keep up with its scaling needs. This was true at Facebook, eBay, and Google – and at countless other successful startups. Marc Andreessen has already coined a phrase for what it looks like: product/market fit. One clue that you don’t have product/market fit – you’re trying to evaluate your business to see if you have it. It’s probably time to pivot. These concepts have important implications for any lean startup. My whole goal with the lean startup movement has been to learn how to tell the difference between value-creating activities and waste in startups – and then to start eliminating waste. In an entrepreneurial situation, this is hard, because artifacts that we are creating (products, code, marketing campaigns, even revenue) are of secondary importance. The real value we create is learning how to craft profitable ecosystems. Even then, it’s the learning that’s the real value. So, when evaluating any activity, ask: is this helping me learn more about my startup’s ecosystem? If not, eliminate it. If so, ask: how could I get even more learning while doing even less work? Most of all, beware one-size-fits-all startup advice. In order to figure out what applies to your unique situation, focus on the principles. Who are the customers? What currencies do they have? And what problems do they need solved? Look for a balanced ecosystem and a driver of growth. And be sure to hold on to the reins once you find it.
• Sneak preview, Grockit 14 April, 2010, 12:28 pm
  Hear the CEO of Grockit give a sneak preview of what he'll be presenting at the Startup Lessons Learned conference on April 23: