Built to learn

It's been an exhilarating ride since the Web 2.0 Expo last week. Thank you all so much for making the event an overwhelming success (way beyond my wildest expectations) and a special thanks to all of you who have reached out to share your feedback, comments, and questions since then.

I have been meaning to write this post for days, but the meetings have been non-stop and I haven't had much time. First of all, I promised to post the full slides of the talk, which are below. I want to thank those people who were recording, tweeting, and posting from the hall itself. Thanks to you I know about the energy in the room and even have pictures to prove it. Best of all, Nivi from Venture Hacks was recording, so these slides have synchronized audio, too.

I learned an incredible amount by giving this talk, especially from the many people who have commented, disagreed, and asked questions about it. Here are some of my top takeaways. Rather than use boring section headers, I thought I'd just quote from actual customers, in their own words.

MarkH: Key takeaways from Eric's great talk #w2e #leanstartup 1) "building a culture to learn" @ericries

Mark's point is the one that seems to have had the biggest impact from the talk as a whole: that startups should be built to learn. That's the essence of so many of the lean startup techniques I've evangelized: customer development, the Ideas/Code/Data feedback loop, and the adaptation of agile development to the startup experience. Many people asked some variation of the question: "sure, learning sounds good. But how do I actually organize my team so that we actually do it day-in day-out?" Answering that question is what I'm striving to do on this blog (and at future webcasts and workshops).

blader: @ericries my #1 takeaway from #leanstartup: "No marketing team. No engineering team. You need a problem team and a solution team."

Steve Blank has evangelized the "no departments" theme for many years. This is my take on that idea. The insight is that waterfall and agile are well-adapted for situations of "known problem, known solution" and "known problem, unknown solution" respectively. The lean startup focuses on situations where we have both an unknown problem and an unknown solution.

Creating a company-wide feedback loop that incorporates both customer development and agile development is a challenge. Traditional department labels just make it harder. So instead of having sales, marketing, and business development, we have a problem team implementing customer development. But where it makes sense, that team may also include engineers building new experiments or prototypes to try with customers. And instead of design, engineering, QA, and operations we have a solution team implementing a startup-centric version of agile development. But that team may also include product marketers or other in-house customers who can give insight into the impact that solution trade-offs might have on customers. Most of all these two teams are in constant contact, sharing insights, hypotheses and -- above all -- data.

rahmin: #leanstartup unit of progress: validated learning about customers, preferably with $$$ attached - @ericries

adachen: The biggest source of waste at a startup is building something that no one wants #leanstartup

Once we have our problem team and solution team, it's essential that they share a single definition of progress: validated learning about customers. It's not good enough to hit product milestones and conduct usability tests. We have to actually validate our key business theories and prove that we're on a path to creating somethng that matters.

dalelarson: "Metrics are people, too." @ericries's talk on Lean Startups absolutely fantastic. #leanstartup

ericnsantos: #w2e #leanstartup Metrics should be Actionable, Accessible and Auditable. Use them to split-test all the time.

(Gotta love using twitter quotes, since they occaisionally come with compliments attached).

Metrics are a key questions startups face. How do we decide what to measure and why? What do we do about it once we get started? I didn't start life as a metrics-lover, and it took me many years to learn to distinguish between "vanity metrics" that make us feel good and "actionable metrics" that help us make decisions. "Metrics are people too" is a reminder I constantly needed when I was a manager. It's not about moving numbers in a spreadsheet, it's about changing customer behavior -- for the better. When people ask about how to reconcile metrics with interaction design, usability testing, or in-person customer interviews, this is the issue they are really talking about. When we lose sight of the humanity of our customers, we're not likely to be able to delight them.

sachinrekhi: "Visionary customers are as smart if not smarter then the founders" #leanstartup

There's no skipping the chasm. Startups have no choice but to first talk to and sell to what Steve calls earlyvangelists. This is true whether you're selling million-dollar software to huge enterprises or selling fifty-cent virtual clothes to teenagers. Only the truly visionary customers will engage early-on. Luckily, they can help you find their mainstream counterparts, if you listen closely.

hansoo: #leanstartup "MBA fallacy: whiteboard, think about it, whiteboard some more, think about it, whiteboard, feel good about your idea"

Although I never went to business school, I have committed the "MBA's fallacy" many times. It's actually the fastest way to iterate on a business: just keep reworking it at the whiteboard. At IMVU, I remember spending an incredible amount of time iterating on the model that would power our third-party developer economy. My cofounders and I would hash out nuances and details almost every day, re-drawing diagram after diagram on the whiteboard. Now, the first few times we thought through those issues, we probably did some quality thinking. But pretty soon it degenerated into fact-free bloviating. If it doesn't involve new facts, it doesn't count as learning.

MeganMurray: "Behind every technical problem is a human problem. Fix the cause, not just the symptom." #leanstartup #w2e (via @blader) Amen

mcavalcanti: #w2e #leanstartup every technical problem is a usually a human problem.

jonbischke: "We're fine with having any problem occur one time. But no problem can occur twice." @ericries #leanstartup #w2e

If you are willing to follow a continuous-improvement methodology like five whys, you can re-derive almost all of the lean startup techniques, and probably discover many more besides. All it takes is that you focus seriously on the idea that you're not willing to waste time having the same problem occur twice. It sounds easy, but in practice it usually means a radical shift in perspective, one that can help see through the apparently technical problems that most of us who are engineers spend our time fixing. Those are only symptoms.

So without further ado, let me share the slides with audio.

The Lean Startup at Web 2.0 Expo

Upcoming Events
If you missed the session at Web 2.0 Expo, never fear. I'm doing my best to satisfy the many requests I've had to provide more in-depth material and more diverse locations.

April 21 - Agile Vancouver is sold-out (thank you all so much!). However, for those who weren't able to get in (or are real gluttons for punishment), I will be speaking the night before at a free event hosted by The Vancouver Ruby/Rails/Merb Meetup Group. It will be a more-technical version of the Expo talk. You can register here. I'm doing my best to live up to the three-!!! billing.

May 1 - free webcast. I'm doing a webcast with O'Reilly that is free and open to the public. We'll be discussing in greater detail the three techniques I highlighted at the Expo: continuous deployment, split-testing, and five whys. Here's the promo; more information is available on their site.

How to Build a Lean Startup, step-by-step
Get started with a detailed guide to three key lean startup techniques: continuous deployment, rapid split-testing, and root cause analysis (five why's). This webcast will cover the theory of how lean startups work, implementation details, and case studies. Participants will come away with a specific plan of action for how to apply these techniques to their product, company, or startup.
Register here.

May 29 - the Lean Startup Workshop. I am particularly excited about this, as it will be a really in-depth discussion. The workshop will go all day and will be for a carefully screened audience. If you'd like to register, you have to take the survey. At the end, you'll be given the opportunity to participate in a customer validation exercise where you can reserve a spot, or just sign up to be notified when applications will start.

I'll continue to post about additional events as I get them scheduled. Looks like I'll be at TiEcon 2009 in mid-may, and at an event to be announced in Austin in early June.

Thanks for reading, attending, commenting and questioning. I'm continually inspired by your entrepreneurial passion and insight. Thank you.