The Lean Startup at SIPA follow-up

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.

2009 05 21 The Lean Startup At SIPA

View more OpenOffice presentations from Eric Ries.

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!