What is the Agile Business Analysis Technique Minimal Viable Product?
Minimal Viable Product (MVP) is used to avoid cost and risk associated with developing the wrong product by testing a hypothesis, reducing waste, or increasing speed to customers for feedback and adoption.
Minimal Viable Product (MVP) identifies the smallest set of features or requirements to deliver value to stakeholders and satisfy early adopters in the shortest time possible. It focuses on core features sufficient to deploy and deliver stakeholder value and no more. Further features are developed after considering feedback from the initial stakeholders.
It applies to
- product development,
services (commonly to test willingness to pay),
- feature development (to gauge demand), and as
- differentiation (market test strategy).
Minimal approaches are frequently chosen based on time and money constraints. Minimal Viable Product (MVP) enables iterative development cycles by collecting and analyzing feedback before delivering additional features.
Join the IIBA Endorsed Agile BA Practitioner course – online, on demand with full tutor support.
MVP generally follows these three high level steps:
Step 1: Determine the problem to be solved.
Identify a hypothesis to solve this problem.
Step 2: Identify a minimum set of features to test the hypothesis of the solution.
Think about creative, low-cost options to test the hypothesis with the target market.
Step 3: Analyze validated learning from customers to determine the next step.
Gather feedback on feasibility of the solution and additional features needed to increase adoption.
Business analysis practitioners clearly identify the target market and who will likely be the early adopters of the solution. Analysis of these groups identifies what problems they may have related to the proposed solution.
Goal to Achieve or Hypothesis to Test
Business analysis practitioners clearly define the goal or the hypothesis to test with MVP.
For example, the hypothesis may suggest that the new product will lead to quick adoption with the target audience. Or, the organization may hypothesize that a new feature in a product will improve customer service.
Mechanism to Measure Learning
In order to validate the hypothesis or to determine if the desired goal was achieved, business analysis practitioners identify objective measurements to correlate and interpret the feedback and learning received.
These measurements influence further solution development by identifying the success of the current MVP.
Business analysis practitioners select the minimal amount of requirements necessary to deliver the MVP. This selection is based on the target audience, the goal to achieve, and the mechanism to measure learnings.
The amount of requirements necessary is subjective and dependent on context. There must be enough produced to validate the hypothesis; however, it must be the minimal amount to release the solution quickly.
Strengths and Weaknesses
Some of the strengths of this technique include:
It is less expensive than developing a product with more robust features.
- Reduces cost and risk by gaining customer feedback before engaging in a full solution.
- Avoids building products customers don’t want, thereby reducing risk.
- Tests actual usage scenario instead of relying on market research.
Some of the limitations of this technique include:
- Requires advanced market analysis to identify the necessary feature set for early adopters.
- There is no formula, and desired features are a best guess.
- It is not about creating a minimal product, but testing an initial hypothesis for a product.
- It is not useful for a clear or simple solution. For this situation, the defined Minimal Viable Product (MVP) is the complete product and should be considered as such.
Notice: As with all the bite-size videos we have created around the topic of Agile Analysis, the content covered here is quoted from the Agile Extension v2 to the BABOK Guide v3. In some parts we have summarised content and some parts we have added some new examples. For a comprehensive coverage of this topic, please refer to the Agile Extension v2 Chapter 7, Section 7.6.