For many organizations, they’ve come to use MVP to mean a less functional, limited implementation application. Build it quick, get it into the hands of customers, and see how they like it.
This isn’t how MVPs are supposed to work. Eric Ries, who coined the term in his book, The Lean Startup defined an MVP as something that “allows a team to collect the maximum amount of validated learning about customers with the least effort.” What’s the smallest experiment you can do to test your biggest assumption? And as Tom Chi, co-founder of Google X, puts it:
“Maximising the rate of learning by minimizing the time to try things.”
But before we delve deeper. let's see what risk in business language means. Risk is nothing more nor less than the quantitatively defined impact of an event, times the (also quantitatively defined) probability of that event occurring. To put simply:
The goal here is to pick out at least 5 of your riskiest assumptions and objectively test them using generative research — mostly because if it’s early stage you probably don’t have the quantitative data that you need.
Gather your main stakeholders in one room and map all your assumptions that are vital to your product. I do this in two ways. One way, I ask them questions about what problem they think the product solves, which are the customers, what insights they have from speaking to sales or customer support. Think of this like ask the experts session when running Design Sprints. Then group those assumptions into groups.