Re:A Minimum Viable Product Is Not a Product, It’s a Process
by ScottBurson on Saturday January 23, 2016 @04:05PM
(#10960079)
I think the usefulness of insisting on reserving the term "MVP" for a successful experiment is that it could help prevent someone from spending months in development, telling themselves "we're building our MVP, we're building our MVP", and thus thinking, when they've built something but not yet shown it to anyone, that it is an MVP. No; you hope it is, but it may not be (and in fact, the odds are against you if you haven't discussed it with potential customers).
So this is not just a semantic quibble, but actually supports the thrust of the article. While you're doing market research experiments, you should call them that. When you actually strike gold, then you have an MVP.
Okay, so an MVP is a product with the absolute minimal set of features necessary. How do you find that core of features? How do you determine which feature you will add (or test) next? How should you build it? Who should you put it in front of?
The advantage of this article is that it provides some answers for those questions. You should build the riskiest feature next. You should build it in the absolute fastest way that will let you have reasonable confidence in the result of your experiment. You should expect to throw out many versions before you find one that works.
It still leaves many questions unanswered - how do you decide what is the riskiest feature? Is there an easier way to test what you'd like to test? But at least it gets you closer to having an actionable plan to reliably figure out market needs.
It's great to have a concrete definition of what an MVP means, but if the result of that definition is that the process of building a startup is "Do you have an MVP?" "Nope." "Do you have an MVP?" "Nope." "Do you have an MVP?" etc, then so what?