I haven't had much time to write lately, and so haven't been able to share much about the Lean Startup Workshop series I have been producing with O'Reilly in their Master Class division. We had the first event last month, and the next is coming up on June 18th. The May workshop was a huge success, with much better turnout and feedback than I had any right to expect. I'm incredibly grateful to the early adopters who were able to be there. Thank you all.
Part of what made the workshop so successful was the caliber of the participants in the room. These were serious entrepreneurs who have the vision to see how the lean startup concept can help them increase their odds of success. Thus, the quality of the questions I was asked, the discussion in the room during exercises, and the overall intensity was higher than anything I've experienced in any other venue. That's why I'm so excited about this format. (For more on what it was like, you can read an in-depth review from the first workshop here).
So far, we have limited registration at the workshops to people who can afford the admittedly high cost of entry. I believe this is part of what made the first workshop such a success - the people in the room were visionary customers who therefore came ready to work, not just to be entertained (by contrast with what I see at some of my speaking engagements). However, this financial bar has had the effect of excluding one segment of potential customers that I'd really like to see there - early stage entrepreneurs who have all the intelligence and vision of their later stage counterparts, but simply cannot afford the cash flow to attend.
Thus, I'm excited to announce that we're trying an experiment in providing scholarships for worthy entrepreneurs. For starters, we've reserved a few seats in the June 18th workshop (next week), and O'Reilly has agreed to jointly sponsor these scholarships with me. We're also soliciting additional sponsors for future workshops; if you or your company are interested, please let me know. The next two workshops aren't scheduled until the fall (Oct 30 in SF, Dec 10 in NYC) - look for a separate announcement about those.
These scholarships will provide extremely discounted pricing for entrepreneurs who demonstrate that they would contribute positively to the discussion in the room. They are not for people who are casually interested - we're looking for more early adopters. If you think you meet that description, and want to come join us on June 18th, please send me an email with a brief less-than-one-page (please, no more) explanation of why you want to be there. We'll reply by email if you are selected to attend.
Once again, thanks to all of you for your passion and support. For more on the workshop series, you can read about them here.
I had a blast speaking at Startonomics Tokyo, which was organized to foster ties between the startup cultures in Japan and Silicon Valley. It was an eye-opening day, and a great crowd to present to. As usual, I'll post the slides and then check in with the live commentary and feedback, and offer some additional comments. Without further ado, the slides:
yongfook: @ericries is a rock star. Very concise presentation and a great speaker. I am now decompressing with a guinness. Mmm. #goap
Thanks!
ericnakagawa: Show of hands how many in startup here? 40%, How many think they could iterate faster? Same #. #leanstartup#goap
It was great to be in an audience of entrepreneurs who recognized the value of iteration and speed. Even though they may not know how to improve, they were eager to learn. It meant the questions and discussion were very practical.
benjaminjoffe: early adopters of buggy product are visionary customers, sometimes smarter than founders! #goap#ericries
InvisibleGaijin: #goap#leanstartup Eric Ries talks about importance of "visionary customers" in startup success. Brilliant insight.
Many founders don't like to hear that visionary customers are as smart, maybe even more so, than they are. Startups need to spend time with these customers. In fact, early stage companies shouldn't be able to get time from anyone else - who else would be crazy enough to try an truly innovative new product? Incidentally, I can't take credit for this idea - it appears in The Four Steps to the Epiphany, Crossing the Chasm, and many others.
christinelu: if you're building a disruptive innovation ...the only people who you want to talk to are early adopters. not investors says @ericries#goap
heysanford: Nay, recipe for chasm crossing fail. RT @christinelu: building a disruptive innovation? ... only talk to early adopters. @ericries#goap
Continuing on the theme of early adopters, I thought this exchange was really interesting. First of all, let me emphasize how much more important it is to talk to customers than to talk to investors, journalists, and the people who hang around at industry trade shows. I've previously recounted the story of the IMVU "IM add-on" feature, a feature that sounds so good on paper I wound up building it twice. Yet it's one of those features that's only ever requested by investors and engineers - never by customers.
Books like Crossing the Chasm are excellent, but they can be misleading. Getting to the chasm is actually quite difficult; most truly early-stage startups never even get that far. The most important thing is to realize that all strategies and tactics are context-sensitive. It's never "always correct" to do a certain thing, and therefore there really aren't any universal "best practices." Instead, we need to focus on tuning our practices to our real situation. Thus, even something as general as "listening to customers" can actually be lethally bad advice.
davetroy: "Think about how *hard* it would be to get a big company to steal your idea. That paranoia is totally ridiculous." - @ericries at #goap
People who work in big companies often laugh out loud when they hear startup founders acting paranoid about having their great ideas stolen. That's not to say that there are no situations where patent or trade secret protection is important. Rather, it shouldn't be considered obvious. Most startup ideas are actually completely worthless without learning and iteration to back them up.
davetroy: "Fanatical empathy for your customer's pain point is the key to designing great products." - @ericries at #goap Tokyo
I get a particular type of question quite often - I call it the "Steve Jobs defense." The idea is that great product visionaries don't need to listen to customers or test their ideas against reality. They just call forth amazing products from the ether. That's how the iPhone was made, right? I really don't buy this account of product visionaries. For one, it doesn't match my experience having worked with some true visionaries at all. It also doesn't seem to line up with the documentary record. Read Founders at Work or take a look at this video of Jobs himself, and see if you see anything at odds with that story.
My belief is that what makes product visionaries awesome is their ability to have radical empathy for their customers, and then to rigorously hold teams accountable for building solutions that match that standard.
Most surprising of all, to me at least, were the questions I got about how to reconcile the lean startup with "the Japanese way of doing business." Since I learned much of what I know about lean from studying Toyota, you can imagine how great a shock this was. After some discussion, it seemed like what I was hearing was that Japanese companies like Toyota have been so successful that many people have forgotten the entrepreneurial roots of those same companies. For anyone interested in this topic, I highly recommend readingToyota Production System: Beyond Large-Scale Production.
I want to thank everybody who helped oragnize the Startonomics Japan event and the whole Geeks on a Plane trip, especially Dave McClure and Founders Fund, who arranged for me to speak in Tokyo. I had a great time, and learned a great deal.
Most of us are swimming in a sea of data about our products, companies, and teams. Too much of this data is non-actionable. That’s because many of our reports feed us vanity metrics: numbers that make us look good but don’t really help make decisions.
Yet even among those who have access to good actionable metrics, I’ve noticed a phenomenon that prevents taking maximum advantage of data. It’s a condition I call datablindness, and it's a painful affliction.
Imagine you are crossing the street. You constantly assess the situation, looking for hazards and timing your movements carefully to get across safely. Now imagine the herculean task that faces those who are blind. That they can function so well in our inhospitable modern life is impressive. But imagine if a blind person had to navigate the street as follows: whenever they wanted to know about their surroundings, they had to ask for a report. Sometime later, a guide would rattle off useful information, like the density of cars in the immediate vicinity, how that density compares to historical averages, the average mass and velocity of recent cars. Is that a good substitute for vision? I think we can all agree that it wouldn’t get most people across the street.
That’s what most startup decisions are like. Because of the extreme unknowns inherent in startup situations, we are all blind – to the realities of what customers what, market dynamics, and competitive threats. In order to use data effectively, we have to find ways to overcome this blindness. Periodic or on-demand reports are one possibility, but we can do much better. We can achieve a level of insight about our surroundings that is much more like vision. We can learn to see.
I got a powerful taste of datablindness recently, as I’ve started to work with various large companies as partners in setting up events, speeches, and other products to sell around the Lean Startup concept. Yet, whenever I find myself transitioning responsibility for one of these events to these third-parties, I have this sudden sensation of loss. I suddenly lose my ability to judge if our marketing programs are being effective. I start to get very fuzzy on questions like “are we making progress towards our goals?” In other words, I’m experiencing datablindness.
What’s happening? Mostly, I’m no longer being hit over the head with data.
For example, a recent event I held started with a customer validation exercise (actually, this example is fictionalized for clarity). I had it all set up to a jury-rigged SurveyMonkey-PayPalminimum viable product. It was pretty ugly, the marketing and design sucked, and I was embarrassed by it. Yet it had one huge advantage. Whenever someone decided to buy a ticket, I got an email immediately letting me know. So throughout the process of taking deposits and then selling seats, I was getting constant impossible-to-ignore feedback about how I was doing. For example, I quickly learned that when I twittered about the event, more often than not I would make a sale. Yet, when I tried other forms of promotion, I’d have to accept their failures when the emails failed to come. True, this wasn’t nearly as good as a true split-testing environment, but it was powerful nonetheless.
Now that I put on events with official hosts and sponsors, my experience is different. Of course, I can still get access to the data about who’s signing up and when – and a lot more analytics, to boot – but I have to ask. Asking imposes overhead. When I get a response, when someone tells me “hey, we had 3 more signups” I’m never quite sure if those are the same three signups I heard about yesterday, and this person just has somewhat stale information, or if we had three new ones. And of course, if I twitter about the workshop on a Friday afternoon, I won’t know if that had any impact until Monday – unless I want to be a pain and bother someone on their weekend. There are lots of good reasons why I can’t have instantaneous access to this data, and each partner has their own. I wonder if their internal marketing folks are as datablind as I feel. It’s not a pleasant sensation.
Let me give another example (as usual, a lightly fictionalized composite) drawn from my consulting practice. This startup has been busy transforming their culture and process to incorporate split-testing. I remember a period where they were suffering from acute datablindness. The creators of split-tests were disconnected from the results. So the product development team was busy creating lots of split-tests for lots of hypotheses. Each day, the analytics team would share a report with them that had the details of how each test was doing. But for a variety of reasons, nobody was reading these reports. The number of active experiments was constantly growing, individual tests were never getting completed. This had bad effects on the user experience, but much worse was the fact that the company was expending energy measuring but not really learning.
The solution turned out to be surprisingly simple. It required two things. First, we had to revise the way the reports were presented. Instead of a giant table that packed in a lot of information about the ever-growing list of experiments, we gave each experiment it’s own report, complete with basic visualizations of which variation was currently more successful. (This is one of the three A’s of metrics: Accessible). Second, we changed the process for creating a split-test to integrate it in with the team’s story prioritization process. The Product Owner would not mark an experiment-related story as “done” until the team had collected enough data to make a decision about the outcome of the experiment relative to their expectations. Since only a certain number of stories can be in-progress at any one time, these experiment stories threaten to clog up the pipeline and prevent new work from starting. That’s causing the Product Owner and team to spend more time with each other reviewing the results of experiments, which is allowing them to learn and iterate much faster. Within a few weeks, they have already discovered that huge parts of their product, which cause a lot of extra work for the product development team due to their complexity, are not affecting customer behavior at all. They’ve learned to see this waste.
Curing datablindness isn’t easy, because unlike real blindness, datablindness is a disability that many people find refreshingly comfortable. When we only have selective access to data, it’s much easier to be reassured that we’re making progress, or even to fall back on judging progress by how busy our team is. For a lean startup, this lack of discipline is anathema. So how do we reduce datablindness?
Have data cause interrupts. We have to invent process mechanisms that force decision makers to regularly confront the results of their decisions. This has to happen with regularity, and without too much time elapsing, or else we might forget what decisions we made. When the incidence rate is small, emails or text messages are a great mechanism. That’s why we have operations alerts trigger a page, but it can also work for other customer events. I’ve often wanted to wire up a bell to sales data, so that when we make a sale, we literally hear the cash register ring.
When the volume is too high for these kinds of tricks, we can still create effective interrupts. Imagine if the creator of a new split-test received a daily email with the results of that test, including the computer’s judgment of which branch was winning. Or imagine an automatic system that caused the creator of a new feature to get daily updates on its usage for the first three weeks of it being live. Certainly our marketing team should be getting real-time alerts about the impact of a new promotion or ad blitz.
Require data to justify decisions. Whenever you see someone making a decision, ask them what data they looked at. Remember that data can come in qualitative as well as quantitative forms. Just the act of asking can have powerful effects. It serves as a regular reminder that it’s possible to make data-based decisions, even if it’s not easy. When you hear someone say that they think it would have been impossible to use data to influence their decision, that might be a signal to investigate via root cause analysis.
My experience is that companies that ask questions about how decisions get made are much more meritocratic than those that don’t. Any human organization is vulnerable to politics and cults of personality. Curing datablindness is not a complete antidote, but it can provide an alternative route for well-intentioned people to advocate for what they think is right.
Use pilot programs. Another variation on this theme is to consistently pilot new initiatives before rolling them out to full-scale release. This is true for split-testing features, but it’s also true for marketing programs or even operations changes. In general, avoid make big all-at-once changes. Insist on showing that the idea works in micro-scale, and then proceed to roll it out on a larger scale. There are a lot of advantages to piloting, but the one that bears on datablindness is this: it’s extremely difficult to argue that your pilot program is a success without referring back to the expectations that got it funded in the first place. At a minimum, the pilot team will have to consult a bunch of data right before their final “success” presentation. As people get more and more used to piloting, they will start to ask themselves “why wait until the last minute?” (See Management Challenges for the 21st Century by Peter Drucker for more on this thesis.)
Luckily, datablindness is not an incurable condition. Have stories of how you’ve seen it cured? Share them in the comments, so we can all learn how to eradicate it.
Some people, when they start to realize the power of using data to inform their decisions, become obsessed with optimization. I think this idea is particularly appealing to those of us from an engineering background. By reducing the decisions we have to make to a series of quantitative questions, we can avoid a lot of real-life messiness. Unfortunately, most decisions that confront startups lack a definitive right answer. Sometimes an early negative result from an experiment is a harbinger of doom for that product, and means it should be abandoned. Other times, it’s just an indicator that further iteration is needed. The only way to get good at these decisions is to practice making them, pay attention to what happens, compare it to what you thought would happen, and learn, learn, learn.
This has given rise to another school of thought, one that sees quantitative analysis, models, and anything involving spreadsheets as inherently anti-innovative and, therefore, anti-startup. But this is wrong, too. Spreadsheets, and predictive modeling in particular, have an important role to play in startups. It’s just very different than what it looks like in other contexts.
Let’s first take a look at what happens when spreadsheets go horribly wrong. For a change of pace, I’ll take an example from a startup inside a large enterprise. Imagine a general manager that has read The Innovator’s Dilemma and related books, and is therefore trying hard to help her organization make a transition to a new product category via disruptive innovation. She knows the internal politics are tricky, but she’s navigated them well. She has a separate team, with its own culture and office, and a mandate straight from top management to innovate without regard to the company’s historic products, channels, or supply chain. So far, so good.
Still, this manager is going to spend the company’s money, and needs to be held accountable. So somebody from the CFO’s organization prepares an ROI-justification spreadsheet for this new team. Because this is a new skunkworks-type project, everyone involved is savvy enough to understand that the initial ROI is likely to be low, much lower than projects that are powered by sustaining innovation.And so the spreadsheet is built with conservative assumptions, including a final revenue target.
Everything that’s happened so far seems reasonable. And yet we’re now headed for trouble. No matter how low we make the revenue projections for this new product, it’s extremely unlikely that they are achievable. That’s because the model is based on assumptions about customers that are totally unproven. If we already knew who the customer was, how they would behave, how much they would pay, and how to reach them, this wouldn’t be a disruptive innovation. When the project winds up getting cancelled for failing to meet its ROI justification, it’s natural for the entrepreneur to feel like it was the CFO – and their innovation-sucking spreadsheet – that is the real cause.
And yet, it’s not really fair to ask that the company’s money be spent without anyone bothering to build a financial model that can be used to judge success. Certainly venture-backed startups don’t have this luxury – every business plan has a model in it. Just because entrepreneurs tend to forget about these models doesn’t mean their investors do. Companies that reliably fail to make their forecasted numbers are exceptionally prone to “management retooling.”
I think the problem with this approach is not the presence of the spreadsheet, but how it’s used. In a startup context, numbers like gross revenue are actually vanity metrics, not actionable metrics. It’s entirely possible for the startup to be a massive success without having large aggregate numbers, because the startup has succeeded in finding a passionate, but small, early adopter base that has tremendous per-customer behavior. Similarly, it’s easy to generate large aggregate numbers by simply falling back to non-disruptive or non-sustainable tactics (see Validated learning about customers for one example). And in a corporate context, a result in which the startup proves that a particular innovation is non-viable is actually very valuable learning.
The challenge is to find a way to use spreadsheets that can reward all of these positive outcomes, while still holding the team accountable if they fail to deliver. In other words, we want to use the spreadsheet to quantify our progress using the most important unit: validated learning about customers.
The solution is to change our focus from outputs to inputs. One way to conceive of our goal in an early-stage venture is to incrementally “fill in the blanks” for the business model that we think will one day power our startup. For example, say that your business model calls for a 4% conversion rate – as ours did initially at IMVU.
After a few months of early beta at IMVU, we discovered that our actual conversion rate was about 0.4%. That’s not too surprising, because our product was pretty bad in those days. But after a few more iterations, it became clear that improvements in the product were going to drive the conversion rate up – but probably not by a factor of 10. As the product got better, we could see the rate getting closer and closer to the mythical “one percent rule.” Even that early, it became clear that 4% was not an achievable goal. Luckily, we also discovered that certain other metrics, like LTV and CPA were much better than we initially projected. Running the revised business model with these new numbers was great news – we still had a shot at a viable business.
That’s hardly the end of the story, since there is still a long way to go between validating a business model in micro-scale and actually building a mainstream business. But proving your assumptions with early adopters is an essential first step. It provides a baseline against which you can start to assess your long-term assumptions. If it costs $0.10 to acquire an early adopter, how much should it cost to acquire a mainstream customer? $0.50? $1.00? Maybe. But $10.00? Unlikely.
Think back to the conflict between our Innovator’s Dilemmageneral manager and her nemesis, the CFO. The resolution I am suggesting is that they jointly conceive of their project as filling-in the missing parts of the spreadsheet, replacing assumptions and guesses with facts and informed hypotheses. As the model becomes clear, then – and only then – does it make sense to start trying to set milestones in terms of overall revenue. And as long as the startup is in learning and discovery mode – which means at least until the manager is ready to study Crossing the Chasm– these milestones will always have to be hybrids, with some validation components and some gross revenue components.
This model of joint accountability is at the heart of the lean startup, and is just as applicable to venture-backed, bootstrapped, and enterprise startups. As with most startup practices, it requires us to do a constant balancing act between execution and learning – both of which require tremendous discipline. The payoff is worth the effort.
Next week I head to Austin, TX for my first visit ever. I'm going to be speaking on June 3rd at an event sponsored by the Technology Entrepreneurs Exchange (TeXchange), "the premier networking organization in Texas for business executives and entrepreneurs to meet, exchange ideas and share experiences." (Also see below for details of another event the day before)
Normally, these events are for members only, but they are making an exception for the lean startup, and the dinner will be open to the public. You can register here. There is also a special discounted rate available for entrepreneurs and bootstrappers, about which you can learn more here. I really like their event format, which includes dinner, moderated table discussions - and then a Q&A session. I expect that will lead to much deeper (and tougher) questions. Bring it on!
Here's their description of the event:
The current macroeconomic climate presents unparalleled opportunities for those that can thrive with constrained resources. The Lean Startup is a practical approach for creating and managing a new breed of company that excels in low-cost experimentation, rapid iteration, and true customer insight. It uses principles of agile software development, open source and web 2.0, and lean manufacturing to guide the creation of technology businesses that create disruptive innovation.
This presentation will empower entrepreneurs and managers to:
-Identify a profitable business model faster and cheaper than your competitors.
-Continuously discover what customers want to buy before building or making follow-on investments in new features.
-Ship new software at a dizzying pace: multiple times a day while improving quality and lowering costs.
-Build a company-wide culture of decision-making based on real facts, not opinions.
In this presentation, serial entrepreneur Eric Ries will share practical solutions based in his work building IMVU to more than 25 million members worldwide and his experiences consulting to more than a dozen technology startups.
On the day before the TeXchange event (June 2nd), I'll be at a much smaller invite-only gathering sponsored by Austin Ventures. This will be an in-depth discussion with a handful of entrepreneurs and founders that have been pre-selected. This event is being organized by Manuel Rosso, an EIR at Austin Ventures, and my former collaborator back when he was VP of Marketing at IMVU. I asked him to reserve a seat or two for blog readers; if you're interested in coming to the event, you need to email him directly and explain why you want to be there.
Once again, thanks to everyone who can come out to join the discussion in Austin. As usual, if you're a reader, please come say hello - and bring your questions.
I had wonderful time presenting at SIPA last night, and was completely exhausted by the incredible post-speech response. To all those who couldn't get your questions answered in person, please feel free to post them as comments and I will do my best to answer. As usual, here are the slides from the event followed by some post-game commentary.
I'm starting to let all this positive feedback go to my head. Here's a taste:
pkgulati: @ericries Attended your #leanstartup event at SIPA today. Great event and a lot in common with what we do at Dubai. We need to stay in touch
GregOsuri: Amazing talk by @ericries at SIPA, changed my thought process significantly, a must education for aspiring start-ups #leanstartup
coupld: @ericries hey Eric this is Kunal. great talk at SIPA today Re: #leanstartup We'll be hitting you up with questions - would love some advice.
ms5: Talking to friends re @ericries talk #leanstartup - IMO most of his points can ONLY be understood by ppl who did a startup & failed before
This last point became kind of a theme for the evening: the importance of failing and taking risks in order to learn. I certainly think that having a failed startup can be an important motivator to do the soul-searching required to really learn, but I haven't given up on being able to affect the odds of success for future entrepreneurs on their first time out. If we can change just a few of the "best practices" that are considered common sense throughout the industry, I think we can do much better - even the first time. At a minimum, we ought to be able to help future entrepreneurs learn more per failure (on average) than we do today.
Naturally, not everyone agreed with everything
atseitlin: Listened to @ericries talk. Loved it and great speaker, but disagree with portrayal of agile only dealing with known problems #leanstartup
I'm really interested in perspectives on this point. Some of you will remember my intense anxiety presenting this idea on a webcast with Kent Beck himself tuned in, but he seemed to understand what I was getting at, which was a relief. Still, that doesn't prove that this is right. So if you have thoughts, please post them in the comments.
Of course, people do use agile in situations of high uncertainty (aka the "unknown problem") - but my claim is just that agile methodologies don't explicitly address the question of how to decide which problem to solve. For example, the agile practice of an in-house customer or product owner that can make authoritative prioritization decisions seems like it doesn't translate very well to startups. Of course, by collapsing the feedback time for the person in that role, agile is certainly helpful (and much more helpful than waterfall) - it's not just not designed for this context. Thoughts?
ms5: @ericries in tonight's talk on #leanstartup "To get to Minimum Viable Prod (MVP), cut features until it is really, really painful" #prodmgmt
Lost of questions last night on the minimum viable product, including one that elicited this response. It occurred to me that this is simultaneously a really hard problem and a really easy problem. Hard, because finding a clear rationale for any specific MVP is challenging. It's mostly a matter of judgment. But once you take the question out of the abstract, it gets much easier. In almost every case, people who ask me about the MVP already have a product in development - and it is plenty good enough to start getting feedback.
marymin: The later you fail, the bigger the audience that sees you fail - and the more you have at risk. #leanstartup
This is another fun one that I don't get to talk about often enough. Our natural impulse is to wait and prevent problems. The more time we take, the fewer problems we should have, because we use that extra time to think things through. That's true as far as it goes, but it's actually faulty reasoning in a lot of startup situations.
If your startup is growing (or aspires to grow), then the costs of a mistake are always going up. If your site goes down when you have 100 customers, that's painful. But with 100 million customers, it could be catastrophic. Since the cost of failure is monotonically increasing, it actually makes sense to fail sooner, not later. In other words, make your mistakes as soon as possible and learn from them - before you get too big to be able to take those kinds of risks. This is the thinking that allowed us to overcome our fear of continuous deployment at IMVU.
Thanks so much to everyone who made the trip to SIPA and participated in the conversation, as well as to SIPA and HP for hosting me. I certainly learned a lot from the experience. Your support means the world to me. Thanks!
This coming Thursday, May 21, is the last time I'm currently scheduled to give the full Lean Startup presentation in the Bay Area. The event is being sponsored by SIPA but will be open to the public. Last I heard from the venue, there are still some seats available; the ticket cost is only $25 if you register online.
Here's their write-up of the event:
We have heard that recessions are the best time to start your own startup. For entrepreneurs who have been on the path, it may be straight forward to get started. What about the rest of us? There are so many engineers with bright ideas, but don't know how to start.
The current macroeconomic climate presents unparalleled opportunities for those that can thrive with constrained resources. Many startups are now following the Lean Startup process. The Lean process was created by Toyota in the 50s. The Lean Startup embodies similar principles as applied to the startup process. The Lean Startup is a practical approach for creating and managing a new breed of company that excels in low-cost experimentation, rapid iteration, and true customer insight.
Eric Ries, a co-founder of IMVU, is a strong proponent of this process and very successfully used it at IMVU. He will share the key principles of making sure you get your startup idea off the ground and stay on course.
If you are an engineer with bright ideas, consider Lean Startup to build confidence while building your startup.
1. Identify a profitable business model faster and cheaper than your competitors.
2. Continuously discover what customers want to buy before building or making follow-on investments in new features.
3. Ship new software at a dizzying pace: multiple times a day while improving quality and lowering costs.
4. Build a company-wide culture of decision-making based on real facts, not opinions.
The event itself will be held on the HP campus in Cupertino, from 6-8:30pm. As always, if you're a reader and happen to be there, please do come say hello. If you have any questions, please post them as comments to this entry. I'll do my best to see that they are addressed.
My rate of posting has been much lower lately, and this is mostly due to preparations for the upcoming Lean Startup Workshop on May 29. I have a lot of good news to report on this front.
First of all, I'm excited to announce that the workshop is now an O'Reilly Master Class, and we have added a second date on June 18. Most importantly, thanks to O'Reilly, we now have more capacity, including a few additional seats to the previously-sold-out May 29 date. You can register for both dates on the new official signup page.
What will be covered in the full-day program? Take a look:
This full-day Master Class focuses on how to build a startup from the ground up to focus on customers, markets, and speed of iteration. Using examples drawn from his own experiences in the startup hub of Silicon Valley, Eric Ries unravels the myths and misconceptions that guide most startups, and paints a picture of a new way forward for the industry. Unlike other incubator-led programs, this workshop is open to anyone who wants to learn, and it does not require companies take investment or give out equity.
Through case studies, exercises, and discussions, Eric Ries will guide entrepreneurs of all stripes through the key areas that determine success for startups: product, engineering, QA, marketing, and business strategy. This workshop presents a new methodology that will allow you to bring new products -- and companies -- to life.
At the end of the workshop, you will have new insight into how to evaluate the strengths and shortcomings of your company, as well as a clear plan of action to bring lean-startup thinking back home. Rather than abstract principles, you'll learn to directly problem-solve.
The response so far has been nothing short of overwhelming, and I want to especially thank those of you who participated in the survey and customer validation exercise that helped shape this event. I'm working on a future post where I'll share the details of how I used customer development to shape both the content and packaging of this event, so look for that soon.
For now, I'd like to ask a favor. Given that this is my first effort in a joint partnership, I'd like to ask you to help spread the word about the Master Class. Would you be willing to link to the Master Class info page from your blog? Twitter about it or post it to a social media site? Most importantly, if you know a high-quality entrepreneur who you think would add to the conversation, would you be willing to try and convince them to attend? I'd also welcome nominations over email, if you have someone you think is a good fit for the event. Please feel free to send along your comments or questions about the workshop itself.
Lastly, some people have asked about discounted rates for those that can't afford the tuition fee. Others have asked about sponsorship opportunities at the workshop. We're not going to have any form of advertising, but I am considering trying to offer a scholarship program to worthy entrepreneurs, just as we did for the Web 2.0 Expo. If you'd be interested in sponsoring a scholarship, or applying for one, would you get in touch or leave a comment on this post? If there's enough interest, I'll do my best to screen the applicants and recognize the donors.
Thank you all for your continued support, and hope to see you at an event soon.
Fear is an emotion that slows teams down. It makes us more cautious. It makes us over-invest in prevention. It makes us less willing to trust, to communicate openly, and - most painfully - to take risks. It is the dominant reason I see teams fall back on "best practices" which may not be effective, but are at least reassuring. Unfortunately, these actions generally work to increase the batch size of our work, which magnifies the consequences of failure and therefore leads to more fear. Reducing fear is a heuristic we can use to judge process improvements. Anything that reduces fear is likely to speed up the fundamental feedback loop.
The interesting thing about fear is that to reduce it requires two contradictory impulses. First, we can reduce fear by mitigating the consequences of failure. If we construct areas where experimentation is less costly, we can feel safer and therefore try new things. On the other hand, the second main way to reduce fear is to engage in the feared activity more often. By pushing the envelope, we can challenge our assumptions about consequences and get better at what we fear at the same time. Thus, it is sometimes a good idea to reduce fear by slowing down, and sometimes a good idea to reduce fear by speeding up.
To illustrate this point, I want to excerpt a large part of a recent blog post by Owen Rogers, who organized my recent trip to Vancouver. I spent some time with his company before the conference and discussed ways to get started with continuous deployment, including my experience introducing it at IMVU. He summarized that conversation well, so rather than re-tread that material, I'll quote it here:
One thing that I was surprised to learn was that IMVU started out with continuous deployment. They were deploying to production with every commit before they had an automated build server or extensive automated test coverage in place. Intuitively this seemed completely backwards to me - surely it would be better to start with CI, build up the test coverage until it reached an acceptable level and then work on deploying continuously. In retrospect and with a better understanding of their context, their approach makes perfect sense. Moreover, approaching the problem from the direction that I had intuitively is a recipe for never reaching a point where continuous deployment is feasible.
Initially, IMVU sought to quickly build a product that would prove out the soundness of their ideas and test the validity of their business model. Their initial users were super early adopters who were willing to trade quality for access to new features. Getting features and fixes into hands of users was the greatest priority - a test environment would just get in the way and slow down the validation coming from having code running in production. As the product matured, they were able to ratchet up the quality to prevent regression on features that had been truly embraced by their customers.
Second, leveraging a dynamic scripting language (like PHP) for building web applications made it easy to quickly set up a simple, non-disruptive deployment process. There’s no compilation or packaging steps which would generally be performed by an automated build server - just copy and change the symlink.
Third, they evolved ways to selectively expose functionality to sets of users. As Eric said, “at IMVU, ‘release’ is a marketing term”. New functionality could be living in production for days or weeks before being released to the majority of users. They could test, get feedback and refine a new feature with a subset of users until it was ready for wider consumption. Users were not just an extension of the testing team - they were an extension of the product design team.
Understanding these three factors makes it clear as to why continuous deployment was a starting point for IMVU. In contrast, at most organizations - especially those with mature products - high quality is the starting point. It is assumed that users will not tolerate any decrease in quality. Users should only see new functionality once it is ready, fully implemented and thoroughly tested, lest they get a bad impression of the product that could adversely affect the company’s brand. They would rather build the wrong product well than risk this kind of exposure. In this context, the automated test coverage would need to be so good as to render continuous deployment infeasible for most systems. Starting instead from a position where feedback cycle time is the priority and allowing quality to ratchet up as the product matures provides a more natural lead in to continuous deployment.
The rest of the post, which you can read here, discusses the application of these principles to other contexts. I recommend you take a look.
Returning to the topic at hand, I think this example illustrates the tension required to reduce fear. In order to do continuous deployment at IMVU, we had to handle fear two ways:
Reduce consequences - by emphasizing the small number of customers we had, we were able to convince ourselves that exposing them to a half-baked product was not very risky. Although it was painful, we focused our attention on the even bigger risks we were mitigating: the risk that nobody would use our product, the risk that customers wouldn't pay for virtual goods, and the risk that we'd spend years of our lives building something that didn't matter - again.
Fear early, fear often - by actually doing continuous deployment before we were really "ready" for it, we got used to the real benefits and consequences of acting at that pace. On the negative side, we got a visceral feel for the kinds of changes that could really harm customers, like commits that take the whole site down. But on the plus side, we got to see just how powerful it is to be able to ship changes to the product at any hour of the day, to get rapid feedback on new ideas, and to not have to wait for the next "release train" to put your ideas in action. On the whole, it made it easier for us to decide to invest in preventive maintenance (ie the Cluster Immune System) rather than just slow down and accept a larger batch size.
Making this fear-reduction strategy work required more than just the core team getting used to continuous deployment. We eventually discovered (via five whys) that we also had to get each new employee acculturated to a fearless way of thinking. For people we hired from larger companies especially, this was challenging. To get them over that hurdle, we once again turned to the "reduce consequences" and "face your fears" duality.
When a new engineer started at IMVU, I had a simple rule: they had to ship code to production on their first day. It wasn't an absolute rule; if it had to be the second day, that was OK. But if it slipped to the third day, I started to worry. Generally, we'd let them pick their own bug to fix, or, if necessary, assign them something small. As we got better at this, we realized the smaller the better. Either way, it had to be a real bug and it had to be fixed live, in production. For some, this was an absolutely terrifying experience. "What if I take the site down?!" was a common refrain. I tried to make sure we always gave the same answer: "if you manage to take the site down, that's our fault for making it too easy. Either way, we'll learn something interesting."
Because this was such a big cultural change for most new employees, we didn't leave them to sink or swim on their own. We always assigned them a "code mentor" from the ranks of the more established engineers. The idea was that these two people would operate as a unit, with the mentor's job performance during this period evaluated by the performance of the new person. As we continued to find bugs in production caused by new engineers who weren't properly trained, we'd do root cause analysis, and keep making proportional investments in improving the process. As a result, we had a pretty decent curriculum for each mentor to follow to ensure the new employee got up to speed on the most important topics quickly.
These two practices worked together well. For one, it required us to keep our developer sandbox setup procedure simple and automated. Anyone who had served as a code mentor would instinctively be bothered if someone else made a change to the sandbox environment that required special manual setup. Such changes inevitably waste a lot of time, since we generally build a lot more developer sandboxes than we realize. Most importantly, we immediately thrust our new employees into a mindset of reduced fear. We had them imagine the most risky thing they could possibly do - pushing code to production too soon - and then do it.
Here's the key point. I won't pretend that this worked smoothly every time. Some engineers, especially in the early days, did indeed take the site down on their first day. And that was not a lot of fun. But it still turned out OK. We didn't have that many customers, after all. And continuous deployment meant we could react fast and fix the problem quickly. Most importantly, new employees realized that they weren't going to be fired for making a mistake. We'd immediately involve them in the postmortem analysis, and in a lot of cases it was the newcomer themselves (with the help of their mentor) who would would build the prophylactic systems required to prevent the next new person from tripping over that same issue.
Fear slows teams of all sizes down. Even if you have a large team, could you create a sandboxed environment where anyone can make changes that affect a small number of customers? Even as we grew the team at IMVU, we always maintained a rule that anyone could run a split-test without excess approvals as long as the total number of customers affected was below a critical threshold. Could you create a separate release process for small or low-risk commits, so that work that happens in small batches is released faster? My prediction in such a situation is that, over time, an increasing proportion of your commits will become eligible for the fast-track procedure.
Whatever fear-reducing tactics you try, share your results in the comments. Or, if fear's got you paralyzed, share that too. We'll do our best to help.
First up is an interview with Mixergy, about lean startups and what to do if customers don't like your (initial) product. You can watch the whole hour-long discussion here. Here's a little taste from a story I've mentioned on this blog a few times, but haven't discussed in detail, about the decision at IMVU to abandon our IM add-on concept; you can also watch an excerpt on YouTube.
I mean, it requires a lot of explanation. instant messaging add-on - it’s not a category that exists in her mind. But, since she’s in the room with us we can talk her into doing it. So she downloads the product, we have her install it on the computer, and we’re like “okay, it’s time to check it out, you know, invite one of your friends to chat.”
She says, “no way.”
We say, “Why not?”
She says, “I don’t know if this thing is cool yet. You want me to risk inviting my friends to a thing that I don’t think is cool? What are they going to think of me? If it sucks, they’re going to think I suck, right?”
And we say “No, no, it’s going to be so fun. It’s a social product…”
And the look of dubiousness, I mean, you can just see, this is a dealbreaker. And of course the first time you have that experience you say, “All right, it’s just that person, let em out, you know, send them away. Get me a new one.”
So then the second customer comes in. Same thing. Third customer comes in, same thing. You start to see these patterns and you’re like, okay. No matter how stubborn you are there’s got to be something wrong here.
Second, the complete audio (with slides) from my webcast last week is up on YouTube now too:
I hope you'll indulge me as I share some of the testimonials we heard from the participants who opted to answer the post-event survey. I'm trying to get better about taking advantage of the many testimonials you all have written for me. Thank you all so much.
His thinking about the relationship between business and technology is refreshing. His understanding of development problems impressive. I can't think of anyone who would not benefit from the presentation. No wonder Kent B. was there!
-Blaine Wishart
I was pleasantly surprised at how concise, useful and poignant the content was...well worth the time!
-Brian Moelk
Great presentation, as always!
-Sachin Rekhi
Eric is one of the smartest guys in the business.
-Ryan Kuder
Probably the best thing was knowing that Eric has done this and seen it work. It's not just a hypothesis but he has real working knowledge
- Trevor Gerzen
I absolutely loved the closing. "Stop typing, take your hands off the keyboard. Think of one concrete thing you can do in the next 24 hours to move you closer to this." Long pause. "Thanks for listening."
-Kyle Maxwell
Inspiring presentation, makes the daunting process of putting together a startup seem just a bit less daunting.
-Lawrence Green
Thanks for reading, listening, and watching. Your feedback, positive or negative, is always welcome.
Two new videos are online from recent speeches. The first is my talk on engagement loops and the levers of engagement from the Kontagent/Facebook Developer Garage. Slides from this talk are available here. For more on the subject of engagement loops, you can read my original essay here.
Wow, what an incredible turnout for webcast this morning, right on the heels of a phenomenal crowd at startup2startup last night. It's been a great twelve hours for the lean startup!
We'll have a full audio recording posted soon, but I did want to share the slides with everyone. Much of the content is shared with the Web 2.0 Expo talk, but there are a few new slides and in the discussion/Q&A we were able to go into much more implementation detail. One big idea that I haven't had a chance to write about on the blog yet is answering the question "What is a startup?" Here's the working definition I've started using:
A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.
In a future post, I'll attempt to unpack this definition in detail. For now, I just want to call attention to the idea that it has nothing to do with size of company, sector of the economy, or industry.
KentBeck: @ericries thank you for the insights. "unknown problem" was an eye opener for me. i'm running junit max according to lean startup principles
OK, so I'm showing off. One of my personal heroes, Kent Beck, the creator of Extreme Programming and a truly wonderful writer was logged in and twittering, too. What a thrill.
Very excited to announce that I've teamed up with O'Reilly to produce the upcoming Lean Startup Workshop as part of their Master Class series. As a result, we should be able to accommodate more people and more venues, maybe even more cities, if there is interest.
Now for some real feedback:
@rotkapchen#leanstartup Love this: Need both problem team & solution team working simultan, exchanging hypotheses, findings & solutions.
I'm continuing to push this idea, that departments can incentivize sub-optimal behavior. What makes a department (or individual) "more efficient" doesn't necessarily advance the company's goals.
farazq: Awesome session @ericries. LIKED: Y startups fail, cont deployment vs waterfall vs agile, small batches & learn fr biz metrics #leanstartup
As concise a summary as I've ever seen.
hwijaya: #leanstartup It's not the release fast dat matter. It's getting the evident dat u're on the right track (wat u learn frm making the release)
katrynharris: @ericries: "go as fast as we can work reliably to make progress & no faster" - absolutely & thanks for a super webcast! #leanstartup
Really trying to emphasize the importance of speed - but speed with regard to actual progress. That's what gives startups their disruptive innovation edge. Going "too fast" is not actually helpful. Learning to tell the difference is the hard part, and creating processes that act as speed regulators is the payoff.
clynetic: #leanstartup - All are ready to do this: Whether starting new company, have startup but need to iterate faster, or established company.
Always glad to see people pick up on these themes. It's never too late, you can always get started, and since all problems are human problems, there's no hiding behind a technical excuse.
Of course, not everybody had a great time.
wogsland: Still not understanding the "lean" aspect. Techniques sound fairly expensive to do correctly. #leanstartup
This is an objection I hear regularly, so I'm grateful to have the chance to address it. Lean is not about cheap, it's about speed. All lean transformation techniques, including the ones I advocate, involve making some part of the organization "less efficient" in order to speed up the whole. So they require investments to pay off. However, the level of waste in most organizations is so high that the investments pay off immediately, and therefore create new resources that can be reinvested in further improvements.
For example, it takes a few days of effort to build a simple split-testing system along the lines I advocate. Some companies tell me they "cannot afford" to do it. But if that split-testing system allows you avoid building just one major feature that would have been a waste of time, it's paid for itself many times over. If you don't have the confidence or ability to make trade-offs like that, you can't get lean.
There's no way to avoid this Rumsfeld quote. Then again, "just because you're paranoid doesn't mean they're not out to get you." What can I say? He had a point.
Well, I don't know what to say to this. I welcome suggestions for ways to get the same content across with fewer buzzwords. I don't think I can be very helpful without a discussion of the theory behind the lean startup, but I also don't know how else to teach that content. Please feel free to post your thoughts.
And then there's some questions that came up during the webcast that we didn't have time to discuss. I covered a few of them on twitter already:
Q: "Do you reccomend removing features that you've launched but don't movethe needle on engagement or revenue?" A: yes, absolutely.
Q: Does the Lean Startup framework work efficiently within a company of 2-3 people (think small)?" A: yes, yes, yes
Q: Does the Lean Startup framework work efficiently within a company of 2-3 people (think small)?" A: yes, yes, yes
Q: "Seems like the biggest issue is changing people's mentality. How did you deal with that on a new recruit (specificaly seasoned ones)?"
A: have them deploy code to production on their first day as an employee. made a big impression.
Q "In CD you spend a lot of time on phone with users. How does this map to the web? Surveys? Trial and Error + Analytics? What else?"
A: honestly, all of the above. Phone/in-person is still critical, but have to remember that is for idea generation, not idea validation
Good Q on webcast: "when measuring the results of your test, how do you avoid the post hocergo propter hoc fallacy?" A: you must split-test
If you had another questions you wanted to see answered (or do after you see the slides or audio), please post them here! I'll do my best to answer.
Lastly, I was really excited to announce on the webcast that we've opened up two dates for the Lean Startup Workshop - now that it's in O'Reilly's Master Class series, I have a lot more capacity to do these events. If you're interested, you can find out more here.
LTSE Tools - software for company builders CapTable - Cap table management and insights for founders. Fast409A - A quality valuation. A quick online process. HiringPlan - Easy headcount planning with built-in market data. Runway - Visualize and manage your startup’s cash flow. IPO Ready - Quickly assess your company's IPO readiness. Learn what it takes to prepare for an IPO.
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tOgjk6ua4CA2o68RYYG8_Kk5b2pbYLupL4HgOc1UMhkQRZg5_DJbpm_g9u5MSxjoAMALUlOBt0jJ72tS_VDwz0qrpT8YEVXgqzuguLfZcbJ7D6LhOS0IT5xbYUIdM3TAPG-PTE5LY2NNhom4xjojM=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_txLej7ayd-1PtHvKDsOlreHph6-rnIvUIqkWnA1EPYiiasmB-1Ty6ciRaClUW4wj2400aY0a_Z8Ly91BHOPIWMUkSmZSZ5OxgM13aAkBUk-Q0zaiVRwWQAxqBP62LoMVkcYwAahcPlZCVGMI_ZGKML=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_s2FElOU4SHgERuvXhguQuj5SD4jF47blM2z5JNYP9Fmt43D9wwkZSL9NJougCUhNEvbNeGCOygPsv9aas14jeEFyARqbAq-Zh-t7BKMQwuljInjDbVKqP-M6QPAhno1QKYojsEYIjfUBZAdmjU0kEq=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_vPy5xrlXncFVmW0hlHATgwsvnkjTVgOJwxpOizokw5rH17cO3FyY9zTWjU05CTsLcFSyRZZzLo_kv68g9QfCoZI4fVy2KBd59R_5Ptg3XD9Gx1OZw_N799LB7dKkJipv-oQfL3d78SWUjD23-wQ4VM=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_sz6F2Lp7wnNuA218-gUYOXsYZzTUxz9CsgeznzifqDyzCOwudyIVQiE4wE5dsuTHbDomc-soZSV0Dw0dbNYqkj8bFatY7r_oIhE71sCLcVfIg8CGJynuMtzskw5AqYuQz_B1WLg8OWne8BgOT6b3uP=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_uSd9Zc--SXJ-MO4X20juAiq3rL-Knyls0zeryHKIGs1XyKKqP-p7xhu3kSUYmqlrRrjuK0rYU7z4naEy7Y7pHovu_sffB2TP84KyN4UkLRz8L6NQ8XWKqC5KUdeCOnJFQJSutCxlysjJWhG69TUVs2=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_vmL53fMpjrBj2h2X_Ejb5snMX-ynsiELaO0gVsPmsnZZVzq-WWhRodPPZBc5NQyfqTUkAs6JcfrP4kurJWIFIsFJjRHbvTD93CDUHVUF-c0RDXop3WZxsMRFQaNCh_W_JMVT41umQHUoPvUw60Ga0=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tspnYsX8dmG6EEtuvYj_pKVqlyiFt2qJiT4sUIVO9IMHe6_80pT12jC-J05y23MhukjFCoqgWPww4hIIurdTWQyizpYj5QDIjXx_qUIKz3Wd_GpfBu9IeaSgMqGQ2bRlJ0gNCkOAUR1nUDYKfNI3W7=s0-d)
RSS Feed
