Last updated on January 11th, 2024
Digital innovation is the name of the game today. Anyone making software products is in it to win it. Creating a Minimum Viable Product, or MVP as it is more popularly known has been used as a tactical weapon to win at this game for quite some time now. But has this approach run out of steam?
The MVP taught us how to adopt a lean and customer-centric approach in product development. So effective was this model that not only startups but established organizations made this approach the norm. However, with news of some high-profile products launching in the market after spending as much as two years in development showed that other approaches also worked.
I’m assuming we all know what an MVP is. Here’s a “no one asked for it” refresher. This is the development technique in which you develop and release the product with just sufficient features to satisfy early adopters. Upon receiving the customer feedback, you proceed to evolve towards a full and final product by adding on features.
Here is what an MVP is not – it is not a method to build a minimal product where quality and good design are sacrificed for faster delivery. Read more The 5 Essential Steps To Building An MVP.
Now, this had been working fine for us for a while. So, what could have changed? Two of three factors, as far as I can see.
The proliferation of software has become near universal. Software has changed our world and our lives. It has managed to integrate itself seamlessly into all that we do. Isn’t there is an app for almost everything? As this software takeover of life and work continues, our expectations from software are changing as well. That’s a key change.
This software proliferation has also given rise to new development methodologies like agile and DevOps. That’s a change that was concurrent to the rise of the MVP and in many ways, was driven by the MVP way. But this has also created an unexpected turn of events.
Thirdly, there’s the rise of the cloud and the continuing rise of open source technologies and their impact charge software development. Taken together, software product development could well be made easier, faster, and more cost-effective.
So, how does that impact the MVP?
Now one of the reasons behind developing an MVP is to test product viability without incurring heavy expenses. It is about learning what the customer wants, what they demand and how they intend to use the product. All without over-committing resources…Right?
However, with product development approaches like agile and DevOps is that as big a concern? These approaches enable you to develop a good product that meets the market requirement and has a strong quality focus. They are also much more resource-efficient and enable faster releases. So, why focus on creating a half-baked product?
Which brings me to addressing the cost aspect. Keeping development costs under check is another valid argument in favor of the MVP approach. However, the rise of Open Source tools and technologies and the proliferation of cloud have enabled product development teams to keep many of these escalating costs under check. By leveraging them, now you don’t need to create a ‘minimum’ product…you can create a complete product at a comparable cost!
Lastly, and most importantly is the view from the customer side. As customers become more mature, their expectations from software products rise. Today, customers will not touch a product that does not offer a seamless and optimized experience. If an application does not meet their expectations, your user will uninstall it promptly, without hesitation. If security features are not robust and mature, you can forget about user adoption. A bad experience today gets reviewed, reported on, and disseminated to create a bad impression for life. Many half-formed version 1’s have died public and unlamented deaths in this manner.
My view is that the customers of today are less willing to be guinea pigs. They don’t want a sub-optimal product, even if it is to gather feedback. In fact, an interesting co-creation model is also emerging where the initial adopters offer their opinion and feedback as important parts of the product development process. The savvy customer is looking to build relationships like that -not be a victim of a discount-development strategy.
Conclusion:
The success of the MVP way lies in the ability it gives to the product company to gather feedback and then pivot based on that knowledge. The MVP mindset forces you to compartmentalize, take small steps, and validate risks faster to reach that big product vision. And in a way, with agile and DevOps, we are already doing that.
I personally do not think that the MVP concept is dead or is going away anytime soon. However, what we definitely need to remember is to focus on building a product that delivers value to the customer. And remember that an MVP approach is not the license to deliver poor products faster.
