2. MVP = Minimum Viable Product
to test fundamental business hypotheses
(such as value hypothesis and growth
hypothesis)
→One of the core concepts of Lean Startup.
It helps entrepreneurs start the process of validated
learning as quickly as possible. It is the fastest way to
get through the Build-Measure-Learn feedback loop
with the minimum amount of effort.
3. Any additional work beyond what is
required to start learning is waste.
→MVP differs from a prototype or demo version, as
MVP is designed not just to answer product design or
technical questions. NOT a lame beta either, as MVP
should be developed with clear hypotheses and goals.
4. So, what’s exactly MVP like？
For example, let’s assume that you want to provide service X, which
starts with a one-month free trial.
In order for this to work, further assume that 10% of site visitors will
sign up for the free trial.
When you consider that other assumptions such as conversion to paid
product will depend on this trial sign-ups, it is important to test this
assumption first.
To test, you should not develop and launch actual service X to see what
happens, as it leads to lots of waste.
You may effectively test it by setting up a site with a certain amount of
information about the service and a button/form of free trial sign up,
and measuring the completion rate of the sign-up.
In this case, such site itself is MVP. (The technique is called Smoke Test.)
→Type and complexity of MVP varies based on hypotheses
5. Q： Wouldn’t MVP give negative
impression ？？
Remember that you are testing hypotheses with early
adopters.
Early adopters use their imagination to fill in what a
product is missing and they actually prefer that state
of affairs. They are suspicious of something that is
too polished.
→Additional features or polish beyond what early
adopters demand is a form of wasted resources
and time.
6. Q： Wouldn’t MVP damage the brand？？
As part of the challenge of being a startup is the near
impossibility of having your product noticed by
anyone, you don’t need to worry about that too
much. However, you can easily mitigate this risk by
launching the MVP under a different brand name.
A long-term reputation is only at risk when
companies engage in vocal launch activities such as
PR and building hype. You should wait such
marketing launch for scale until the product has
proved itself with real customers.
7. Hesitation towards MVP
• Psychological hurdle of MVP can be high especially for
technical founders, as the vision entrepreneurs keep in their
heads is of a high-quality mainstream product that will
change the world.
→Remember and accept that it is the fastest way to get
through the loop.
• Many people want to internally strategize and debate to the
death on the product, design, and features, thinking that
customers wouldn’t know what they want.
→It is basically the same as avoiding to face reality.
Remember that there are only opinions inside the company.
8. MVP range in complexity and form
depending on hypotheses to test against.
Deciding exactly how complex an MVP needs
to be cannot be done formulaically. It
requires judgment.
→There are some patterns and techniques
that have been practiced so far and you can
learn from them. But remember that
deciding the right MVP requires human
judgment.
9. MVP Cases
#1: Groupon
• Skinned Wordpress blog and posted daily
• Used FileMaker to create PDF coupons and emailed
• Effectively validated the demand for such service without
developing a seamless system
#2: Dropbox
• Before starting significant technical development, made a 3
min video to demonstrate how the Dropbox is meant to
work, targeting at early adopters
• Call to action was to sign up for beta waiting list
• Effectively validated its assumption that customers wanted
the product that Dropbox was developing
10. MVP Cases
#3: Food on the Table
• Signed up the first customer by describing benefits of the service and
its subscription fee
• Without developing a software to deliver the service, the company
provided its service manually and personally （Concierge MVP technique.）
• Gradually automated as customers grew
• Allowed the company to learn customer needs in detail and to
automate functions that works and expand the scope of the service
#4: Aardvark
• Build a series of prototypes for ways customers could interact with the
virtual assistant and get their questions answered, measuring their
engagement
• Once Aardvark (the sixth prototype) was chosen, continued
refinement with humans replicating pieces of the backend as much as
possible（Wizard of Oz testing technique.）to avoid premature and
unnecessary technical development
