It is one thing to know your customers have a problem; a low-fidelity MVP is how you learn about what ails your target money. But you only make money if you solve your customer’s problems. High-fidelity MVP are how you learn if your company merely feels your customers’ pain, or if the product you are developing alleviates your customers’ pain.
High-Fidelity MVP (Minimum Viable Product)
A high-fidelity MVP’s sole purpose is to test whether your product solves the problem that your users are having. This is where elements such as the user interface, user experience, and user engagement are examined. A high-fidelity Minimum Viable Product is where you build your prototype or at the very least a more detailed clickable mockup.
Your first step is to figure out when you should move on from testing your low-fidelity minimum viable product to the next stage. Unfortunately, there is no obvious signal that you should take the next step. On the one hand, you want to vigorously test your problem assumption. However if you focus on that issue too long you get analysis paralysis. You will never get complete certainty from your low-fidelity minimum viable product, so you shouldn’t look for it. Instead you should move on to your high-fidelity minimum viable product when you are relatively confident you have found your problem. If you need a percentage, shoot for being 85 to 90 percent confidence.
Just as with the low-fidelity MVP, a high-fidelity MVP only works if you choose effective metrics to monitor that accurately represent your performance. The things you should be measuring are tied to customer engagement. Are they ordering your service (if applicable)? How long are they spending on your site using the tools? Are they suggesting your service to others? These are the sorts of things you should be monitoring while rolling out a high-fidelity MVP.
Related: An MVP Is Not A Cheaper Product, It’s About Smart Learning
Small Batch Testing
Once you have built your high-fidelity MVP you will still want to control your audience exposure in the early days since there is a high likelihood of bugs and other small errors that might be diminish the user’s experience. Studies have found you can identify 85 percent of the problems in your MVP by testing it with as small of a user base as five people.
Once you have started testing, focus on how people use the site as opposed to what features your users say they want. People say what they think they want, but how they act in relation to your site better illustrates how they will interact with your product. Focus on the issues that inhibit your users from engaging the site the most, then make as small adjustments as possible to address those concerns. Doing small things to fix big problems will decrease the possibility that in your attempt to fix a problem you lose something that your users like.
The key here is to establish a baseline product. You do not want to be adding big, new, flashy features here. Think tinker, not renovate. You need to keep testing and adjusting until you get a product that works, with no bugs, and provides positive evidence that you have a product that will solve the problem you sought to address..
Small batch testing is not strictly necessary. It is a good idea if you have an minimum viable product that you are not confident will provide you with quality results in testing due to other flaws not tied to the aspects you are testing; specifically whether your product solves the problem, whether you business model works, and the product’s acquisition and activation processes.
Customer Validation
Customer validation occurs when you take your high-fidelity MVP to a larger audience. The purpose is to validate your solution and business model. Despite the fact that your product will be in front of a larger audience, the same basic tenants we have been preaching throughout this series of posts still apply. Iteration is key; a series of imperfect MVPs that provide information about your core questions (the problem solving ability of the product, your business model, etc.) is preferable to a “perfect” product that takes forever to develop and ultimately provides too much information to understand what is working and what isn’t.
You also need to make your high-fidelity MVP flexible so it can quickly and easily adjust to new information. If you get new information but have built your product in such a way that to make any changes will essentially require you to start from scratch, you have significant problem. Building your product through incremental iterations through agile development will prevent this from being a problem. We’ll discuss agile development in more detail in an upcoming post.
High-fidelity MVPs are a great tool for testing whether your product solves a valuable problem and your business model. It should be the first thing you do when you are ready to test your product-market fit. However, some might skip this step because they are confident in their product and business model. A good example of when to skip this is step is when you are improving an existing product that already has a strong customer base. But be careful. Skipping this step should only be done when you are extremely confident in your product-market fit and that the risk is relatively low.