Experience shows that early product releases can be a smart move when doing innovation. What used to be called betas or even alphas is nowadays often referred to as an MVP (Minimum Viable Product).

In Lean Startup terminology an MVP is the minimum set of features that address the most important problems you are trying to solve for your customers (Ash Maurya, Running Lean). The motivation for building an MVP is to verify any assumptions you might have about customers’ problems and your ability to solve them.

A lot of people are however substituting the word “beta” with “MVP” these days, although there are some significant differences.

First of all, the MVP is not necessarily a technical solution. You might build an MVP without using any software at all. Nor is it the least amount of features it takes not to be embarrassed, to get some attention, or to make a sale.

Still, MVP as a term is often used to describe the above: A Beta release. Its driver is often everything but the intended purpose of an MVP, which is to learn about customers and demand. Instead it’s used as an alibi to show progress, get attention and feel more secure.

I think one part of the explanation for this misconception is that the MVP term, when read out of context, lacks the who. Who are we trying to help, and what impact are we trying to make?

By its minimal nature, an MVP will never cover the needs of a mass market, not even multiple groups of early adopters. Hence, a key discriminator between the beta and the MVP is a clear notion of a customer segment: A set of people who experience the problem you are trying to solve to a degree that makes them interested in buying a minimal, immature, change-prone product.

Gojko Adzic has a technique called impact mapping, where you start your software design process by asking what change you want to cause in the behaviour of your users or customers. This could be a powerful tool when designing an MVP. Let’s say I’m in the gaming industry and I want to make an iPad game for kids from 2-4 years. It obviously needs to be extremely simple to start and use. Why would I want to make this game, and how will customers benefit from it? As many parents experience, the iPad can be an excellent baby sitter (unless you overuse it, of course). Hence, a change I want to trigger is making parents sleep longer in the weekends, because their kid is playing this game.

In this idea, there are a number of assumptions. Kids at this age are able to find the iPad and start a game on their own. The particular game I’m thinking about will be entertaining to them. Parents want their kid to play for an hour or so every Sunday morning. Etc. There are many ways to design an MVP to start verifying such assumptions (some of the assumptions could even be verified without any MVP at all).

Flipped around however, I might say that I want to take a position in the educational gaming market, gain som attention with new innovative computer games for youngsters, and to get there I of course want to take advantage of some other services I already have. In this situation, I might think that my first release must be of some size in order to appear professional, to be worth the attention, not being slaughtered in the press, etc. My release should have an offer for kids in a wider age range and it should be bundled with my educational software for parents following up homework and so on. My driver here, which is basically anything but the learning part, will almost certainly make me design an MVP which is far from minimal, but still cannot be stripped down further once everybody had their say.

This is where the change part comes into play. To whom are we trying to make a change? In the first example, it’s the parents, who should be able to sleep longer on Sundays. That’s something we could measure fairly easy with a limited amount of first users.

In the latter example, we neither have a notion of customer segment (pro-tech, sleepless parents) nor the impact we want to make (an hour more sleep every week). Of course if the former example indeed became successful, the MVP would most likely grow in features and gradually target more needs and more segments. It would go from MVP to a product in growth.

The difference is how the development teams focus their work. Focusing on a single change for a limited segment of users, and building from there will have a much higher probability of really helping someone, compared to going out wide and generic, usually motivated by fighting of fierce competition, taking maximum advantage of resources and other pre-mature economy of scale factors.

So, if you’re currently building an MVP, I would like to encourage asking some randomly chosen team members the following: Who will experience a change because of what we are making? If you don’t hear a consistent answer, you might want to reiterate your MVP strategy.

Maybe it’s just internal communication. Most likely, however, you’re not minimal enough. You don’t have a minimum viable product, and you probably don’t have a minimum market segment and a clear notion of how to impact it.

Would the intention of the MVP become more clear if we called it Minimum Viable Change?