MVP Launch – Why We Had To Slaughter Our Code?

This can be one of our worst nightmares as a start-up. We have just launched our MVP on the market. It turned out that instead of a victory we have to face a defeat. Why we have to burn our code to the ground? Let’s cast some light to the MVP’s behind the scenes.

Despite working on a Minimal Viable Product is a smart move, the effects can be disappointing if we don’t do it right. But before we expose the flaws, we need to take a minute to admire the overall look. In this article, we agreed that choosing Agile in our online product building is much more effective than a Waterfall methodology. Product Design Workshops conducted by our software house bring us closer to achieving our business goals. Launching MVP keeps us in the race, helps us in marketing communication with our clients, and save our time and money. Fine. But if it’s so fabulous, why can it backfire?

Our App as a Forklift – Product misconceptions

To get this right, we will be metaphorical for a while. Forget about IT. Let’s imagine that a software house we hire for a job is a company specialized in constructing customized vehicles. We come as a client and all we say about our expectations is that we need to build a vehicle for product transportation. Could we be vaguer? After taking a few deep breaths, our new business partner offers „product workshops”.

Together we work out what kind of vehicle we actually want to construct and what do we need it for. It turns out that all we need is a forklift with an increased load capacity. We decide to hire that company, and their engineers kick off the entire process. They construct, build, and deploy our forklift. We introduce it to the market. And what happens next? We come to a conclusion that our forklift is pretty much OK (for now), but what we would like to do is „little bits and pieces” to be improved. We want our vehicle to become a long-distance runner – to be able to transport goods within 1000 km radius. We want it to have space for a driver and 4 passengers, and to hold 3 times more load capacity than the original version of a forklift. Is it possible? Hell no, it isn’t, and our contractor will tell us so.

What can we do in this situation? We have two options: to keep on selling the original forklift (and start building a new one at the same time) or to abandon the project and build a new vehicle from scratch.
Ok, we get the point. In IT projects we need to be 100% clear about the product’s objectives. Our software house works on a system based on business goals. We need to be bold about them. We just cannot hedge about the MVP range. We cannot say that we want an application for everyone, with every possible app feature we can think of.

Why should we choose the MVP?

Why should we care so much about MVP? Because it will prove that our product has potential (or not). It will also show that it is able to win our clients’ hearts, and provide us with a meaningful feedback from the market. If we know how to use the intel, we will be able to take good decisions. We will diminish our costs at a very beginning, and still fight for our clients. We will reach our goals faster, cheaper, and easier. Moreover:

• Finding angel investors is much easier if the MVP works and it resonates in the market. We know that is worth investing more money in the product. Investors don’t hesitate too long if they see that the product is already validated. That’s the MVP’s huge leverage.
• If the MVP is not successful and the brand community isn’t happy with it, we still have some backup plans. We can withdraw from the market (without big financial losses), or slightly change the course with a pivot. The product failure is a very disturbing vision for every entrepreneur, but the true value of MVP is hidden right here, in the heart of a product defeat. If our app fails, the MVP saves us from big harm and big financial repercussions. Even if we get knocked out by the market, MVP helps us to minimize the risk and drowning in debts.

Clear vision & communication

As a product owner should we say upfront where we see our product in a few years perspective? Should we expose our future plans during our first meeting with a software house? 100% yes. That information should be presented to the software development team as soon as possible. This will empower the programmers with a clear product vision. This will unlock the opportunity to design features in a way that will enable functionalities to be improved and expanded in future.

If we don’t do this, we will find ourselves sweating because some algorithms will disable feature modifications in a few months or years perspective. All we can do then is to burn our code to the ground and suffer the failure.

The good news is – we can prevent it. From the very beginning, we must emphasize on the clear objectives. We have to join our forces with the software house and come up with a range of our MVP.