(from Melissa’s slideshow for Lean UX NYC 2014, which I was at but somehow missed summarizing, link here)
This summarizes only a portion of Melissa’s great talk—check out the link for more great insights
Don’t think of an MVP as a Product Lite version of your product—that’s not it
An MVP is an experiment you run to learn something you need to know to effectively move forward in creating a product
The general creation flow is Problem Exploration (discovery) > MVP experiments > Feature development
HOWEVER, if your MVP can’t fail and your product idea can’t be heavily modified or discarded, than this type of MVP isn’t for you—it will just frustrate you if the experiment’s results aren’t actionable (and actually it’s a waste of everybody’s time/energy for the same reason)
Experiment process:
- Set up
- Design
- Run
- Feedback
- Iterate
MVP process:
- Define customer and problem
- Investigate assumptions
- Design a test
- What do we want to learn?
- How will we measure that?
- What is the least we can build to learn? (key question that’s often left out)
- Watch people use it!
- Measure customer behavior
- Evaluate success
- Pivot or persevere
For MVP experiments, focus on the riskiest assumptions (i.e. which assumptions, if disproven, would end your project?)
- Write a customer hypothesis and problem hypothesis to guide the experiment’s creation
- Design an MVP test
- GOTB and talk to real people!
- At least 10 people
- Verify your two hypotheses and as many other assumptions as you can
- One outcome might be to pivot (strategic change in direction based on learning)
- No further investment until either the experiment’s success is validated, or if it fails, the decision is made to continue experimenting
Types of MVPs
- Wizard of Oz (front end looks real, back end is totally manual)
- Good: Looks real to customer so very accurate response
- Bad: Gotta write some code and you can’t tell why folks don’t use it
- When to use? If you are:
- Running a large scale test
- Trying to sell a feature/service before it’s built
- Concerned about sacrificing your brand
- Concierge (delivering your future service manually)
- Good: Close to customer, easy to learn, easy and cheap to get started and adjust based on feedback
- Bad: Not scalable and time consuming
- When to use? If you are:
- Testing a service
- Trying to determine what customers will respond to
- Testing and refining on a small scale
- Landing Page (pitch your product and gauge reception)
- Good: Just a pitch, don’t need all the details figured out and can be launched quickly
- Bad: Gotta get the page in front of folks via marketing!
- When to use? If you are:
- Looking for initial customers to test with
- Trying to gauge interest level
- Easy to pitch to a large audience
- Videos (Demo your product via video presentation)
- Good: Can demo complicated things; and show a prototype before producing
- Bad: Complicated to create; a decent amount of work has to be done before you have anything to video
- When to use? If:
- Your product does something very easily
- Your product sounds complicated
- People need to see it to believe it
An MVP sprint structure might be:
- Mon: Reflect and define
- Tue: Specify
- Wed, Thu: Build and refine
- Fri: Customer feedback
Finally, in homage to Melissa’s famously feline presentations, a slide from her presentation noted at the top of the post:
About Melissa (from melissaperri.com): Melissa Perri is a Product Manager, UX Designer, speaker, and coach. Working along side product development teams around the world, Melissa helps them create product strategies that satisfy users and drive business goals. She coaches Product Managers to answer two important questions – “Should we build this?” and “Why?” Harnessing knowledge from Agile, Continuous Improvement, and Lean Startup, Melissa has developed her own processes for great Product Management that she teaches through workshops and consulting. Her clients have included Spotify, Rovio, Valtech, Plated, Wayra UK, and Levo League.
