You will learn what MVP is, why you need it, how to formulate it right, and why we consider it primarily a hypothesis testing tool. You will also find out how to identify barriers that prevent us from changing user behavior, how to overcome them using MVP, and how to understand that your MVP works.
Enjoy!
What is MVP
How do you understand what an MVP is?
Possible answers:
- the simplest solution to organise business processes and solve a problem;
- a minimum viable product;
- an initial product that already has functionality and values and which can be tested on the user;
- something that will help to find out what users want at the development stage;
- a prototype that will allow you to understand whether your idea is working or not, so that the investor can test it.
To answer the question of what an MVP is in more detail, let's first find out what business is. It's pretty simple.
Business is a structure that changes people's behavior in such a way that someone wants to pay for this change. Therefore, when we do business (in particular, at a very early stage), we must find out: are we able to change the behavior of people so that they pay for it?
MVP is a tool for testing hypotheses. In our case – experiments on changing people's behavior.
But besides the “tool for experiments” we need three more things:
- the hypothesis that we are testing;
- people whose behavior we are trying to change;
- a way to measure the result.
The simplest hypothesis formula:
“If we do [this], we can change the behavior of [these people] [this way], thanks to [these qualities] of the product.”
Let’s analyse this on a particular case: let's say, we're on a Zoom meeting right now, so we definitely have a common experience. Our goal is to create a product that is better than Zoom for events like our webinar.
Now let's prepare the hypothesis.
1. Describe the people's behavior that we want to change using a new product
Let's list the audience using our webinar as an example:
- all users,
- a speaker,
- target attendees,
- random attendees (who came without an invitation),
- organisers.
2. Formulate the task
Let's practice wording an MVP. Let's start with how NOT to do it.
A definition like “it will work on the following platforms, you can make one-on-one calls” is not relevant. It is not clear who the audience is, and if our product is going to change their behavior.
Also, there's no need to try to describe minimal functionality in terms of features. These details will come in handy for the developer team later. As entrepreneurs, we don't need to understand the functionality when we word the the hypothesis for testing.
Here is an example of an incorrect wording.
Situation: “We don’t like the "trolls" coming to the webinar trying to disrupt the event.”
Statement: “If we want to change the behavior of visitors, we can, for example, develop a secure login with a password or with face recognition, to allow only pre-approved attendees.”
As a result, we won’t know if our users began to behave differently. In the best case, we will be able to check whether our programmers can execute our idea.
If you give the task for the experiment in terms of “develop a feature”, then, in the end, you will get the answer in the same terms: “the feature is developed” (or not). This will allow you to understand the cost and speed of development (to some extent), but will not answer the question of whether the business is working.
3. Formulate the same thing in terms of a change in people's behavior
Let's think about how we would like to change the behavior of attendees? For example, we see that participants don't turn on their cameras. Why not? Something prevents them from doing this. And almost always, what prevents them is not (only) technology. If the technical capabilities allow them to turn on the camera, then there are other obstacles: people are not used to it, they don’t understand why this is necessary, they don’t understand what we want from them.
4. Eliminate the barrier
A barrier is an obstacle that prevents us from changing people's behavior. If we understand what it is, then the entrepreneur’s job of finding a niche for the business is half done. Another definition of an MVP is a way to break such a barrier.
Let's get back to the "trolls" example. How do we want to change their behavior? To make sure that they are not there. This is the answer to the question of how their behavior should change: they shouldn't come.
Then we think of the means to achieve this – for example, you can pre-distribute the login and password to all the necessary participants. But then another problem will come from this: the complication of work, increasing the barrier to entry for target participants. And here we understand that a change in the behavior of one group shouldn't lead to negative changes in the behaviour of another group.
So, we need to change the behavior of a particular group of people (to make sure that the “trolls” don't come), without changing the behavior of another group (to make sure that this change does not influence the target audience).
Why do we discuss the behavior change of each audience group in such detail? Note that we didn't think yet what the program should do. We talked about people: about different groups and how to change their behavior. First, we need to determine how to change the behavior of people, and then – the ways to do ut. Then, when we discuss organisational and technical means, we will have to decide whether this is a good solution. You need to start with narrow groups because it’s easier to note their specifics. Only then they can be generalised to larger market niches.
What does a business begin with?
A business begins with a few simple questions:
- who are our clients?
- for what change in the quality of their life will they pay?
Sometimes it happens that we “work” for some people, while others pay for it. For example, in education we change the behavior of students, and their parents pay for that. But, in fact, this means that the parent will pay for changes in their experience. Then, you need to start the analysis with the client's experience.
When we show people the first experience, they should say: "Yes, I would pay for such a change."
Let's look closer at this idea: people pay only for the expectation that their experience will change. The expectation of a new experience is the only product we buy. This means that the customer has an assumption of what changes they will experience after the purchase. And after the purchase, they compare their expectations with the real experience that they receive.
If we haven't changed anyone’s behavior, then the person who pays us will not have the desire to interact with us any longer or tell others about their positive experiences.
What makes a good MVP?
We consider a good MVP to be a solution that changes the behavior of a larger proportion of people to a greater extent. We will choose the cheapest solution out of all our ideas.
A good MVP:
- tests more hypotheses per unit of time;
- gives the entrepreneur deeper insights;
- gives us reliable results (they are unambiguous and non-personal);
- costs as little resources and time as possible.
Caution: MVP is not the beginning of a technical system. MVP is done to be thrown away. We use it to extract experience from it; an MVP is not supposed to be the basis of the future platform.
What can you build MVP from? There are several options:
- from people and some promises people give to others;
- from people who provide the service manually (sometimes from the outside it looks like automation);
- from other services that already change the behavior of people the way we need it;
- from the program code that we wrote for the task. This is usually the most expensive option. It should only be chosen if the hypothesis cannot be verified by previous methods.
How to understand that MVP works? You witness that people's behavior is changing! For example, we understand that MVP is done, when we prepared, delivered it to the client, the client began to behave differently, and they are ready to pay for it.
What hypotheses do we test?
In the cycle of interaction with the client, we have several consecutive hypotheses.
The first hypothesis: "will we get paid if we promise [this experience]?". We change people's behavior when we sell a product. The result – people respond and pay money.
The second: “how will customers react to the experience that happened to them during the purchase?” We are building a process in which their behavior changes (and they notice it). The result – people's lives are changing as we promised.
The third: "can we do something in our business at a lower cost compared to other businessses?" We test the hypothesis that we can change their lives cheaper than other market solutions.
If it worked, then we created an innovation. Innovation in business is always a way to do something that everyone needs at a lower cost.
To test these hypotheses, we need different product qualities and different setups for an experiment. Let's get back to creating it.
First, we make a promise
The tactics of a fake landing page – we create a landing page (one-page site) where we talk about our product, while the product itself doesn't exist yet. There may not be anything else behind this page. The main thing is that there is a place where we make a promise and after that, we get the contacts of people who are ready to pay for such a promise.
This page, together with its visitors, is an MVP that tests the hypothesis "are people ready to pay for the promise of such a change in their experience?" People who have seen this page should be willing to pay. What to do next?
If we can provide our service right now, we take the money and provide it without any automation. If we can’t, we just talk to these people on Skype, honestly tell them that we are testing the service and how much their opinion matters to us. In any case, we will understand whether people are willing to pay for it and whether we can attract them with our promise.
Then we need to figure out who our client is. Who do we accept money from? Whose life should we change? In our example with the seminar, the people who pay could be:
- all users,
- only attendees,
- only speakers,
- only organisers.
Let's analyse this on the example of organisers. If we create a product that the organisers pay for, then, first of all, we change the behavior of the organisers.
What can the organisers pay for? For cost reduction. Then we offer them to:
- spend less time gathering a group of participants,
- attract participants cheaper than before,
- moderate by a less qualified employee,
- not be distracted by technical problems.
The organisers can also pay for the increase in profitability. Then we offer them to:
- sell to more customers,
- take more money from one client,
- get customers to pay more times.
Let's try to give the organisers a promise.
For example: "You pay us 5 thousand a month, and you won't be distracted by troubleshooting technical problems.”
The client will require evidence: "why should I believe this?" We need to provide the real proof that the customer's life will get easier. Most likely, this means that we will need to know the answer to the question of how our solution (for changing people's behavior) works before we begin to make it, right at the promise stage.
We make sure we can give the value we promised
The second version of MVP: people entered into interaction with us, and we promised them that their life will change. After this experience, they will either want to change it again or tell other people about it.
We continue to analyse our case: we create a service that helps the client avoid technical problems. What is the easiest way to provide value?
For example, we hire students, train them, and they do the technical work for the organisers. Problem: at the first stage, we pay more than we earn.
We will work around this in two stages. First, we understand whether the client is willing to pay for changing their experience. Only in this case, will we come up with a way to reduce production costs so that margins rise.
So, we understood:
- the behavior of the people we want to change,
- what kind of people will pay for it,
- how we will change their behavior,
- how to do it cheaper.
Let's recall the formula: “If we do this, we can change the behavior of these people in this way, thanks to these qualities of the product.”
Now let's substitute new values: “If we hire a large number of cheap moderators, we will save the time of the conference organisers because there will be no technical problems. And the conference organisers will pay us for this. ”
We have a ready-made MVP formula, and yet we haven't spent a single euro on copywriters, or on designers, or programmers. We simply created an idea and went to the client with the question: "Would you like to pay for this?”
Can this be considered an MVP?
In the classic sense, no. We haven't created any functionality. And if we assume that MVP is the minimum functionality, then we haven't done anything yet.
However, if you consider that MVP is a tool for testing hypotheses on the delivery of value, then this is a good (cheap, insight-giving, allowing you to interact with the audience) tool for experiments.
When we understand that people respond to our verbal offer, we will begin to test whether this appeal works on the Internet, without personal contact. If it works, we will try to deliver experience by putting it together from ready-made services and working hands. If we run into production costs, we will start programming. And here we need a statement on functionality – this is the answer to the question "how to save money on the delivery of the experience."
... And that's a whole different story.
