Friday, May 22, 2009

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.

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!


  1. Eric, do you have any discussions planned for the co-founding dynamics of a successful lean startup? The insights on customers and deployment methodologies have been fascinating, and I would like to hear your thoughts on co-founders & their relationships playing in to the other topics (for example, do you have the same 'no lone founders' rule that many of the incubators seem to adhere to?).

    Also, would you be interested in doing a case study on a fledgling startup? Obviously we don't want TLS to turn in to a reality TV show but I would appreciate the opportunity to watch your methodologies being applied in real-time.

  2. Hi Eric,

    I'm a big fan of you and Steve Blank!
    Your ideas are very inspiring and sound :)

    Could you please help me on an issue?
    What's the best open source platform to design 3d avatar environments for a webapp?
    ( I'm not trying to compete with IMVU, it's a different kind of idea that I'm trying out!)

    Alexandre Gomes

  3. I could not make it to the presentation. I would love to see the recording if it is there.

  4. Eric,

    I continue to follow your work along with Steve Blank's with great interest. We're doing our best with this startup (my 4th) to follow the 4 Steps in combination with your development approach.

    There seems to be a hole/gap with the approach though (unless I've missed it - that's completely possible - and wouldn't be the first time), with the integration of the Customer Development and Product Development processes.

    To be more exact, with enterprise products in particular, WHEN to build-out the bulk of the MVP is a particularly tricky question to answer in addition to the always thorny WHAT comprises the MVP.

    I'm really uncomfortable taking a half-baked MVP to a potential enterprise customer when I'd like them to consider using this application as a core part of their business. It just doesn't resonate with me. And, again in the enterprise context, I'm not sure you can get away with a bug-riddled application, even when you say it is only in development...

    I'd really like to make the leap to getting more (we did it with the concept/mock-ups) early feedback to reduce the chances of failure, but I'm having a hard time accepting this is the way to go with an enterprise product.

    Any material you can point me to or advice you can provide would be most appreciated.

    Keep up the great work.

  5. Thanks for that presentation. I am the founder of online-marketplace amprice, where we work for four years without substantial founding raising our marketshare from year to year.

    We started with an out-of-the box solution until our growth were showing us, that we really need our own solution to have scalable marketplaces. Under the laughter of several people we started coding and presented some months later our new, unique system, which is the most multifunctional marketplace worldwide. Today we are number three in Germany, starting now our internationalization.

    If you don't have financial power during your growth, you have to be patient, everything needs more time.

    We were learning a lot from our members. They are testing, they are claiming, if something is not as good, as they need it. And we listen and work on that issues.

    There is one important point: If you do not have the funding, you have to be much more creative and you need a complete different management. Search for people, who stumbled once in their life, they will contribute themselves to the company and work much harder, than many high-ranked professionals. Kick everyone, who is not rowing in your boat, you dont need politicians, you need workers, who do their job without discussing everything to an end. That is one of my learnings building up amprice.