How to define a Minimum Viable Product — MVP
The Minimum Viable Product, although a properly defined term, means different things to different people. In fact, it is one of the most misused terms in the technology domain. It is often poorly referenced to describe a prototype, a demo, or even the first deliverable of a project.
“In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product
Defining the MVP
Assuming you have this great idea, you need a method to start defining the product. More specifically, the subset of the product features that can serve your objectives with the minimum cost and risk. The following explains how to get from an idea to an MVP.
Identify your users
Set the context — think of the problem, the situation, and the opportunity. Think of what is already available in the market dealing with the same problem. Identify and name the types of users involved and how they interact. Document your users, their needs, the problems they are experiencing, their expectations, and the best possible experience they could have in your context.
The Minimum in the MVP implies that you already have the big picture, you have the product vision! A common mistake is when the team ‘easily’ identifies a set of ‘obvious’ use cases as the MVP — without a clear product vision and the big picture.
Check also: How (and why) to write great User Stories
Think as a user
Having the big picture you need to apply a process to identify the smallest subset of functionality that serves a very specific goal. The goal is to satisfy your users. You also want to enable critical user insights and feedback. This feedback can improve the next iteration in your product development plan.
The big picture is the super-set of user stories across all the classes of users identified. It’s a good idea to create a large set of epic stories. Then iterate across all identified users and try to define user stories covering their needs and expected benefit/ gains.
Use a compact format as the one proposed in Scrum: as a <user> I want to <be able to perform an activity> so that <describe the gain>. You don’t have to worry about priorities at this stage. A good idea would be to name each story/ assign a compact title for easier classification and organization.
As soon as you have your product feature super-set, you need to review it to ensure that it defines a product (the P of the MVP). Search for continuity, homogeneity, and complementarity among your user stories.
As a result of this process, you may realize that more than one of the related products are referenced in your backlog and need to be separated. Or you may realize that there are significant gaps that need to be filled.
Again, think as a user. Use empathy to identify interactions, scenarios, and stories that need to be included.
You need to also gather feedback so you can try to validate your stories and the product. You can gather feedback through expert advice, user interviews, formal or informal surveys or public domain references (for instance any reliable public domain statistics that can help you test your assumptions).
Think as an entrepreneur
Thinking as a user is great. You can be creative and forget, for a moment, about real-world challenges such as technical and financial constraints. Your objective is to compile the product super-set of user stories to satisfy — or to even to excite — all the different types of your users.
Now it’s time to think as an entrepreneur. You need to start considering and documenting implementation costs, priorities, strategic advantages, and differentiators against the competition.
You need to estimate the development cost of each user story. You also have to quantify the expected value for the user along with the expected impact on the business: your business.
The logic to identify the right minimum subset can be complex — requiring estimates of all the above at the user-story level. For each user story (or Epic) you need to have at least the following:
1. The complexity/cost associated / feasibility
2. The expected value for the user
Estimates of the above dimensions could be on a numerical or ordinal scale. As soon as you have those estimations you can then rank your stories. Also, plot them in a simple chart against complexity and expected value for the user.
Check also: How to become a great Product Manager
Prioritize, Rank, Set the focus
At this point, you can start prioritizing high-value, low-cost stories over lower value, costly ones. Be aware, though, of those natural, strong dependencies between product features.
In many cases, there are technical or procedural dependencies requiring certain features to be implemented first, although their cost is high and the expected user value low. These dependencies need to be identified and possibly visualized in the user stories mapping.
Having the above for each of the features (user stories) of your product allows you to define your MVP as:
“… the minimum set of features (stories) ensuring a good-enough product experience driving increased user engagement that can secure the next product development cycle”
You can sort your entire product backlog by the dependency sequence (start with foundation). Then by the value for the user in descending order. Then by complexity and feasibility in ascending.
You can also combine budget constraints, team’s velocity, and go-to-market strategy to make it ‘easy’ to identify the red-line of your to-be-proved Viable MP.
In reality, though, this will be just a draft definition of an MVP. What is needed in an ideal scenario, is feedback and validation of the features by real users via prototyping, focus groups, market research, competition analysis, and related methods.
The more input from real users, the more confident you can be that your product concept has all it takes to become Viable (which also assumes a great execution/ implementation/ launch).
Thanks for reading!