The  Lean  Startup  


Core  idea:  most  startups  fail  
Overwhelming  majority  fail   Chart  of  web  2.0  companies  -­‐>  someone  took  it  and  put  an  X  over  all  failures,  and  Os   over  successes  (a  lot  of  red  ink…  grim  time  for  the  industry)     Collectively  as  an  industry,  we  pour  a  lot  of  energy  and  resources  into  sector  with   terrible  mortality  rate     It  doesn’t  have  to  be  that  way   We  can  do  better   This  talk  is  about  how     -­‐>  this  talk  is  about  alternate  reality  that  we  can  reach,  where  mortality  rate  is   different    

Key:  Why  do  they  fail???  
  Certainly  not  quality  of  ideas   -­‐>  Favorite  exemple:  Microsoft,  PayPal     Successful  companies  achieved  enough  iterations  to  reach  product/market  fit    Figured  out  how  to  match  crazy  vision  with  what  reality  would  accomodate     Evolution:  ‘chip  marble  away  from  the  statue’  -­‐>  our  job  as  entrepreneur  is  to  figure   out  which  is  the  crazy  delusion  part  from  the  elements  of  truth       What  is  a  startup?      abandon  the  idea  of  ‘two  guys  in  a  garage’:  folklore,  focuses  on  side  effects!     A  startup  is  a  human  institution  designed  to  deliver  a  new  product  or  service   under  conditions  of  extreme  uncertainty.     Core  characteristic:  extreme  uncertainty  about  what  the  future  holds   Core  need  of  a  startup:  develop  a  methodology  to  learn  about  the  future!     A  good  plan?   Start  a  company  with  a  compelling  long-­‐term  vision   Raise  plenty  of  capital   Hire  the  absolute  best  and  the  brightest  

Hire  an  experienced  management  team  with  tons  of  startup  experience   Focus  on  quality  (don’t  ship  till  it’s  ready)   Build  a  world-­‐class  technology  platform  (all  the  PhDs  in  the  room)     fantastic  contribution  to  society     do  the  whole  thing  in  stealth!  (cool  thing  at  the  time,  ton  of  famous  people   disappearing  form  the  map  to  work  on  unknown  thing,  filing  patents…)       What  happened:  achieving  failure   Different  from  failure:  includes  a  lot  of  achievement   -­‐>  5y  and  $40m  wasted     Reason:  Crippled  by  “shadow  beliefs”  that  destroy  the  effort  of  all  those  smart   people.  Shared  by  everyone,  just  never  talked  about  them.       Shadow  belief  #1:  We  know  what  customers  want   Entrepreneurs  create  a  ‘reality  distortion  field’   Problem:  it  is  needed!     Real  question:  if  you  are  in  a  startup  today,  how  do  you  know  if  you  have  a  vision  or   a  delusion?  What  ways  to  check  if  that  vision  makes  any  sense  at  all?       Shadow  belief  #2:  We  can  accurately  predict  the  future   “People  don’t  call  you  crazy  if  you  believe  it,  don’t  say  it  at  least”     Has  implications  on  business  plan:  company  had  200  people  at  launch!!  Because   honestly  felt  that  it  was  needed.       Shadow  belief  #3:  Advancing  the  plan  is  equivalent  to  progress     Founder’s  job  is  essentially  to  sell,  all  day  long.   Investors   Employees   Partners   Customers     Day  in  the  life  of  a  startup:    Make  sure  that  everybody  works  hard  =>  keep’m  busy  
 But how do you know if you actually made progress?  People fall back on ‘making the plan’

    Back  to  ‘a  good  plan?’  

  What  was  the  problem?     How  to  make  money?  No!  Super  detailed  business  plan.  Did  actually  work,  people   did  pay  for  it.  Didn’t  ship  before  credit  card  integration  etc.    Just  a  failure  compared   to  their  expectation.       New  plan:  IMVU     Bad  idea  #1:  Shipped  in  6  months    -­‐  a  horribly  buggy  beta  product   Concerns  overblown:  nobody  ever  tried  it     Bad  idea  #2:  Charged  people  for  it,  from  day  one   Even  more,  Metcalfe’s  law  was  working  against  them!  ‘We  didn’t  mind’     Bad  idea  #3:  Shipped  multiple  times  a  day     By  2008,  on  average  50  times  a  day   Continous  deployment.  Fears:  ‘what  if  it  breaks!?’  ‘what  if  an  engineer  removes  the   Checkout  button!?’     Bad  idea  #4:  No  PR,  no  launch   Published  everything  on  the  website,  even  business  model!!  But  had  to  become  part   of  top  1000  websites  before  journalists  were  interested!         Lean  startups  go  faster     3  key  ideas:   Commodity  technology  stack   Customer  development   Agile  software  development       Commodity  technology  stack     Product  development  leverage:  for  each  ounce  of  effort  you  invest  in  your  product,   you  take  advanteg  of  the  efforts  of  thsoudans  or  millons  of  other   Drives  costs  down,  but  more  important:  impact  on  speed!  Time  to  bring  a  new   product  to  market  is  falling  rapidly.     Q:  how  about  IP  concerns?   A:  not  the  real  value.  Today,  value  is  in  data  and  customer  relationship,  not   technology    companies  are  defended  by  their  business,  not  lawyers    

Q:  how  to  convince  a  customer  to  buy  if  there  uncertain  about  solidity  of  your   business?   Wrong  person  to  talk  to:  talk  to  early  adopters,  people  that  have  an  acute  enough   pain  to  engage  in  crazy  activity.  Early  users  are  more  visionary  about  product  than   you  are!     Q:  you  disclosed  your  business  plan.  Weren’t  you  afraid  that  big  guys  would  copy  you?   Do  you  know  how  hard  it  is  to  pitch  an  idea  to  top  manager  at  Yahoo?   Steve  Blank:  ‘the  only  company  that  can  put  you  out  of  business   Actually  had  a  buyout  offer  by  a  company  who  said  ‘well,  if  you  say  no  we’ll  copy  you   and  put  you  out  of  business’.  Poached  a  co-­‐founder  and  put  him  in  charge  of  team   designing  .  Luckily,  had  core  in-­‐competency.  Spent  two  years  building  a  product  to   the  specs  of  what  IMVU’s    was  2  years  ago  –  IMVU  had  already  make  mistakes.         Customer  development     “Read  the  book”  (literally!)       Agile  development     Traditional  Product  Development:  Waterfall     Unit  of  progress:  Advance  to  Next  Stage     Works!  Works  extremely  well  for  a  lot  of  situations   Important  to  understand  what  circumstances  where  it  works   Works  well  when  predictable  problem  and  solution   Can  build  a  model  of  the  future.     Dangerous  for  a  startup:  getting  this  reinforcement  from  advance       Agile  development     Unit  of  progress:  a  line  of  working  code:   Any  activity  that  does  not  contribute  to  building  lines  of  code  is  eliminated     Code  that  doesn’t  work  is  a  form  of  waste   No  code  to  anticipate  future  needs  that  we  might  not  have   No  documentation  that  people  never  run,  no  specs  that  become  stale,  no  tests  that   never  get  run    

(!!!)   Problem:  known   Solution:  unknown     In  Extreme  Programming  (Eric’s  favorite  agile  dev  methodology),  ‘domain  expert’  is   a  customer  that  sits  directly  next  to  the  software  engineer.       Product  development  at  lean  startup     Unit  of  progress:  validated  learning  about  customers           (!!!)   Problem:  unknown   Solution:  unknown     Cross-­‐functional  Solution  Team  in  direct  contact  with  a  Problem  team   -­‐>  break  departmental  barriers:   “Startup  dollhouse  fallacy”:  startup  =  small  big  company     Tangible  unit  of  progress:  learning     Best  measure  is  revenue,  but  just  a  measure  -­‐>  it’s  all  about  knowledge!   Revenue:  try  it   There  is  a  few  special  cases,  but  very  few   “You  wouldn’t  believe  the  number  of  entrepreneurs  who  come  to  me  and  tell  me   they  are  a  special  case”       THE  LEAN  STARTUP   The  Lean  Startup  Heuristic   ONE  Heuristic  to  decide  if  any  process  is  harmful  or       Minimize  TOTAL  time  through  the  loop     Three  ‘fallacies’:   Engineering  fallacy:   Data  warehouse  fallacy:       MBA  fallacy:  there  is  one  super  fast  way  to  iterate:  do  it  at  the  whiteboard  by   yourself.  Spend  the  day  moving  boxes  around,  then  start  again     Idea  is  to  minimize  the  TOTAL  time,  not  suboptimize  one  aspect.      

Q:  doesn’t  that  mean  you  need  a  product  to  learn?   Need  to  put  a  product  out  there,  not  necessarily  a  real  one.  However,  wary  of  this   idea    cf.  MBA  fallacy.       Minimum  viable  product   Can’t  talk  too  much,  go  see  the  blog.  I  can  say  with  confidence  that  many  of  you  have   a  way  too  big  idea  of  what  is  minimum.  Heuristic:  pare  features  down  until  you  feel   uncomfortable.  Then  you  are  within  50%  of  target.         Techno  for  agile:  continuous  deployment     Deploy  new  software  quickly   At  IMVU  time  from  check-­‐in  to  production:  20  minutes   During  this  time,  does  a  battery  of  test.  First  test  on  sandbox,  then  run  battery  of   tests,  and  then  do  incremental  deployment:  first  on  a  few  systems,  then  if  works  on   the  full  cluster.  If  fails,  receive  an  email,  then  all  your  coworkers  as  well,  then   commit  cycle  is  broken.     Tell  a  good  change  from  a  bad  change  (quickly)       Revert  a  bad  change  quickly     Work  in  small  batches   At  IMVU,  a  large  batch  =  3  days  worth  of  work     Cluster  Immune  System     Run  tests  locally  (SimpleTest,  Selenium     Continuous  Intergation  Server  (BuildBot)     Incremental  deploy   One  server  at  a  time,  while  monitoring     Alerting  and  predictive  maonitoring  (Nagios)     When  customers  see  a  failure:         Committed  to  the  idea  that  we  could  have  any  issue,  once   Then  have  to  learn  from  that  mistake  as  much  as  possible     Whatever  is  in  the  HEAD  of  the  SCM  is  production!!!!  

    Split  testing  all  the  time     Make  it  really  easy:  one  line  of  code     AAA’s  of  Metrics     Actionable   Has  to  give  people       Accessible   Has  to  be  easy  to  deploy     Auditable   Has  to  be  able  to  convince    used  to  kill  people’s  features     Measure  the  macro     Always  look  at  cohort-­‐based  metrics  over  time     Split-­‐test  the  small,  measure  the  large   -­‐>  idea  is  to  do  split-­‐tests  for  small  features,  but  to  measure  the  impact  on  the  large   stuff!  Not  the  small  stuff.  E.g.  final  revenue,  not  click-­‐through  of  that  one  button.       Q:  how  about  first  impression?  Don’t  you  risk  turning  users  away?   Well,  you  better  fail  at  the  beginning   Any  mistake,  you  want  to  make  it  now!  Not  later.  Every  day  increases  the  risk  of   feature  failure.     Q:  ‘fail  early,  fail  often’  doesn’t  work  today!     Paradox:  if  you’re  succeeding  on  a  regular  basis,  you’re  not  taking  risks,  so  you’re   not  creating  innovation.  The  goal  is  to  learn  as  much  as  you  can  from  each  failure,  so   you  will.  If  you  say  ‘my  goal  is  to  be  right  every  time’,  you  won’t  take  enough   chances.       Five  whys  root  cause  analysis     A  technique  for  continuous  improvement  of  company  process.     Ask  ‘why’  five  times  when  something  unexpected  happens.     Make  ‘proportional’  investments  in  prevention  at  all  five  levels  of  the  hierarchy.    

Behind  every  supposed  technical  problem  is  usually  a  human  problem.  Fix  the   cause,  not  just  the  symptom.       There’s  much  more…   …  read  the  blog!       Q:  differences  between  teams?   No!  Exact  same  team!     Failure  is  important.  People  who  have  gone  to  success  to  success  are  not  open.   People  who  have  tried  the  traditional  way  and  failed  are  the  most  open.        

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.