Building a Workable Hypothesis for Your Minimum Viable Product
In our previous piece, we discussed the popular concept of MVPs. Our key message was as follows: working on an MVP bears a resemblance to scientific experiments. First, you shape an initial assumption about the need you want to satisfy with your solution. Then you translate this hypothesis into a limited version of your product to be introduced in the market. After that, you will ‘test’ it with real early adopters. At this stage, you are supposed to receive as much valuable feedback as possible to improve your MVP, add new features, ‘polish’ the interface, etc. And as you can see, this long way to success starts with a hypothesis.
Indeed, a reliable hypothesis is an obvious cornerstone here. If you manage to detect (or even to ‘invent’) a gap to be closed by your MVP, your chances to win big will definitely be significant. We are going to offer a framework to build such hypotheses below.
Basically speaking, the MVP-centered mindset replaces ‘Can we develop this product’ with ‘Should we develop it at all?’. Consequently, a typical business roadmap starts with a problem, then it switches to a solution and ends with expected results.
One can outline such a hypothesis this way:
– Our team believes that certain users [INSERT YOUR TARGET AUDIENCE] experience difficulties while doing this or that [INSERT THE PROBLEM]
– We assume that our solution [INSERT YOUR PRODUCT] can help them resolve this difficulty via its core functionality
– If we are right, then we will attain the desirable result at a given moment of time [INSERT YOUR KPI and DEADLINES]
– If we fail to achieve the expected outcomes, we must have been mistaken
Practically, you take the following steps:
– Making an assumption
– Executing a production, development, and promotion plan based on this assumption and available resources. In other words, you perform an experiment with your hypothesis
– Analyzing the data generated by the experiment
– Confirming a correct hypothesis, revising a partly correct one, or rejecting a false one.
Now let’s go deeper into details regarding each of the phases.
Assumption: explore your target audience via surveys, interviews, competitor analysis. Identify and isolate its main ‘pain point’ that hasn’t been yet properly covered by other products.
In the ideal case, you are supposed to be able to fill out the following fields.
Target AudienceTheir Pain PointOur SolutionSuccess Criteria
Plan: frame a scheme of dealing with this ‘pain point’ via your product. You need to focus on a single core functionality that has to be implemented really well. Try to calculate how much resources you can spend on it, including:
– Marketing and promotion costs
– Success criteria and deadlines
Analysis: this is the critical phase to assess the success of your venture. You may use both qualitative and quantitative techniques for it. As for the first ones, you can rely on such indicators as downloads, signups, successful trials, retention rates, customer acquisition costs.
However, it is also reasonable to utilize such qualitative methods as deep customer interviews, satisfaction surveys, discussions with users and peers at conventions, meetups, and other events. Sometimes, such time-consuming approaches may provide you with insights that are more valuable than cold and dry figures.
Further evaluation: if your hypothesis is at least partly true, you can move forward and improve your product in accordance with customer feedback.
To top it all off, let us reiterate the key point of this brief guide. Your main goal as a startup is to comprehend which idea is the right one to be translated into a product. And to win, you need to build this product and start validating your hypothesis ASAP. That is why it is more important to imagine such a product than to build it: after all, coding and testing is no rocket science.
Once again, if your idea is good enough, coding is a subordinate issue. You can make mistakes, take your time to improve the product, and put all the minor aside. That is how the modern oversaturated market works. As Eric Ries, the popular author of ‘The Lean Startup’, stresses, ‘MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses.’
Contact us, if you need assistance and expertise for a viable hypothesis. Evercode Lab is always happy to come to the rescue.
Originally posted on the Evercode Lab page here