 |
The highly successful TiEcon Chennai of this year hosted two “unconference” style sessions one of which was on building products with bare-minimum feature functions and taking them to the market. The participants shared their experiences which gave great insights into implementing this strategy. Here, I summarize the discussions with the important points that emerged in the discussions.
The Strategy
In the highly competitive markets of today, time-to-market is becoming more and more critical and so is the need to build products that incorporate the cutting edge technologies. It is also important to obtain user feedback early and use them to quickly enhance and perfect the product. The strategy is to develop products with bare-minimum feature functions and take them to the market. While reducing the time-to-market, this approach provides several other benefits.
The strategy is best applied in software products where it is far easier to distribute updates and upgrades. However, it is possible to apply the same strategy to physical products as well but with a different approach.
In the web applications world, the strategy is called “Minimum Viable Product” (MVP), a term that I would use in this article to refer to the topic in discussion.
Early User Feedback
No market research and analysis can substitute feedback from real users. It is important to get the real user feedback as early as possible so as to make necessary corrections. However, the problem is that a real user needs a real product to use! Building a minimum viable product that is ready to use offers the perfect solution.
Fail Cheaply
One of the most important advantages of the MVP approach is that it allows the entrepreneur to “fail cheaply”. Experiencing failure with minimum loss of effort and investment allows the entrepreneur to recover quickly and shift focus from one idea to another.
Failing cheaply has psychological advantages too. The psychological impact from failure of a high investment, high expectation project is far greater than from failure of a low investment low expectation project. This is very important because, the key strength of an entrepreneur is his / her ability to recover from failures.
The “minimum viable”
So, what is the “minimum viable” or “bare-minimum”? It is the feature functions that address the most important customer pain areas. You are expecting the user to use a product that has limited set of capabilities. Therefore, it should have compelling features which the user will find attractive enough to experiment.
In a market where there are already existing products, MVP may not be an option at all. However, products such as Google Docs which, in a sense cater to the already existing “office automation” market and competes with matured products like Microsoft Office, can still be candidates for MVP approach. Google launched Google Docs with bare-minimum feature functions and is continuously evolving. The most compelling and unique feature of Google Docs is online collaborative editing beyond corporate firewalls which has attracted millions of users.
The “prototype” approach
MVP can be applied to physical products in the form of “prototypes”. A prototype is a working model of a concept / idea that has all the important features functions for validating the concept / idea. “prototyping” is a widely used approach in automobile industry.
Prototypes are normally validated by a closed / known set of users. These users would use the prototype to do real things in real-time. Prototyping allows perfecting the product and making it mass market ready before investing in the expensive production infrastructure.
Parallel Development
It is important to continue product development in a parallel track while the MVP is being tested by the users. MVP is not the complete product but only a stage in product development and needs continuous enhancements to make it the complete product. Waiting for all the feedback to emerge before continuing development can prove costly as you are likely to loose considerable amount of time in the process. A better approach would be to continue with the development and make necessary changes / corrections as and when user feedback is received. This way, you would have the complete product ready very shortly after the all the user feedback is received.
Product Beta
The “Beta” version of a product is complete in its feature functions but may still contain hidden defects. Launching products in “Beta” is becoming increasingly popular in the web-application world. The reasons for this are mainly (a) in a software product, finding those minor defects is extremely time-consuming and almost impossible by using standard testing methods; (b) In web-applications, it is relatively easy to incorporate changes and extremely simple to distribute them (due to its “hosted” nature.)
It is important not to confuse Beta product with MVP. Unlike MVP, beta product is a fully developed product, one step away from release.
Building MVP using Open Source platforms
For web applications, it is a great idea to build the MVP using open-source platforms. At UniMity Solutions, we build our MVPs and prototypes on Drupal platform. In our case, we continue to use Drupal to develop the complete product. However, if you need to use other more general purpose platforms / frameworks, it is still advisable to start with platforms like Drupal as it offers several out-of-the-box methods to build applications.
To Charge, or not to Charge!
Should you charge the customer for your MVP? In almost all cases, asking to pay only makes it difficult to get the user use your product. Remember, your primary objective is to collect feedback on your product and not sell it. However, if you think that you MVP offers a perceivable value to the customer, you may consider charging them.