Two of the most discussed development methods — Agile and Lean highly prioritize MVP (minimum viable product) capable of testing a concept in practice.
Unlikely something besides MVP can prove the viability of a developers’ brainchild equally well when it comes to custom software development.
Nevertheless, this apparent assumption is not so obvious for many software vendors and startups who prefer to create and rush a fully fledged product to market first (wasting a ton of money in doing so) and then to wait for how the market would react and what could happen with the product.
Very often (more frequently than vice versa, in fact) the so-called business intuition and market knowledge fail such overconfident software companies as evidenced by a high fatality rate among startups.
So, what’s wrong with the issue? Do the lack of knowledge, experience, and clear vision prevent startupers from practicing the efficient MVP technique?
It seems an incomplete understanding of many MVP’s advantages causes the regretful mistakes when the improper balance between continual product improvements and a prompt entry into the market takes place.
Finger pointing at the Moon
The first thing that should be fully realized is the difference between MVPs and products having minimum possible functionality ever.
Such a “minimum product” can be rapidly deployed at least cost in the form of either an alpha/beta version or just an introducing landing page.
This can serve the purpose of representing something to be discussed with potential users, some object of study.
However, such a minimum product does not always correspond the idea of MVP since it's over-minimalistic functionality can not meet the actual expectations of users.
And this is where the misconception grounds. While the ”minimum product” is intended to give some thinking food for its developers, an MVP should offer some value to users.
Even if this value is truly minimum ever. In this regard, one of many existing definitions of MVP is worth mentioning, “A minimum viable product is the smallest thing you can build that delivers customers value” (Ash Maurya, author of Running Lean book). Besides, in many cases an object represented as an MVP is far from being a “product” at all.
A landing page describing features of a future product can hardly be accepted even as a prototype.
Sounds weird, but this is exactly what Bodhidharma was teaching Zen learners about, “The finger pointing at the moon is not the moon itself”.
A whipping boy function
Of course, learning customers’ opinion composes a significant part of the MVP concept. However, a finished ready-to-use product can unlikely discontinue testing and experimenting.
One of the marks of a professional custom software development company is the continual product improvement that theoretically should never stop.
It does not mean the endless iterations when a prototype is going back to further development without giving a finished product a chance to appear.
Here a fine line between an MVP and an end product should be clearly recognized. This is the very mission of prototypes (or MVPs) to circulate in numerous iterations until a prototype is finally transformed into a commercial version capable of satisfying customers to a greater or lesser extent.
A seemingly finished software updated every day can make users feel ambivalent regarding its developers: on the one hand, their ongoing commitment to excellence is available, but on the other hand, the obvious immaturity of a commercial product may indicate a wish of its developers just to earn money as soon as possible.
In order not to expose a final product to such a risk, an MVP should play a role of a punching bag.
However, every team of software developers should be able to come to a consensus about the moment when their MVP is ready to become a commercial version.
This is about distinguishing “viable” and “valuable” with regard to the vendor’s final objective, as Guy Kawasaki claimed.
Best things come in small packages
Strategically important skills of using a minimalistic approach to developing an MVP are crucial for product vendors.
Many contemporary tech-savvy software companies are able to create an MVP having quite abundant functionality at least cost in record time.
However, the question is whether the MVP is that small package in which the best things come? In other words, even the best idea can be compromised by a deficient MVP just like a really good product can fail being packed improperly.
Often the risk lies in excessive refinement of functionality resulting in a hyper-minimalistic low-grade prototype which does not correspond the initial project.
It can not incentivize the sufficient level of learning among potential customers that leads to both ignorance and ignoring.
Hence, some may argue that maintaining a proper balance between a technically simple easily deployable prototype and an MVP capable of adding some value to customers is hardly achievable.
In order to solve the issue, software developers should focus on two different objectives choosing only one of them to be prioritized:
- Launching a product to the market as early as possible
- Sending a clear message about the core value of a product to potential customers
Both approaches are intended to different effects. Each of them may appear the most appropriate depending on a particular product, market situation, competition, and many other circumstances.
A synthesis of both approaches is theoretically possible in various proportions. Nevertheless, just the clear understanding of which approach should be selected to best correspond the current circumstances can prevent an MVP from getting lost among the rest equally worthless analogs.
Layer cakes are more delicious
The pure landing pages as a form of MVP can unlikely fulfill all assignments usually imposed on prototypes. Their weakest point lies in the insufficient tooling they offer customers for comprehensive feedback.
Registration on a landing page does not disclose the users’ concerns about a product while they just login.
Nevertheless, a landing page can be modified in such a manner that can make it more efficient in playing an MVP role.
It implies adding extra layers in the form of links to YouTube channels, blogs, and automatic mailing.
Such a layer-cake method should be provided in a step-by-step mode when a prototype acquires new functions and feedback tools over the progress of iterations.
Besides, this approach is applicable to any form of MVPs regardless of particular functions/layers can be added. The unobtrusiveness and consistency are the raisins that can make MVP’s layer cakes more delicious for users.
Whatever anybody says, even a low-grade MVP is better than nothing. It is more times cheaper and safer to give an MVP to “ laceration by customers” rather than impose a commercial product to experimental risks.
Hence, the Shakespearean question “to be or not to be” is irrelevant here. Any kind of MVPs is worth practicing. After all, the most progressive Lean and Agile development popularize the MVP approach for a reason.
If you enjoyed reading this post, please share it to help others find it!
SUBSCRIBE for weekly updates.
Thanks for reading...