Often when we think about an MVP, we think about a barebones version of our product that we can use to validate any hypothesis that we can dream up. But,…
Often when we think about an MVP, we think about a barebones version of our product that we can use to validate any hypothesis that we can dream up. But, despite the pervasiveness of this idea, it's backward thinking.
To understand why, let's consider the purpose of an MVP, in the first place. Remember that much more than merely testing our product, the true purpose of an MVP is to validate a hypothesis in the style of the scientific method.
But building your MVP before you choose your hypothesis is akin to designing your experiment before you consider what hypothesis you want to test. If you haven't chosen the hypothesis that you want to test, then how will you know what kind of experiment will best suit your needs?
To build great products, you must first start by deciding what hypothesis you want to prove and then designing the experiment that's purpose-built to validate that hypothesis.
Finding Your Next Hypothesis
So, where you do you find your next hypothesis? From your hypothesis backlog, of course. Your hypothesis backlog is a running list of unproven assumptions that you currently have about your product, which still need to be validated. These assumptions might include things like outstanding risks, unanswered questions, or unvalidated ideas.
Just like working from your regular product backlog, working from your hypothesis backlog is merely a matter of prioritizing by whichever hypothesis is the most important to you and then designing the MVP that best validates that specific hypothesis.
Making the Most of Your MVPs
But does this mean that you can have only one MVP per hypothesis? Not at all. While each of your MVPs should be purpose-built to test a given hypothesis, with a little upfront planning you can design an MVP that lets you simultaneously test multiple, closely related hypotheses.
The idea is not to limit each MVP to a single hypothesis, but instead to start with your hypotheses first and then design the MVP that is best suited to testing those specific hypotheses.
For example, in the image below you can see how Hypothesis1 and Hypothesis2 each map to a corresponding MVP. However, Hypothesis3 and Hypothesis4 are presumably so closely related that they can be validated using only a single MVP.
Creating a Culture of Intentional Experimentation
The key to shipping to successful products is not only to create an ongoing culture of experimentation but also to create a culture of intentional experimentation.
Teams who simply experiment wildly with little thought for how those experiments will contribute to their overall strategy rarely stumble onto the right product that makes their business successful. But, teams who take an intentional approach to experimentation and take the time to design MVPs that are best suited to validating each hypothesis are in a much better position to discover how to make their product successful and to do so much more quickly.
Are you new to the Product Owner role and are just trying to find your way? Or, are you an experienced Product Owner who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Product Owner and help your team reach their highest potential.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.