Is that at all <i>useful</i> when trying to decide what to do next?<p>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?<p>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.<p>It still leaves many questions unanswered - how do you decide what is the riskiest feature?  Is there an easier way to test what you&#x27;d like to test?  But at least it gets you <i>closer</i> to having an actionable plan to reliably figure out market needs.<p>It&#x27;s great to have a concrete definition of what an MVP means, but if the result of that definition is that the <i>process</i> of building a startup is &quot;Do you have an MVP?&quot;  &quot;Nope.&quot;  &quot;Do you have an MVP?&quot; &quot;Nope.&quot; &quot;Do you have an MVP?&quot; etc, then so what?