Minimum viable, not minimum functional.

The Minimum Viable Product (MVP) is a concept made famous by Eric Reis’ book The Lean Startup which has become somewhat of a startup bible. The idea is a simple one yet commonly misunderstood or overly simplified as a poor performing early version of what you hope to sell. An untested early software (alpha or beta) release where the customers discover all the bugs for you is a common misconception of an MVP. The result is predictably disappointing and often disregarded as not being a true reflection of your ide'a’s potential due to the obvious flaws in what was shown.

This is not an MVP, this is just bad delivery of your finished idea.

An MVP is a test, an experiment, a way of finding out if your market research guesses were right. A way of turning that dodgy data you found into hard facts, relevant and tailored to your business model canvas. It should be made as soon as possible, at the start of your process, not after you’ve spent months or years developing a solution.

The important word is “viable”, you’re trying to test something, to conduct an experiment. In order for the results of that experiment to be valid, believable and to steer your development. Whatever you’re doing needs to work in some way, or at least appear to, enough to get interesting results. But it doesn’t have to work like you intend it to.

The goal is to test the idea, not to make it cheaply or rush its release.

Whilst the term MVP is a new one, the concept is not. A famous example of an MVP comes from IBM in the 1980s. The story goes something like this…

IBM were keen to develop a new software product for busy working people who would spend much of their time dictating messages to typists who would type them out. It was the early days of computing and secretaries and typists did the bulk of data entry because most people could still not use a keyboard or typewriter very well.

So IBM saw a big opportunity to build some Speech-to-Text software, removing the need for a typist altogether.

Now this was the early days of computing remember, so to build such a thing would have been an enormous undertaking. The market seemed obvious, big time savings, lower employment costs, wealthy customer base, tick tick tick. But IBM needed a way to validate if this market was genuine before investing a huge amount in the cutting edge R&D needed to create such a thing.

So they faked it.

Customers were invited in to use their “new” wonder software. They were given a microphone and sat in front of a computer and a screen. As they spoke to the microphone the words would appear perfectly on the screen in front of them, regardless of accent or other quirks in their speech. Magic.

The customers were understandably blown away, this was like playing with the future of technology. But after a while they didn’t like it. The process was tiring and hard work. Mistakes were hard to correct and the potential of the idea was deemed to not be worth the R&D effort. The results were clear, it was not going to be the big success they thought it might be.

So how did they achieve this miracle of R&D in a matter of days?

A little bit of trickery, instead of the microphone being connected to the computer in front of them, it was in fact linked to the headphones of a professional typist in the next room. As the customer spoke, they would type the words onto the screen.

The illusion was perfect.

Quick, believable, valid. No one could argue with the results of this experiment. Here was something that would function far better than the computer software ever could and still customers didn’t want it.