Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
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
A strategy for defining a proper, real MVP
Assuming you have this great ideaâââa concept you believe is good enough to further analyze 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 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.
Think as a user (for each class of users identified)
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: the data-driven corporation
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.
The 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 epic 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 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 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).
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 competition.
You need to estimate the development cost of each user story and also 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 and also 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 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 dependency sequence (start with foundation), then by the value for the user in descending order and then by complexity and feasibility in ascending.
You can also combine 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 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).
More on Artificial Intelligence
- Artificial Intelligence: the impact on employment and the workforce
- Artificial Intelligence: A non-technical introductionâââdefinition, applications and impact
- Data Quality in the era of A.I.
- Whatâs next on AI, AR, VR, NUI, Robotics, Data & Visualization, Blockchain
- How AI will Impact Transportation
Interested in novel ideas and thoughts on innovation? Follow The Innovation Machine
George Krasadakis | Professional Profile | LinkedIn
How to define a Minimum Viable Product was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.