Approaching a Minimum Viable Product
Eric Ries [update] is the latest product developer to promote “Minimum Viable Product” to describe a product created to elicit feedback. A recent mailing list question suggested to me that more explanation was necessary. Here are my thoughts on what an MVP is and how to approach it.
The purpose of the MVP is to answer your most pressing question, to validate your most pressing business assumption. To create an MVP work backwards from your question, not forwards from a feature list. Invest as little as possible to answer the question because after this there will be another question and another and you’ll need enough money to answer them all.
For Tattlebird [my new product], my first critical assumption was that stuff was happening in browsers that site developers would care about. Working backwards from that question, all my MVP needed to do was gather data in a browser, send it to a server, and show it, minimally, to a single user. That was the list of features for my MVP. An hour later there was a flood of exactly the kind of information I was hoping was out there.
Your networking platform [the original questioner was asking about the MVP for a professional networking platform] must have a twist, something no other professional networking platform currently does. If users don’t care about the twist you’ve found, your idea (this iteration of the idea, anyway) is invalid and you’re best off moving on.
Let’s say the twist is location–you have the professional network that shows where people are in real time (hey, not a bad idea!) If people don’t care about location, it’s time to move onto the next idea. How are you going to find out whether people care about location? Well, you have to have a system that two people can use, the system has to have some way to find out where they are, and the system needs some way to notify both people where the other one is. There’s the MVP–what’s the fastest/cheapest way to get that done and then ask users whether they care?
What’s Hard About That?
I don’t know about anyone else’s practice of MVP, but what makes it hard for me is completely irrational: I prefer dreams to answers. I’m not saying this is a good thing or useful or sensible, you understand. It’s just something that’s true of me that I’ve come to understand.
For example, after I validated potentially-fatal assumption #1 for Tattlebird (“interesting stuff happens in browsers”) I needed to validate potentially-fatal assumption #2, “Developers will find the information useful, not just interesting”. That is, I need a story where a developer says, “Tattlebird told me surprising fact X, so I did Y, and now I’m making $Z more.” I don’t know if such a story is possible. If I can elicit such a story I may have a business. If I can’t elicit such a story, I need to move on.
Here’s where the dreams/answers dilemma comes up. Since I got the answer the PFA #1 I’ve been walking around with dreams of financial security floating in my head. It feels good to think I could make my living programming again. I don’t want to give that up. If I want to actually achieve that dream, though, I have to let go enough to find out if PFA #2 is true or not.
I could have gotten PFA #2 validated the day after I got a thumbs-up on PFA #1. Instead I fiddled and fussed for a week, a week I could have been using to get answers to PFA #2 through N. Yesterday I finally expanded the MVP just enough to get my answer and contacted someone who might use it and experience “the story”.
When I look back at all my startup experiences (all of them eventually sunk on a PFA), every single one of them could have been shipped much sooner. Sometimes the barrier was intellectual: it’s just plain hard to see how to ship 1/10th of a new piece of hardware. (Hard but not impossible.) By far the dominant reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback.
The problem with chasing the dream too long is that you end up without the resources to change direction when a PFA comes true. The MVP is intended to counter this tendency. The process of working backward from the assumption to the least possible investment to validate the assumption saves resources in the case of difficulties and keeps the business on the path of learning.