2. “Lean”
Eric Ries
Steve Blank
Lean Manufacturing Lean Startup™
Customer Development
Key tenet: Reduce Waste
Agile Software Development
3. Basic “Lean” concepts
• “Lean Startup”: the principles of developing the minimum viable
product (MVP) in a startup setting, testing with customers, and
resisting scaling until the idea has been validated
• “Customer Development”: working with customers to find the right
product and service as well as the right business model
• “Minimum Viable Product (MVP)”: the smallest possible thing a
product development organization can build for use in customer
development (doesn’t have to work)
• “Product/Market Fit”: when 40%+ of your users will be deeply
disappointed if they can no longer use your product
• “Pivot”: change direction based on new data while staying grounded
in what one’s learned to date.
4. Entrepreneurial Product Development with
“Lean” in mind
• Do A LOT of customer development (starting from the
beginning)
• Get buy in on the initial effort and document the
minimum requirements to get engineering going
• Evolve a minimum process to efficiently develop the
product
• Build the minimum viable product (MVP) and test it
with customers right away (non-functioning mockups are
often adequate)
• Be open minded. Hypothesize, test, iterate, pivot if
necessary, repeat.
• Don’t prematurely scale the startup until
product/market fit has been achieved
5. Before you begin: check the
assumptions
• Do you have funding to get you to FCS (First Customer
Ship)?
• Do you know your own core competence: what you can
do better than anyone else in the world?
• Have you quantified your value proposition and proved
that you have found a problem that’s worth solving, in a
market that’s worth owning?
• VERY IMPORTANT: has your technical team proved the
viability of the technology in a successful research and
advanced development project?
Conflating research and advanced development with product development
=
Project delays and early failure
6. New product development in a startup setting
Hypothesize market
problem to be
solved
Hypothesize a
solution concept
Pick target market
segment
SWAG segment
size – worth
owning?
Quantified value proposition, found a problem worth solving
Choose your target Product discovery
research to build
personas
Build a mockup
and/or prototype to
illustrate solution
Product research
with buyers/users
Understand your
own core
competence
Technology
research and
feasibility study
Validated feasibility of core technology
Found a solution that probably solves customer problems
Define MVP –
scope, functionality,
design, UI
Build MVP in
smallest possible
chunks
Continuously test
with customers
Final QA and FCS
Charge $$ for your product and service
The best way to succeed is to involve customers in every stage of the process
7. Choose your target
Entire market
Target segment
Early market
Potential
target
customers
Image source: Google image search
8. Develop hypothetical buyer/user personas
Primary Persona:
Budding student
entrepreneur
MIT Grad student who wants to
start a company but doesn’t
know how
Secondary Persona:
Aspiring
entrepreneur
Working engineer who
wants to quit his job to
start a company
Secondary Persona:
Business cofounder
MBA Student looking for
technical cofounder
Tertiary:
B-School professor who
wants to showcase their
research
Tertiary:
Industry Sponsors
looking to build
their brand
Image source: Google image search
10. Research technique: Subject recruitment
• VERY IMPORTANT: Recruit carefully. Do a study with the wrong
subjects and the results will be worthless.
• The recruitment questionnaire can include information like this:
– Demographic information
– Technology profile – e.g. what cell phone they use
– Behaviors surrounding the product or service of interest
– The questionnaire would typically include termination criteria where a
potential subject is rejected if they do not meet all of the key criteria.
• Recruitment questionnaires can be administered on line (e.g.
surveygizmo) or by phone (preferred, because you can ask open
ended questions)
• Typically a research protocol would specify subject breakdown
ahead of time
11. Research technique: Contextual Interview
• 2-3 Researchers meet with a subject in the target environment for 1-
1.5h
• The conversation is typically recorded
• The interviewer asks open ended questions to get the subject to tell
a story about the topic of interest. Always ask “Why?” or “Why
not?”.
• The interviewer lets the subject lead the conversation
• Researchers debrief immediately after an interview
• A report is created that incorporates key insights, detailed notes,
quotes, images, videos
• Best practices suggest we conduct ~20 qualitative sessions for a
good sampling
12. Research technique: Observation
• 2-3 Researchers set up recording equipment in the target
environment, and observe while the subject works or plays in the
target environment.
• Researchers take copious notes while looking for examples the
subject is doing something unexpected in order to compensate for
the inadequacies of a product or service.
• Researchers may interact socially with the subjects but largely leave
them alone – except when situational questions arise, where
researchers may ask clarifying questions
• At the end of the observation session the researcher may conduct a
debriefing interview with the subject to understand the behaviors of
the subject
13. Crunching the data
• For each session: process transcripts, bring out the key learnings,
create a report to record that session
• After 5-10 sessions: research team meets to look for patterns,
simplifying concepts
• Test hypothetical personas against findings to date; adjust and
iterate
• After 10-20 sessions: verify early findings, fine tune results
• Develop buyer and user personas (each is a composite of all the
people that the researchers met, representing key attributes that
define them as a group)
14. Example persona
14
Primary User Persona: Aspiring Technical Founder
Name: Paolo
Age: 23
Gender: Male
Occupation: MIT EECS Ph.D. Student , concentrating on computer vision
Personality profile: Introverted; uncomfortable around people. Prefers email/IM/texting over face to face communications
or even voice calls.
Technology profile: Deep geek about all things Linux and Android. Carries an HTC Android phone, runs Ubuntu on his
ultraportable laptop, owns a Samsung Galaxy Tab II, administers his own Linux server at his apartment, which he shares
with 2 roommates. He does not have a car – he’s a starving grad student after all.
Paolo can’t remember a time when he doesn’t know how to write code. He wrote his first computer game at age 11 on his
mom’s Mac. He is a Linux buff and his current research interests center around gesture recognition using input from low-
resolution cameras (sort of like Kinect on steroids).
Paolo believes the gesture recognition algorithm he is currently developing will blow the Microsoft Kinect out of the water.
His technology is developed to be cross platform from the get-go. It can be packaged to work for Windows, Mac, iOS and
Android. He’s proved this with demo apps on all these platforms. While his demo apps don’t sport the prettiest UI, his
friends all think it’s cool and that he should do something about it.
Paolo desperately wants to start a company to productize this technology. The only problem is that he has no idea how. He
has interned at some big companies but never at a startup. He has never made and shipped a product. He’s read enough to
know he doesn’t know how to bring his idea to fruition.
“It is so inefficient reading up on startups – the stuff is everywhere. I need a centralized resource.”
“Why can’t there be a website that just tells me what classes to take to learn this stuff?”
15. Needs, wants, expectations
Needs Wants Expectations
• Be taught some basic business sense –
what does it really take to turn an idea
into a prototype, then into a product
and a viable business
• Understand how to build a team to
achieve this
• Learn the basic mechanics of company
formation, fund raising, how to
understand term sheets / liquidation
preferences, etc.
• Be connected to mentors who can help
him validate his idea
• Be connected to potential cofounders
and other resources who can help him
get started
• Find out what courses to take at MIT to
help prepare him for entrepreneurship
• To take his game-changing idea and turn
it into a startup
• To have his own company straight out of
school – living the startup dream, never
going to work for anyone else
• To avoid human contact as much as
possible (Email/GChat is ok, texting is
marginal, face to face is a last resort)
• To be allowed to focus on technology as
much as possible and let someone else
worry about all that business stuff
• To understand how to pick the right
business partner – what questions to
ask, what experience to look for
• Readily available content that he can
consume in the privacy of his dorm
room. “I can read a book and do
anything better than anyone else who
has been doing it for the past 25 years.”
• Ability to lurk on various networks and
learn about startups by watching others
interact
• Be able to quickly browse and search for
information he needs
• Not be bombarded with a ton of
business gobbledygook – no BS allowed
• Able to leverage facebook and linked in
for networking
Primary Persona:
Paolo, MIT EECS Ph.D. Student,
Aspiring Technical Founder
16. Come up with a solution
For [target end user]
Who wants/needs [compelling reason to use]
The [product] is a [product category]
That provides [key benefit].
Unlike [main competitor],
The [product] [key differentiation]
17. Sample positioning statement
For the aspiring technical founder
Who wants/needs a trusted resource to help them learn
about entrepreneurship
The MIT Entrepreneurship Center Website
is a key informational and networking resource
That provides a single destination for practical information
about how to start and run a company, as well as rich
community features that help them network with mentors,
partners and more
Unlike other on-line startup resources
The E-Center Website combines thoughtful, well curated,
content with a vibrant community that will quickly help
founders get their companies off the ground
18. Build a storyboard and test it with
prospective buyers / users
Image source: via Google image search - http://www.sophiewijaya.com/works/single-gallery/5433057?originalSize=true
19. If possible: build a very minimal interactive
product prototype, and test that
Image source: Zeo, Inc.
20. If not possible: deploy vaporware
Image source: via Google image search - http://www.carbodydesign.com/archive/2009/03/05-ford-iosis-max-concept/
21. Test the mockup with users, learn and iterate
Image source: via Google image search http://iat.ubalt.edu/usability_lab/
22. Define the Minimum Viable Product (MVP)
“The idea of minimum viable product is useful because you can basically say:
our vision is to build a product that solves this core problem for customers and
we think that for the people who are early adopters for this kind of solution, they
will be the most forgiving. And they will fill in their minds the features that aren’t
quite there if we give them the core, tent-pole features that point the direction of
where we’re trying to go.
So, the minimum viable product is that product which has just those features
(and no more) that allows you to ship a product that resonates with early
adopters; some of whom will pay you money or give you feedback.”
Eric Ries, The Lean Startup
“If you aren’t embarrassed by your first product, you have launched too late.”
Chris Dixon, Founder Collective, Hunch
23. MVP Requirements do’s and don’ts
100
page
MRD
DO
• Write SOMETHING down
• Get buy-in from ALL
STAKEHOLDERS.
• Be practical and specific. Leave it
loose at your own risk.
• Build a top level project plan that
identifies key tasks, milestones and
interdependencies
• Develop a lightweight 2 year roadmap
DON’T
• Start building anything without
buy-in
• Write a 100 Page MRD
• Overspecify details on each
feature in classic Waterfall
fashion
• Build a 5 year product roadmap
with a great deal of detail
Water-
fall
style
specs
5 Year
Road
map
Rely
only on
oral
tradition
24. “MVR” (Minimum Viable Requirements)
• Clear description of the market problem that is being solved
• “Elevator pitch” of the solution (preferably with images)
• Description / analysis of first target segment
• Buyer and User Personas
• Detailed storyboards on top 1-3 typical workflows
• Specific examples for details encountered in each workflow
• Considerations for human factors / human cognition
• Top level design directions to be followed by product design team
• Lightweight functional description of minimum viable product (MVP)
• Quick and dirty 2 year product roadmap
• Any external business drivers (e.g. trade shows, funding runway,
etc.)
25. Product roadmap is a plan, not a commitment
Image source: via G oogle image search http://techon.nikkeibp.co.jp/english/NEWS_EN/20080509/151528/
26. Build a top level project plan for MVP
• GOAL: Identify interdependencies. Who needs output from whom?
Minimize elapsed calendar time with better coordination.
• VERY IMPORTANT: Don’t overplan . SWAG it and let the
developers run with it. “Planning is guessing” – Jason Fried in
Rework
Image source: via Google image search http://www.total-quality-management-software.com/images/project_gantt_chart.gif
27. Build the team
Product
Manager
Development Manager
Product
Design
Engineer-
ing
QA
Product
Marketing
Manager
Customer
support
Manager
Manufact-
uring
Manager
Purchas-ingRegulatory
Consult-
ants
Legal
Counsel
MarketingSales
Finance
Operations
IT
28. Develop the MVP: Hardware
Phase 0:
Feasibility
Phase 1:
Engineering
Prototype
Phase 2: Pre-
Production
Prototype
Test and validate Customer Research
Test and validate Customer Research
Test and validate Customer Research Release
to
production
Stage Gate picture source: via Google image search http://mastersonconsultingllc.com/newproductdevelopment.html
29. Develop the MVP: Software
Image source: via Google image search http://www.processflowchart.net/agile-development-process/
30. Hardware Software
Development / release cadence Bursty (a single
iteration can
take several
months)
Can be
continuous if
practicing Agile
Development cycle duration Long Short
Cost for each cycle High Low
Cost to go to market Very high Low
Product lifecycle Long Short
Cost for development mistakes High Low
Cost for production mistakes High N/A
Cost to fix mistakes after product has been released Very high Low
Turnaround time to fix mistakes after product has been
released
Long Short
Recommended level of ROI analysis before starting
product development
Thorough Cursory
Recommended level of customer research High Medium
Recommended level of detail for product requirements Higher Lower
Hardware versus Software
35. If you haven’t done so yet: do your
pricing research
• Develop a product concept (as good as an ad)
• Qualitative testing with select prospective customers to
hone the concept
• Quantitative testing to gauge price sensitivity
– Van Westendorp Price Sensitivity Meter
– Monardic testing (show 1 price, gauge likelihood to buy)
– Sequential monardic
– Paired-comparison
– Conjoint analysis
– …
• DON’T: draw any pricing conclusions from a few face-to-
face chats if dealing with consumers. (People lie.)
36. Are you ready to launch?
Product
Manager
Development Manager
Product
Design
Engineer-
ing
QA
Product
Marketing
Manager
Customer
support
Manager
Manufact-
uring
Manager
Purchas-ingRegulatory
Consult-
ants
Legal
Counsel
MarketingSales
Finance
Operations
IT