We generally acknowledge that pursuit of an MVP when starting out on something new is important. Humans have a dangerous inclination to get too attached to our ideas, and so MVPs helps us do no more than is needed to exploit some market opportunity.
However, our use of the term and application of the concept has been problematic. A lot of us – designers, developers, product managers, and beyond – don’t see eye-to-eye on what MVP means, what it looks like and how you get there. Nor do the folks who popularised the concept in the first place. And (as I’ll demonstrate during my 20min talk) nor does the audience in the room.
So, after reflecting on my own experiences and product failings, I went off and did more research – speaking to peers, re-reading the “it” books. And I decided that the best way to help us all align on what an MVP actually is – in a way that becomes sticky for teams everywhere – is by focusing on what an MVP certainly isn’t.
My talk will reveal MVP imposters and lookalikes, as I help us all rally around what it really means. I will run through some examples of minimum viable experimentation, before concluding with where pursuit of an MVP might fit into one’s design process.