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!)  
http://bit.ly/tpTtE  
 
 
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.