A strategy for moving from a concept to a proper MVP definition
The Minimum Viable Product, although properly defined, means different things to different people. In fact, it is one of the most misused terms in the technology domain: it is often poorly used 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
From a concept to a properly defined MVP
Assuming you have this great idea, a concept you believe is good enough to further analyse as a product. You need a method to start defining the product and more specifically the subset of the product features that can serve your objectives with the minimum cost and risk. Key stages in this process are:
Identify your users
Set the context — think of the problem, the situation, the opportunity; think of what is already available in the market dealing with the same problem; identify and name the users involve 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.
Think as a user (for each class of users identified)
The Minimum in the MVP implies that you have the big picture, you have the product vision! A common mistake is when a team identifies a set of use cases and, without a product vision and the big picture, they name the set as MVP.
Having the big picture, the product vision, you need to apply a process to identify the smallest subset of functionality that serves a very specific goal: to satisfy your users while enabling critical user insights and feedback which can significantly improve the next iteration in your product development plan.
This big picture can be expressed as the super-set of user stories across all the classes of users identified. It’s a good idea to create a large set of such stories: 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 — the big picture — you need to review it to ensure that it really 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 related products are referenced in your backlog and need to be separated; or, 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/ try to validate your stories and the product through expert advice, user interviews, formal or informal surveys or public domain references (for instance any reliable public domain statistics that can in-validate 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: you have compiled your product super-set of user stories trying to satisfy -or 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 competition. You need to quickly estimate the implementation cost of each user story and also 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, ordinal or categorical scale. As soon as you have those estimations you can then rank your stories or plot them in a simple chart against complexity and expected value for the user.
At this point you can start prioritising 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 and/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: the minimum set of features (stories) ensuring a good-enough product experience resulting to increased user engagement that can secure the next product development cycle. You can sort your entire product backlog by dependency sequence (start with foundation), then by the value for the user in descending order and then by complexity/feasibility in ascending. Also combining budget constraints, team’s velocity and go-to-market strategy makes it ‘easy’ to identify the red-line of your to-be-proved Viable MP.
The above can be easily applied on a well understood concept and documented in the form of a properly structured product backlog. 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/ stories 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).