MVP and the misconceptions about what it means
I sit as a technical advisor on the panel of KodoStartups pitching events and I hear pitches from a lot of startups. Such events are heavily packed with big audiences as well as startups wanting to pitch their ideas to the investors.
Pitching an idea is not an easy task. As a founder, you have a very limited time to keep the investors’ attention and be able to convey your message across. I see many founders fail to explain what they want to build, who they target and how they will reach that market. But the most worrying of all for me as a technologist and someone who builds software for a living is the misunderstandings around what an MVP is.
Founders pitching their MVP to investors
Before we take a closer look what an MVP is, let me tell you what I hear during these pitches and why this is all wrong.
Most of the founders have never read Eric Ries’s book “The Lean Startup”. They have heard other founders using the term MVP and have adopted it. They have to, because they need to use the jargon adopted in the startup community, of course, but they lack the understanding of what an MVP is. This is dangerous.
Most likely, someone explained the term and the concept around it, then somebody else decided to simplify it and present it in a single sentence and the process continued until the widespread understanding became something like (approximating) “Build an application with only the most essential features at launch”.
This is exactly what I hear from founders when they try to explain back to me what their MVP is.
The dangers of building an MVP with the lack of understanding of what it is
The notion of “building an application with only the most essential features at launch” may make you sound and feel smart, or even impress some investors, but it holds absolutely no value.
You are a startup. The whole idea of being a startup is to define the product-market fit and then find the right business model to bring that product to your customers. What this simply means is that you cannot know what is an “essential feature” for your product. Period.
If you already have your product and you already know who your customers are, you may be able to distill the core functionality your product needs to offer, but at that point, you are not a startup anymore, you are running a real business. Trimming your application down and cleaning it periodically has a value of course because you are improving the application to be closer to the real needs of your customers. But this is not what a startup is doing or should be doing. You are in a search and innovative mode and your goals should be to experiment and iterate.
Launch with “essential functionality” may kill your startup
Now that I explained why it is not possible to launch your product with “essential functionality”, let’s talk why such a notion is dangerous for a startup.
Since you don’t know (and cannot know) what the “essential functionality” is for your application, service, or product, the best thing to do is to guess it. This guess will be based on your personal needs and experience, simply because it cannot be otherwise. In other words, you will be building a solution for your needs and hope (also will try to convince other people) that this is a viable solution to many other people with the same problem.
On top of the (probably) wrong assumption that other people have the same problem as you do, you apply the assumption that what you are building is the right solution for that problem (and set of people). Then you will be applying even more assumptions – that the defined “essential functionality” set of features is the right set of features to launch with.
Even if we forget that the “essential functionality” is nothing more than a personal preference, think about the fact that there are many startups out there, most likely trying to get to the same customers and offering similar solutions. I know, we think we are all geniuses, but reality shows time and time again, that really original and unique solutions are extremely rare.
By limiting your set of functionality to a minimum to help launch quickly, gives other startups the opportunity to offer something better, more functional and closer to a finished product. We are all trained that time-to-market is critical, but let me ask you this – was the MP3 player invented by Apple? No. But Apple took the time to develop a killer device and they succeeded where other companies were rushing to take over the market segment with half-built products.
This is the key – half-built products. I see more and more cases where the term MVP is being used to justify laziness, lack of dedication, lack of creativity and vision. “Let’s launch something” is more important than actually building real solutions. The result is a waste of energy, time, resources that should have been used to invent a really viable solution.
What is MVP then?
MVP is an important concept and should be implemented correctly.
To develop an MVP, you need to have a Theory. This theory needs to be Measured. Collected data will provide Knowledge.
The purpose of an MVP is to test a given theory, gather the right data points about the theory and generate the knowledge based on that theory.
Without the proving/disproving element, gathering data and extracting knowledge you are not really building an MVP, but rather using the term to describe a limited functionality product.
Follow the mantra BUILD – MEASURE – LEARN.
Please remember this is an iterative process. Your goal will be to test one idea after another and do it quickly. It is not the product you “launch”. It is supposed to be just one step of the process to figure out what will be your product. This is supposed to be a validated learning cycle that helps you learn and innovate until you hit something valuable for your customers.
Conclusion
Building an MVP doesn’t mean building a smaller set features in your product. It means having a theory to test, measure and learn. Then repeat the whole process until you find a viable solution to the problem you are solving.
Going to market with limited functionality is dangerous. It may even kill your startup and your idea. Half-baked products only increase the mediocracy of quality and waste time, money and resources.
Invest the time to understand your customers’ needs and dedicate your effort to deliver a functional solution.
0 Comments