Product Management: Minimum Viable Product

I was at 5th annual SVPCamp today.  There were several hundreds of product managers, entrepreneurs, programmers and designers to share ideas and network.  It was my second time at the event.  It felt great to connect with fellow product managers in Silicon Valley.  For those of you who missed SVPCamp 2012, I highly recommend that you attend the next year event.  I found that SVPCamp is the single best event for product managers to network and exchange ideas about product management challenges.

Your job as product manager is to strike the balance
between bare-bone minimum and
what will be acceptable in the market

This year there were several sessions around minimum viable product (MVP).  Discussions ranged from what MVP is, how to use it to reduce risk of launching a new product and what best practice looks like.  It looked like most of product managers and entrepreneurs were learning how to put together MVP on the job.

After listening to a couple of sessions and having some time to digest, I wanted to share my view on MVP.  As for slides from MVP-related sessions, I'll share the link once they come up.  For now, these are what I found to be key points of MVP through listening and mapping them to my own experience about MVP.



1. MVP is not a final product.

MVP is an exercise that you do when you are launching a new product.  When there are lot of risks in going into new area, you set up MVP.  What you must understand and help other key stakeholders in your company understand is that MVP is not yet a shipable product.  You put MVP together to get real feedback from users (customers and earlyvangelists).  Catherine Connor talked about her long cycle from beginning of MVP to final product being longer than a year due to nature of portfolio management cycles.

MVP is not a final product.  It's somewhere between alpha and beta stage.  It's what comes after product idea and initial product scope definition.

2. MVP must capture the best guess of a few key user stories.

MVP must be built based on assumptions.  What user cares most about solving, how user might visualize the solution to be are all good questions to think about.  In order to answer them, as product designer you have to make certain assumptions.  Be clear on what you are assuming.  Use iterative brainstorming sessions to drill down on promising ideas.  Make sure you don't go boiling oceans, however.  What you are looking for is a couple of user stories (maybe three, but no more than three) that you want to nail down completely.  Idea is for users of MVP to be able to solve their real problem using MVP.

MVP lowers the risk of failing spectacularly
by allowing you to learn quickly through real feedback;
Slide from Drew Houston CEO of DropBox on MVP

3. MVP must be quick and cheap.


You cannot spend months to build MVP.  That defeats the entire purpose of MVP.  Scope has to be small.  It's functionality must be simple.  It has to be put together quickly, so that you can start collecting real user feedback quickly.  If you are finding yourself spending more time discussing what MVP scope should be than building, you are wasting your time.  Build something quick and let customer tell you whether it works or not.

4. MVP must be iterated based on user (or earlyvangelist) feedback.


One of key reasons why MVP works is that it's working product.  It must be a working product regardless how little it does or how unfinished UI might look.  Your job as product manager is to use that MVP to see whether and how user can solve their problem per your assumption.  It's best done in user's natural environment as Chris Kocher pointed out in his Intuit example.  During the early days of Intuit (back when software were sold in a shrink-wrapped box), Intuit had a program where a developer would follow customer back home to see how their software was being used in user's environment.  Seeing how user gets distracted away from install process to tend to crying toddler shed light on what were really important to customers.

You want to speak to several users who understand what the product does and are passionate about solving the problem, i.e. earlyvangelists.  Not all users are earlyvangelists.  Rigorously qualify earlyvangelists using your sales team's help.

Once feedback is collected, you have more information to make better informed decisions.  Go back to MVP and see whether there were any assumption that were violated.  See if there is a better method to solve the newly defined problem.  Evolve your MVP to solve the new problem and release it back to earlyvangelists for feedback.  Rinse and repeat.

5. MVP is ready to be released when users start depending on it (or need it bad enough to pay for it).

You are done when your earlyvangelists or users start depending on MVP.  That means it will cause some pain when they lose the product.  And this usually means they will spend money to get the product once it's out as real product.  Now you are ready to productize the MVP.  One thing to be careful of is how to set the right customer expectation when you go out to build a real product.  Not all features included in MVP may make it to final product release.  Make sure customer understands them and none of the ones that you have pivoted away from are key user stories that prevents the rollout.

Anything you might want to add to this list?  Please feel free to add your comment.