Why a prototype is more helpful when validating a start-up than an MVP

TL,DR;

I’ve been a professional software developer for over 25 years. In addition to providing business advice to start-ups I also provide technical advice and support. This can mean helping them build the first version(s) of their product, often to help potential investors visualise the concept.

Notice that I said ‘first version’, not ‘first working version’. It doesn’t have to work to do the job. In my humble opinion the first version, or prototype, of your product or service should not be a working version at all. This suggestion routinely causes some consternation and confusion among founders.

So, let me explain.

Call it what you want, just don’t call it an MVP!

One of the few aspects of the Lean Startup methodology that most people have heard of is the so-called Minimum Viable Product or MVP. In my experience, this is not usually a good thing!

The problem is that while people may have heard of an MVP, rarely do they truly understand why it exists. There are as many interpretations of MVP as there are founders of start-ups. Unfortunately, most of these interpretations actually waste time rather than saving it because of a mis-understanding of what the MVP is and what it is for.

If there is one thing I can reliably guarantee about any given MVP it is this: it is nowhere near minimum. Usually, not even in the same Postcode! There are generally a couple of reasons why this is the case:

1. The first reason that MVPs are almost never minimal is that most people spend their lives building to build, not building to learn. We find it very hard to stop ourselves ‘just adding one more thing’ because we’re used to making things complete. Leaving stuff out just doesn’t feel right. An MVP should be optimised for learning. The most effective way to learn is to test one thing at a time. Just adding ‘one more thing’ risks diluting an MVP to the point where it cannot be used to learn anything.
2. The second reason is that most entrepreneurs are reaching for perfection, and perfection is the enemy of the MVP. I’d go even further than that and say that perfection is the enemy of execution. The drive for perfection often raises the bar on what minimum means to a level approaching absurdity.

As for viability, this has so many definitions that it’s hard to concentrate on what we’re measuring the viability of. Are we testing the viability of the business (i.e. whether we can make more money from each customer than it costs to obtain that customer)? Are we testing the viability of the solution (i.e. whether it’s worth paying for)?. Yes, and no to both those statements. Ultimately, this is what our experiment will tell us. However, the viability we’re talking about here is that of the test itself. Confusing, right?

To my mind, the real problem with this term is the final word - Product. Describing our test as a type of product makes us think about it in the wrong way. At the stage when the MVP would be most useful we don’t actually have a product. The MVP is not a product, it’s a way of testing what the actual product should be.

It is for these reasons that I never use the term MVP. I don’t find it helpful.

So what should I call it?

It doesn’t really matter what you call your first efforts as long as you use a term which emphasises intent to learn, not to build. When discussing the evolution of a product I find it useful to break it down into the following four stages:

1. Fake-able - It looks like the real thing but it doesn’t actually work, although it may appear to work. An example of this might be a high-fidelity mockup of a website or an app
2. Testable - It does something, preferably only one thing, and it allows that thing to be tested with real users. Performance may not be optimal and appearance will probably leave something to be desired, but it’s a thing!
3. Usable - OK, now we’re starting to get somewhere. We could probably call this the true MVP stage because it doesn’t do much and we’ve tested that users want it, so it’s both minimal and viable.
4. Lovable - This is close to the product you always wanted to make.

You may insert the word Minimum in front of each of those stages if it makes you feel better, as long as you understand the intent.

I like to focus on stages 1 and 2. I’m going to use the word prototype as a catch-all descriptor for these first stages, since to me it conveys the idea that the intention is to learn and that things may change as a result.

The entire point of these experimental stages is to learn as fast as possible (and fail as quickly as possible, if you’re going to fail at all), from real customers and behaviours, before investing time and resources in any particular course of action. In other words, to prototype.

It is particularly important for startups to avoid actually building anything if they possibly can since to do so costs both time and money, both of which are in short supply for the startup.

What’s the point?

In order to create a successful prototype you need to understand what a prototype is for. So, what has the prototype ever done for us?

A prototype allows us to:

• Act before we have all the answers
• Test and explore an idea
• Sell an idea
• Progress incrementally towards a complex solution
• Avoid wasting time on the wrong things by failing early
• Communicate & collaborate

In order to do any of these things it is absolutely critical that we understand the following before we build it:

• What hypothesis is the prototype is trying to test?
• What does success look like?

It is useful to be clear about what prototypes are not for. Prototypes are not intended to:

• Create your end product faster. That may be a side-effect (if you’re lucky), but it is not the justification.
• Magically and mysteriously remove all the leg-work involved in making robust, secure products. Prototypes point the way but you still have to travel to the destination.
• Be of any use whatsoever unless you are laser-focused on the hypothesis they are trying to validate. How can you learn if you don’t have a clear idea of what you’re testing for and whether the test has been successful or not?

Remember, prototypes are ultimately intended to help us gather the maximum amount of validated learning (based on real customer reactions, not guesses) before we commit ourselves to a particular course of action. In order for this to work effectively we must first identify our assumptions and then create hypotheses to be tested from these assumptions. If we miss this first step we’re pretty much wasting our time and relying on blind luck.

If we don’t define beforehand what success looks like the how do we know if the prototype has helped us? Suppose our prototype appears to have caused a 2% increase in traffic to our website. Is that good? Is it bad? We have no way of knowing unless we decided beforehand that we were aiming for a 1% increase or a 10% increase.

The take-away

In future blog posts I will discuss identifying assumptions and creating hypotheses but for now please take away the message that in order to validate a new business we need to learn, not simply to build.

Calling the thing we use to learn a prototype or experiment helps us concentrate on the learning, not the building. I have argued here that calling it an MVP does just the opposite.

A good prototype can both validate your idea and help you to raise the investment you need to realise that idea. What’s not to like about that?