A core tenant in agile product development is the idea of minimal viable product, or MVP. For such a fundamental and powerful concept, it’s remarkable how often some either misunderstand, or are unable to execute, an MVP effectively. At a high level, you can think of a minimal viable product this way:
Do as little as possible to…
answer a question about…
your product assumptions.
In other words:
An MVP is a version of a new product which allows you to collect the most information with the least effort.
The goal is to understand customer interest in your product without going through the effort and expense of fully developing it. Because the goal of the MVP is learning, the requirements of the MVP are directly related to the information you need.
I’ll say that again: an MVP’s sole purpose is to answer a question (or questions) about your product. The design of your MVP is dictated by the questions you ask. Here are two examples of common questions and how they dictate MVP design:
“Are my customers interested in this product idea?”
The knowledge you require is found by interacting with your customers. The MVP could be as simple as a non-functional product landing page that tracks customer behavior. Specifically, questions like, ‘Where did the customer click?”, “What marketing content did they consume?”, and “Was price a limiting factor?” could be tracked and answered. This in turn would tell volumes about customer intent and sentiment about your product.
An MVP like this can be built and deployed very quickly, allowing you to gather the customer feedback required to make intelligent product decisions. The data, both quantitative and qualitative, inspires confidence that you’re making the right product choices.
“Does my product design cover my primary use cases?”
In order to surface important (but not obvious) edge cases, your users need to put the product to actual use… there is no better way to find the holes in your feature set and make sure they can do what they want to do. Observed user behavior will validate (or disprove) your assumptions about how they use the product.
To answer this question, your MVP might require automation to appear functional. When the user takes an action, the product responds as expected (even though the functionality has not been built yet!). Experiences like this can be accomplished using pre-programmed responses (if user does X, respond with Y), or even using human intervention (a member of your team manually performs the actions of the system). To the user, it ‘feels’ like a real product.
Two common MVP pitfalls:
- “Minimal” to the max
Minimal is seductive. How little can we build?! Sure, we can fake that! Many teams focus exclusively on spending as little resources as possible while forgetting to consider if it will provide actionable information. Remember, an MVP is designed to answer a question. If it fails to do this, it can’t be cheap (in time and resources) enough.
- “Viable” means full featured, right?
Instead of building too little, this type of MVP is too-featured, too-developed, too much time, too much money, just too-much. If the resources required to build the MVP rival the actual product development, you’re not building an MVP, you’re building a (likely terrible) product.
Higher (product) learning
The highest quality feedback is observing a customer’s actual behavior when using your product. Observing what they actually do is much more reliable than asking them what would do. Only by trying to complete their action will they communicate the entirety of their product journey: their expectations, confusions, frustrations, and most importantly, intentions.
A – B – C – D
Always Be Capturing Data
When phrasing the questions that your MVP will answer, define the key performance indicators (KPIs) you will track. Don’t rely on gut interpretation of the information you get from your customers–this is plagued by confirmation bias–and instead use your KPIs to validate your assumptions.