Notes from the lecture at the University 20.35: What is MVP and why you need it?
As promised earlier this week, we have published an article that we wrote based on the lecture by our CEO Alexey Kulakov for students of an intensive online course at the University 20.35.
In this article, you will learn what exactly 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 behaviour, how to overcome them using MVP, and how to understand that your MVP works.
Have a read!
What is MVP
Let's start with a question that you will answer first, and then I'll tell you what I think about it. How do you understand what an MVP is?
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 at the development stage what exactly users want;
a prototype that will allow you to understand whether your idea is working or not, so that the investor can test it.
Great. In general, this is all close to my understanding. To answer the question of what an MVP is in more detail, let's first find out what business is. Everything is very simple.
Business is a structure that changes the behaviour of people in such a way that someone pays for this change. Most often, those people whose behaviour we are helping to change are paying 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 behaviour of people so that they pay for it?
MVP is a tool for testing hypotheses. In our case – experiments on changing people's behaviour.
But besides the “tool for experiments” we need three more things:
the hypothesis that we are testing;
people whose behaviour we are trying to change;
a way to measure the result.
The simplest hypothesis formula:
“If we do [this], we can change the behaviour of [these people] [this way], thanks to [these qualities] of the product.”
Let’s analyse this on a particular case: we are all participating in a Zoom meeting right now, so we definitely have a common experience with which we can understand something. Let's say we want to create a product that is better than Zoom for events like our webinar.
Now let's prepare the hypothesis.
1. Determine the behaviour of which people we want and can change using a new product
Let's list the audience using our webinar as an example:
all users (the widest frame),
random attendees (who came without an invitation),
2. Formulate the task
We will train in formulating 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 what interests us now, because from this definition it is not clear what people, how, and why will change their behaviour.
No need to try to describe minimal functionality in terms of features. These details will come in handy for the developer, later. But this is not what we, as entrepreneurs, need to understand when formulating the hypothesis for testing.
Here is an example of an incorrect formulation.
Situation: “We don’t like the "trolls" coming to the webinar trying to disrupt the event.”
Statement: “If we want to change the behaviour 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 do what we described to them.
If you give the task for the experiment in terms of “develop such 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 changing people's behaviour
Let's think about how we would like to change the behaviour of attendees? For example, we see: participants don't turn on cameras. Why? Because 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 behaviour. 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 behaviour? To make sure that they are not there. This is the answer to the question of how their behaviour should change: they shouldn't come.
Then the means begin – 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 behaviour of one group shouldn't lead to negative changes in the behaviour of another group.
Our decision shouldn't lead to the fact that less targeted users will be coming.
So, we need to change the behaviour of a particular group of people (to make sure that the “trolls” don't come), but NOT to change the behaviour of another group of people (to make sure that the number of target users hasn't decreased).
Why do we need to discuss the change in the behaviour of each group of people 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 behaviour. First, we need to determine how to change the behaviour of people (not the work of technology!), And then – with what means. Then, when we choose organisational and technical means, we will have a criterion – the answer to the question of whether this is a good solution. You need to start with narrow groups because it’s easier to notice the specifics on them. And only then they can be generalised to larger market niches.
What does a business begin with?
A business begins with a simple question: who pays for what:
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 behaviour of students, and their parents pay for that. But, in fact, this means that the parent will pay for changes in their experience. This means that 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." And ideally, pay right now.
I will sharpen the thesis. 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 will receive.
If we haven't changed anyone’s behaviour, 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 is a good MVP?
We consider a good MVP to be a solution that changes the behaviour of a larger proportion of people to a greater extent (in a targeted way). And from such solutions, we will choose the cheapest.
More detailed. A good MVP:
tests more hypotheses per unit of time;
during the observation gives the entrepreneur deeper insights;
gives us results that we can trust (the result of the experiment is unambiguous, we can separate the facts from opinions and assessments);
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. It is needed in order to extract experience from it, and not to lay a technical solution in the foundation of the future platform.
What can you build MVP from? There are several options:
from people and some promises that some 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 behaviour 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? People's behaviour is changing! For example, we understand that MVP is done, when we prepared, we came 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 be paid for the promise [of such an experience]?". We change people's behaviour 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 behaviour 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 than others?" We test the hypothesis that we can change their lives cheaper than other market solutions.
Did it work? We have done 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 preparing it.
Let's start by making a promise
The tactics of a fake landing page – there is only 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 plus the flow of people, plus the formulation of the hypothesis and the answer to the question of what we measure – MVP to test 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 a 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 their opinion is valuable 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.
When we start to think, by what qualities of the product we want to change the behaviour of the client/speaker, the question arises: at whose expense? In our example with the seminar, the people who pay could be:
Who is our client? Who do we accept money from? Whose life should we change?
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 behaviour 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 organiser 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 and an answer to the question "why should I believe that I will stop being distracted?" We need to provide the real reasons that the life of the customer will become easier. This most likely means that we will need to know the answer to the question of how our solution (for changing people's behaviour) works before we begin to make it, right at the promise stage.
Let’s understand if we can give the value we promised them?
The second version of MVP: people entered into interaction with us, 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 thanks to which the client won't be distracted by troubleshooting 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 them more than we earn.
But we will work with this solution in two stages. First, we understand whether the client is willing to pay for changing their experience. And only if so, will we come up with a way to reduce production costs so that margins arise.
So, we understood:
the behaviour of which people we want to change,
what kind of people will pay for it,
how we will change their behaviour,
how to do it cheaper.
Let's recall the formula: “If we do this, we can change the behaviour 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 MVP formula, and yet we haven't spent a single ruble either on copywriters, or on designers, or programmers. We simply formed an idea and went to the client with the question: "Will you pay us 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.
But 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."
But that is another story )
And, finally, some useful services for creating a prototype:
Figma (what interface designers are switching to from Sketch or Photoshop) is a design tool where you can design interfaces. You can assemble the entire interface in it, it works in the browser, and is very useful in web development.
Tilda, Bitrix24, Wix – allow you to make a site without programming skills and don't require special knowledge to create a product page.
And if you are thinking about developing an MVP for your service, you can always get in touch with us. We are happy to help!