Organizations often misunderstand an MVP as the bare minimum set of functionality to produce an intended result. They associate an MVP to a “Beta release” and focus their effort on stripping down their product to minimize the development time and test the release as quickly as possible with their users. While this is not a wrong approach per-se, in my experience it does not represent the full meaning of an MVP.
The focus of the MVP should not be on the “build” bur rather on the “learn” objective. Many teams confuse the MVP as building a functional slice of their product, releasing it, and then continuing building the next slice. An MVP is not a slicing approach to building a product. Rather it’s a learning opportunity to collect feedback and validate a hypothesis as quickly as possible, and then change the plan if needed. The main question an MVP should help you answer is not “can I build this?”, but rather “are customers interested in buying it?”.
The H-B-T model of an MVP
As discussed above, an MVP should not be a Beta release but it should incorporate elements of the customer experience and of the business viability that are needed to validate if the product idea is worth pursuing and if it delivers market-solution fit. I like to borrow a model used to explain the competencies of a product manager, and apply it to an MVP, as I think it does a good job an explaining the broader scope of an MVP, beyond a limited set of capabilities. This is the H-B-T model, that incorporates the Human, Business, and Technology dimensions to create a more balanced view of an MVP.
H – Human dimension
The Human dimension focuses on the MVP elements that create the customer experience you want to offer to your customers. In order to validate your MVP, you need to test the whole customer experience around it. How are your customers going to discover your product? How are they going to use it? How are they going to get support for it?
The key is to create elements of the full customer experience without a full upfront investment in the final setup. For example, if the customers are likely to incur into problems in using your product (for example, because it’s too innovative and they may not know how to use it), you may expect them to seek help through the customer support. You can offer support using an email address or a single phone line, even if you expect at full scale that you will need thousands of call-center agents. Offering an avenue to your customers to get support and voice their concerns, allows your customers to get a stronger sense of satisfaction from your product, and offers you the possibility to validate whether your support channel provides the intended benefits. The goal is to test and validate the desired customer experience with the minimum investment.
The Human dimension also help us think about who the target customers are. Often, when launching an MVP, we may target early-adopters as the product may be too new for mainstream users. You need to define who these users are, to develop a better understanding of their needs, and to validate whether your MVP delivers on their expectations.
B – Business dimension
The goal of an MVP is to learn, and to do that you need to know what to measure. The Business dimension focuses on identifying key metrics and objectives that you want to validate with your MVP.
This dimension helps you focus on the business viability of your idea. The goal of the MVP should be to determine whether you can achieve market-solution fit, that is are your customers willing to pay for your product? Are they going to use it? Are they going to refer it to other customers?
STORY: Launching the Goozex MVP
When we were building Goozex.com we kept a strong focus on a limited MVP – to limit the investment and increase the speed to market. We needed to validate the viability of our idea, that is were customers interested in trading used video games with other customers and receiving points in exchange? We needed to validate whether users were comfortable enough to engage with the concept, before investing in a full-scale development with all the options.
Video games can come in a variety of conditions (from new to badly used) and a variety of accessories (some have just the case with a cover, others have a manual, or an add-on accessory, or even a free gift). Managing all the conditions and options was beyond the goal of our MVP, and we decided to keep things as simple as possible in order to validate the overall viability of the idea. We launched Goozex.com with only the option to list a video game, regardless of condition or accessories. This made some users uncomfortable, and it was a good learning for us. But it allowed us to validate that the idea of peer-to-peer trading of used video games worked. We validated the business idea, and quickly added the options to specify the condition and accessories.
T – Technology dimension
This is the set of capabilities that are offered by the MVP. What does it do, and how does it do it? Is the MVP an app, or a physical representation of your product? In software development, the Technology dimension for an MVP often results in a Beta version of the product.
Determining the minimum set of capabilities to include in an MVP is not a trivial task as it depends on several factors including the resources you have available, what you need to validate, the relative access to customers and their expertise with your product, and the business priorities imposed by the strategic direction or market forces. As discussed above, the capabilities should include elements of the customer experience and useful metrics that the business can use to validate the viability of the product idea.
