What’s the point of a Prototype?

The Geovation Accelerator Programme has many aims. My job as a Senior Innovation Engineer at Geovation is, among other things, to help the programme cohort members to unlock the investment they need to become independent. This often means helping them build the first versions of their product to help potential investors visualise the solution.

Notice that I said ‘first version’, not ‘first working version’. It doesn’t have to work to do the job. 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 MVP or Minimum Viable Product. This is usually not a good thing! The issue is that whenever the ideas for the MVP are discussed it quickly becomes clear that they are almost never minimal and rarely viable.

The first reason they are almost never minimal is that most people spend their lives building to build, not building to learn and MVPs should be optimised for learning. This means that so-called MVPs often contain a multitude if things that ‘just need to be there before we can get started’ most of which are, in fact, completely unnecessary at this stage. The second reason is that most entrepreneurs are reaching for perfection, and perfection is the enemy of the MVP. The drive for perfection often raises the bar on what minimum means to a level approaching absurdity.

As for viability, what pretty much every startup owner fails to realise is that it is the customer who decides what is viable, not the entrepreneur.

It is for this reason that I never use the term MVP, and I will not discuss the creation of such a thing. 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 explain it in four stages:

1. Fakeable - 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. Loveable - 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.

Geovation focusses on stages 1 and 2, the fakeable and the testable. 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 aim of these experimental stages is to learn as fast as possible, 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 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?

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.

In future blog posts I will discuss identifying assumptions and creating hypotheses but for now please take away the message that we want to learn, not simply to build.

Before I go, it might be useful to dispel some common ideas about what prototypes are not for.

Prototypes are not intended to:

• Create your full 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 test if you don’t have a clear idea of what you’re testing for and whether the test has been successful or not?

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?