© 2014 ConceptSpring
Elaine Chen
September 2014
Entrepreneurial Product Development
“Lean”
Eric Ries
Steve Blank
Lean Manufacturing Lean Startup™
Customer Development
Key tenet: Reduce Waste
Agile Software Development
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.
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
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
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
Choose your target
Entire market
Target segment
Early market
Potential
target
customers
Image source: Google image search
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
Conduct product discovery research
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
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
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
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)
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?”
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
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]
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
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
If possible: build a very minimal interactive
product prototype, and test that
Image source: Zeo, Inc.
If not possible: deploy vaporware
Image source: via Google image search - http://www.carbodydesign.com/archive/2009/03/05-ford-iosis-max-concept/
Test the mockup with users, learn and iterate
Image source: via Google image search http://iat.ubalt.edu/usability_lab/
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
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
“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.)
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/
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
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
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
Develop the MVP: Software
Image source: via Google image search http://www.processflowchart.net/agile-development-process/
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
Staying coordinated: The Daily Standup
Image source: via Google image search
Staying transparent: executive reviews
Image source: via Google image search
Develop, Test, Develop, Test
Image source: via Google image search
Develop, Test, Develop, Test
Image source: via Google image search
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.)
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
Ship it!
Image source: via Google image search
@chenelaine blog.conceptspring.com
Thank you

Entrepreneurial product development

  • 1.
    © 2014 ConceptSpring ElaineChen September 2014 Entrepreneurial Product Development
  • 2.
    “Lean” Eric Ries Steve Blank LeanManufacturing 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 Developmentwith “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 developmentin 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 Entiremarket Target segment Early market Potential target customers Image source: Google image search
  • 8.
    Develop hypothetical buyer/userpersonas 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
  • 9.
  • 10.
    Research technique: Subjectrecruitment • 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: ContextualInterview • 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 UserPersona: 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 NeedsWants 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 witha 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 Forthe 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 storyboardand 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: builda 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 mockupwith users, learn and iterate Image source: via Google image search http://iat.ubalt.edu/usability_lab/
  • 22.
    Define the MinimumViable 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’sand 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 ViableRequirements) • 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 isa plan, not a commitment Image source: via G oogle image search http://techon.nikkeibp.co.jp/english/NEWS_EN/20080509/151528/
  • 26.
    Build a toplevel 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 DevelopmentManager 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
  • 31.
    Staying coordinated: TheDaily Standup Image source: via Google image search
  • 32.
    Staying transparent: executivereviews Image source: via Google image search
  • 33.
    Develop, Test, Develop,Test Image source: via Google image search
  • 34.
    Develop, Test, Develop,Test Image source: via Google image search
  • 35.
    If you haven’tdone 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 readyto 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
  • 37.
    Ship it! Image source:via Google image search
  • 38.