Go back

8 lessons from the Lean Startup Conference

December 17, 2013 by Shane Reiser


Eric Ries, author of The Lean Startup, speaks at the Lean Startup Conference

My biggest fear as CEO of Startup Genome is that we might waste some of our limited resources building stuff that no one wants.

To make sure we do that as infrequently as possible, we employ some lean methodologies. For example, we:

  • prove our hypotheses and validate our assumptions before we build
  • follow a build, measure, learn cycle
  • deploy continuously
  • don’t work on fixed deadlines
  • learn from our mistakes
  • strive for simplicity
  • do in-person customer interviews
  • use open source religiously

Last week I went to Eric ReisLean Startup conference. I thought I might take a break from writing about startup communities and share what I took away from the conference that I hadn’t already absorbed from the books:

  1. Pursue the skeptics. Talk to all of them. Hire them. Don’t assemble a panel of advisors that already love what you’re building.
  2. Most people know what their riskiest assumption is, they’re just too afraid to test it.” The lesson here is that you can’t afford not to test the riskiest assumption in every product and feature you build.
  3. When doing customer interviews, don’t ask “would you pay for this?” There’s a big difference between saying they’ll buy it and actually pulling out their credit card. Instead, ask them to give you money now. If they aren’t willing to prepay, maybe they will never pay at all.
  4. Forget the MVP for a second and consider the MVE: Minimal Viable Experience. When you’re starting a new project, use non-scalable processes that allows people to complete the primary journey. For example, someone with an idea for a service that recommends clothes to wear shouldn’t start by building a complex recommendation engine. Instead, they might use simple web forms to survey people and collect payments, then do the matching manually behind the scenes. By doing manual work on the back-end and observing people’s behavior, you’ll learn and be more likely to build what people want in long run. Read: Wizard of Oz testing. Watch: Mariya’s talk at the Lean Startup Conference

  1. Look for confirmation bias. Testing your hypotheses can be scary. You feel pretty confident that what you believe is right. It’s tempting to just go build. But no, you’re smarter than that, so you run tests to prove your hypotheses. Yay! The results of your tests prove your hypotheses! Time to build, right? Maybe not. Before you start building, take a step back and look for confirmation bias. This is when you interpret results in a way that supports what you were expecting and ignore information that challenges your preconceived notions. Testing your beliefs is an emotional exercise. Your heart wants to be right. Your heart believes you are right. Your heart tricks your mind into looking for the answer it wants, and you end up writing leading questions written in your customer surveys or taking ambiguous data and interpreting it to support your position when you should be running a new test to get better data.
  2. I’ve always done everything I could to simplify and focus, but I liked how one speaker described it as the core loop: the main set of actions your users have to take in order to make BOTH of you successful. This language is handy when prioritizing with your team. “Is this part of the core loop for this product/feature?Read: slide 47-52 of Mariya’s slides
  3. I like what Steve Blank makes Lean LaunchPad participants do. He forces them to run experiments and talk to 100 people in-person in 10 weeks. Nothing bad can come from that much talking to customers.
  4. This quote: “If you can do better, you should.”

Shane Reiser is the Co-founder of Startup Genome and a community builder in Omaha, NE, USA. He attended the Lean Startup Conference in San Francisco in December 2013.

Photo Credit: JD Lasica on Flickr

To the top