Documente Academic
Documente Profesional
Documente Cultură
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.