Look at your phone and answer the question how many of the apps you use every day originally had all the functionality available? I think very few, or even none. This is what I want to talk about, but from the side of project management and creating a valuable project.
Introduction
How often do you meet projects with an indefinite deadline? The business is constantly dissatisfied, adds another important functionality, and as a result, you still have an unfinished product for the customer. And this is where MVP can help. MVP means Minimum Viable Product. The minimum version/value of a product that can be launched for the customer.
Why do we actually need an MVP and why is it so important?
We often develop a product with a certain budget and timeframe. Here, setting a version of the MVP will certainly help show your stakeholders what functionality we are able to realize with that budget and time. However, let's look at the other side when we don't have a budget, we don't have a deadline, but we have to remember that every product has to earn for itself at some point and bring enough business value. MVP in such a case will help us indicate when to show the product to the customer, how to advertise the initial product, and with what functionalities.
However, the MVP causes a lot of problems and is not always determined correctly. How not to do it? Check below.
Does the business MVP always meet the technology MVP?
Unfortunately, no. Often business wants functionality and does not think about technology while technology does not think business and this is where the crush arises. We can't be afraid and we need to collide these two environments. But how to do it?
To begin with, let's identify the stakeholders of the project and those of business and technology. Let's organize collaborative workshop/meeting/brainstorming to introduce prioritization and determination of the business value of all targets and those technological and that business.
Everyone should be involved in gathering requirements for the MVP version. Each party needs to logically explain its approach using arguments that are understood by both sides.
It is also best to identify common business goals. Often these goals overlap with technology goals (for example: the business wants to support 100,000 users, technology wants an efficient fast service that will respond in fractions of a second). Any business analysis of the project that shows the client's needs (interviews, focus group analysis, observations, etc.) can be very helpful here.
Remember that often determining the business value of a given functionality will diametrically change its priority on the MVP list.
What if stakeholders don't cooperate?
If there is no cooperation among stakeholders, if there is a lingering belief that the hierarchy of people in the company and the functionality of the CEO are the most important-we need to change this. First of all, make it clear that all the business goals we want in our finished product are on an equal level, no matter from whom they are presented.
We need to make it clear to each stakeholder what their responsibilities are, and how much they should be involved to advance the determination of the MVP.
At the MVP determination workshop everyone is equal everyone's arguments should be heard. I think this is a good time for a facilitator to choose the workshop methods so that everyone feels equal and expresses his or her opinion.
Don't drag out the MVP determination, but don't treat it like something you can't change.
It is good practice to establish "must" values for the MVP, but remember to verify them. When creating a project, we often forget to verify the business values defined as "must" at the beginning of the project. Let's remember that in business everything changes at a very fast pace. At a given moment, one functionality may have the highest priority, and in two or three months it may turn out that its priority according to business analysis has changed to "nice to have". Therefore, let's not close ourselves to the fact that once the MVP is established, it will not be changed in the course.
Summary
Work out an MVP with the client such that it gives satisfactory business value to the project. Control business and technological changes versus your MVP. Don't be afraid to change the MVP, but still stick to the definition that this is the minimum version of the product. Remember your projects are for the users and your focus should be on them. The MVP version will allow you to further explore with your users what business value the new functionality can bring you.
