Why MVPs fail more often than they succeed

This is a mash-up of four concepts, so the best place to start is the beginning.

In Japan, just after World War II when the Lean concept first started, Toyota founder Kiichiro Toyoda saw that the manufacturing process created by Ford was deeply flawed and unable to meet changing customer requirements or worker needs. Toyota then developed Lean based on the following principles:

• Specify the value desired by the customer.
• Identify the value stream for each product providing that value and challenge all of the wasted steps (generally nine out of ten) currently necessary to provide it.
• Make the product flow continuously through the remaining value-added steps.
• Introduce pull between all steps where continuous flow is possible.
• Manage toward perfection so that the number of steps and the amount of time and information needed to serve the customer continually falls.

Fast forward to 2001, when the Agile Manifesto, was released and you see something like this:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over Processes and tools.
• Working software over Comprehensive documentation.
• Customer collaboration over Contract negotiation.
• Responding to change over Following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

You will notice that while Lean speaks about customers, value, and so forth — Agile speaks about better project management practices based on agility. Now, I completely agree that Agile is a better way to break down software projects, but what often happens is that developers are given more power in an agile process to make decisions.

This ties in to Joseph Campbell’s concept of a Monomyth, which is basically the underlying story that society relates to (it’s what Star Wars is based on, and most of our religions — its great if you have not read it). Our current version of this myth is the heroic coder (i.e. Zuckerberg, Sergey & Brinn, Musk, Andreessen etc. ) — who, through technical competence and clear vision negotiates a new path. We have started valuing technical ingenuity over human insight (Jobs versus Wozniak) even though the world gives us many examples to the contrary.

This startup mythology has seen a range of wannabe nerds who still live at home looking to make it big in Silicon Valley. Like starlets from Hollywood’s Golden Age, they swoop down on their Mecca looking for an investor to build the next unicorn. The question is how?

Now, let’s introduce the Lean Startup — a great methodology aimed at overcoming analyses paralysis — into our concept mix. Lean startup basically focuses on getting out of the office and starting to test your assumptions (which is great). the MVP is one such tool to get feedback and iterate. The “M” stands for “Minimal” (most people get this one right), the “V” stands for Viable (generally a massive fail), “P” for “Product” is charmingly out of date in today’s SaaS and iterative world.

Read more: Running a lean startup? Here are 9 free tools that could help

So, four concepts:

• Lean — customer value at its heart, rapid change to changing markets and optimising value.
• Agile — developer project management at its core.
• Monomyth — societies inherent love for heroes and how they wire our belief system.
• Lean Startup — overcoming analysis paralysis and getting out there and testing all the time.

So what is the problem? The problem is the belief that MVP and getting out there will increase your speed to market. We trust coders too much and rush to “write some code” because they are the heroes. We use agility to manage the project and make quick decisions to launch with an MVP. Generally, the code is wrong because it is based on the wrong assumptions and the wrong user behaviour. This is because who wants to go and test those with prototypes, interview lots of strangers and have their own beliefs laid bare by understanding the problem more intensely, do landscape research, understand the ecosystem and value chain, model different revenue models, test pricing elasticity, and so on.

What corporates and startups miss is that they have not tested all their assumptions before writing the code. They have spent too little time really understanding the problem and rushed toward a solution. Seeing as there is such a shortage of coders, and code hours are so rare, we should be managing our products to have less code not more.

MVP are normally more NVP (non-viable product) and once you have the wrong set of assumptions and behaviours you are testing off of, guess what, the chance of you going back and finding the right ones is almost zero. Why? Because you start A/B testing to optimise the wrong stuff. Your focus is already in the wrong place and now you are in product mode.

Also, “products” are complex things and operate as whole systems — it’s hard to test just one behaviour for optimisation without the whole product impacting the result of that test (e.g. a landing page — if your value proposition is wrong or business model is wrong, it wont matter how long the form is or what the colour of the button is).

This article originally appeared on LinkedIn and was republished with the author’s consent.

Image by Steve Jurvetson via Flickr