Following up on my lecture for University 20.35: what an MVP is and why you need one

What an MVP is

Let’s start with a question that you answer first, and only then I’ll tell you what I think about it. How do you understand what an MVP is?

Answers:

• The simplest solution that lets you organize business processes and solve the problem;
• A minimum viable product;
• An initial product that already has functionality and value and can be tested on a user;
• Something that, already at the development stage, helps you find out what exactly users want;
• A prototype that lets you understand whether your idea works or not, so that an investor can test it.

Great. On the whole that’s all close to my own understanding. To answer the question of what an MVP is at a deeper level, let’s first sort out what a business is. It’s all very simple.

A business is a structure that changes people’s behavior in such a way that someone pays for that change. Most often the people whose behavior we help to change are the ones who pay for that change. So when we’re doing business (in particular at a very early stage), we have to find out: are we capable of changing people’s behavior in such a way that they’ll pay for it?

An MVP is a machine tool for testing hypotheses. In our case — experiments in changing people’s behavior.

But besides the “machine tool for experiments” we need three more things:

• The hypothesis we’re testing;
• The people whose behavior we’re going to try to change;
• A way to measure the result.

The simplest formula for a hypothesis: “If we do [this], we’ll manage to change the behavior of [these people] [in this way], thanks to [these qualities] of the product”.

Let’s go straight to a concrete case: right now we’re all taking part in a video call, so we definitely have shared experience we can work something out from. Let’s say we want to create a product that’s better than Zoom for events like our webinar.

Now let’s prepare the framing of the hypothesis.

1. We determine whose behavior we want to change and can change with the new product

Let’s list the audiences, using our webinar as the example:

• All users (the broadest possible frame),
• The speaker,
• The target listeners,
• Accidental listeners (the ones who showed up without an invitation),
• The organizers.

2. We formulate the task

What we’re going to practice is formulating an MVP. Let’s start with how NOT to do it.

A definition along the lines of “it will work on the following platforms, you’ll be able to make one-on-one calls” is not what interests us right now, because from that definition it isn’t clear which people will change their behavior, how, and for the sake of what.

Don’t try to describe the minimum functionality in terms of features. Those details will come in handy for the developer, later. But that isn’t what we as entrepreneurs need to understand when we’re framing a hypothesis for testing.

Here’s an example of the wrong formulation.

Situation: “We don’t like that ‘trolls’ turn up at the webinar and try to derail the event”.

Framing: “If we want to change the listeners’ behavior, we could, for example, build a protected entrance: by password, by the organizer’s address book, or with face recognition, so that we only let in people approved in advance”.

At the end of that we won’t find out whether our users started behaving differently. At best we’ll manage to check whether our programmers are capable of building what we described to them.

If you set the task for an experiment cycle in terms of “build this particular function”, then at the end you’ll get an answer in the same terms: “the function has been built” (or not). That will let you understand the cost and the speed of development (to some degree), but it won’t answer the question of whether the business works.

3. We formulate the same thing in terms of changing people’s behavior

Let’s think about how we would want to change the behavior of the listeners. For example, we see: users don’t turn their cameras on. Why? Because something is getting in their way. And almost always what’s getting in their way isn’t (only) the technology. If the technical capability to turn the camera on is there, then there are other obstacles: people aren’t used to it, they don’t understand why it’s needed, they don’t understand what’s wanted from them.

4. We remove the barrier

A barrier is an obstacle that prevents people’s behavior from changing. If we understand what it consists of, then the entrepreneur’s work 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 go back to the example with the “trolls”. How do we want to change their behavior? Make it so that they aren’t there. That’s the answer to the question of how their behavior should change: they shouldn’t come.

After that the means come into it — for example, we could hand out a login and password to all the participants we need in advance. But that creates a different problem: the work gets more complicated, the barrier to entry goes up for the target participants. And here we realize that a change in the behavior of one group must not lead to negative changes in the behavior of another group. It must not turn out that our solution results in fewer target users coming.

So: we need to change the behavior of one particular group of people (make it so the “trolls” don’t come), but NOT change the behavior of another group of people (make it so target users don’t start coming less).

Why discuss the behavior change of every group of people in such detail? Notice that we haven’t yet thought about what the software has to do. We were talking about people: about different groups and about how to change their behavior. First you have to determine how to change people’s behavior (not how the technology works!), and only then — by what means. Then, when we come to choose the organizational and technical means, we’ll have a criterion — an answer to the question of whether this is a good solution. You have to start with narrow groups, because it’s easier to spot the specifics on them. And only afterwards can you generalize them to larger market niches.

Where a business begins

A business begins with a simple question of who pays and what for:

• Who are our clients?
• What change in quality of life will they pay for?

Sometimes it happens that we “work” for one set of people, and a different set pays. In education, for instance — we change the pupils’ behavior, and the parent pays. But in fact that means the parent will pay for changes in their own experience. Which means the analysis has to start from the client’s experience too.

When we show people the first experience, they have to say: “Yes, I’d pay for a change like that”. And ideally — pay right now.

Let me sharpen the thesis. People pay only for the expectation that their experience will change. The expectation of new experience is the only product we ever buy. That means the client has an assumption about what changes they’re going to undergo after the purchase. And after the purchase they’ll compare that expectation with the real experience they get. If we haven’t changed anyone’s behavior, then the person who pays us won’t have any desire to interact with us even one more time, or to tell others about their positive experience.

What is a good MVP?

We’ll consider a solution good if it changes the behavior of a larger share of people more strongly (in the direction we’re after). And out of solutions like that we’ll pick the cheapest.

In a bit more detail. A good MVP:

• Tests a larger number of hypotheses per unit of time;
• Gives the entrepreneur deeper insights while they’re observing;
• Gives us results we’re confident in (the outcome of the experiment is unambiguous, we can separate facts from opinions and judgements);
• Costs as few resources and as little time as possible.

Attention: an MVP is not the embryo of a technical system. An MVP is made to be thrown away. It exists so that you can extract experience from it, not so that you can lay its technical solution into the foundation of a future platform.

What can you assemble an MVP out of? There are several options:

• Out of people and certain promises that some people make to others;
• Out of people who provide the service by hand (sometimes from the outside this looks like automation);
• Out of other services that already change people’s behavior the way we need;
• Out of program code we wrote for the task. Usually this is the most expensive option. It’s worth choosing only if there’s no way at all to test the hypothesis by the previous methods.

How do you know an MVP is working? People’s behavior changes! For example, we understand that the MVP is done when we’ve prepared, we came to the client, the client started behaving differently than before, and they’re ready to pay for it.

Which hypotheses are we testing?

In the cycle of interaction with the client we have several consecutive hypotheses.

The first hypothesis: “will people pay us for the promise of [this particular experience]?”. We change people’s behavior at the moment when we sell the product. The result — people respond and pay money.

The second: “how will clients feel about the experience that happened to them during the purchase?” We build a process in which their behavior changes (and they notice it). The result — people’s lives change the way we promised.

The third: “will we be able to do something in our business at a lower cost than others?”. We test the hypothesis that we can change their lives more cheaply than other solutions on the market.

Did it work? Then we’ve made an innovation. Innovation in business is always a way of doing something everyone needs at a lower cost.

To test these hypotheses we need different qualities of the product and a different framing for the experiment. Let’s go back to preparing it.

Let’s start by making a promise

The fake landing page tactic — all you have is a landing page (a one-page site) where we describe our product, while the product itself doesn’t exist yet. There may be nothing at all behind that page; the important thing is that there’s a place where we make a promise and after that we collect the contacts of people who are ready to pay for such a promise.

That page plus a flow of people, plus the formulation of the hypothesis and an answer to the question of what we’re measuring — that’s an MVP for testing the hypothesis “are people ready to pay for the promise of this change in their experience?”. People who see that page have to want to pay. What do we do with that next?

If we can provide the service right now — we take the money and provide it without any automation whatsoever. If we can’t — we simply talk to those people over Skype, honestly admit to them that we’re testing the service and that their opinion is valuable to us. Either way we’ll understand whether people are ready to pay for it and whether we can attract them with our promise.

When we start deciding which qualities of the product we want to use to change the behavior of the client/speaker, a question comes up: and who’s footing the bill for the party? In our example with the seminar, the ones who might pay are:

• All users,
• Only the listeners,
• Only the speakers,
• Only the organizers.

Who is our client? Who do we take money from? Whose life do we have to change?

Let’s work through the example of the organizers. If we’re creating a product that the organizers pay for, that means first and foremost we’re changing the organizers’ behavior.

What might the organizers pay for? For lowering their costs. In that case we offer them:

• Spending less time assembling a group of participants,
• Attracting participants more cheaply than before,
• Moderating with a less qualified employee,
• Not being distracted by fixing technical faults.

Organizers might also pay for increasing their revenue. In that case we offer them:

• Selling to a larger number of clients,
• Taking more money from a single client,
• Getting clients to pay a larger number of times.

Let’s try making the organizer a promise.

For example: “You pay us 5 thousand a month, and you won’t be distracted by fixing technical faults”.

The customer will demand proof and an answer to the question “why should I believe that I really will stop being distracted?”. We have to provide real arguments that the customer’s life will get easier. That most likely means we’ll have to know the answer to the question of how our solution works (in terms of changing people’s behavior) before we start building it, already at the promise stage.

Let’s work out whether we can deliver the value we promised

The second version of the MVP: people have entered into interaction with us, we promised them their life would change. After that experience they’ll want either to change it again, or to tell other people about it.

Let’s keep working through our case: we’re creating a service thanks to which the customer will be able to not get distracted by fixing technical faults. What’s the easiest way to deliver the value?

For example, we hire students, train them, and they do the technical work for the organizers. The unpleasant part: at the first stage we’re paying them more than we earn. But we’re going to work with this solution in two stages. First we’ll find out whether the client is ready to pay for the change in their experience. And only if the answer is yes will we come up with a way to lower the cost so that a margin appears.

So, we’ve understood:

• Whose behavior we want to change,
• Which people will pay for it,
• How we’re going to change their behavior,
• How to do it more cheaply.

Let’s recall the formula: “If we do this, we’ll manage to change the behavior of these people in this way, thanks to these qualities of the product”.

Let’s substitute the new values: “If we hire a large number of cheap moderators, then we’ll save conference organizers time thanks to there being no technical faults. And the conference organizers will pay us for that”.

We have a ready formula for an MVP, and at the same time we haven’t spent a single rouble: not on copywriters, not on designers, not on programmers. We simply formed the idea and went to the client with the question: “Will you pay us for this?”.

Can this be considered an MVP? By the classic definition — no. We haven’t created any functionality. And if you take an MVP to be minimum functionality, then we haven’t done anything yet.

But if you take an MVP to be a machine tool for testing hypotheses about value delivery, then this is a good (cheap, insight-generating, letting you interact with the audience) machine tool for experiments.

When we understand that people respond to our spoken offer, we’ll go and start testing whether that pitch works on the internet, without personal contact. If it works — we’ll try to deliver the experience, assembling it out of off-the-shelf services and pairs of hands. If we run up against cost — we’ll start programming. And that’s where we’ll finally need a task framed in terms of functionality — that’s the answer to the question “how do we save money on delivering the experience”.

But that’s another story )

And finally. Useful services for building a prototype:

• Figma (what interface designers are moving to from Sketch or Photoshop) — a design tool you can use to design interfaces. You can assemble an entire interface in it, it works in the browser, it’s very useful in web development.
• Tilda, Bitrix24, Wix — let you make a site without programming skills, don’t require any special knowledge to create a product page.

And if you’re thinking about developing an MVP for your own service, you can always write to us. We’ll help!