"Minimum Viable Product” at TiEcon Chennai

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.

Please leave you comments below. If you like this blog, please follow.

Evaluating Drupal Modules

Any serious Drupal Developer would admit that one of the most challenging tasks in Drupal development is to identify, evaluate and adopt contributed modules. This is so, for the following reasons:

1. Many of the contributed modules are written by developers, with specific Requirements in mind which need not be exactly matching you requirements
2. There are many modules doing the same task but with different approaches
3. The code quality is unknown until tested

It is therefore important to take a systematic approach to evaluation of modules in order to derive the best value out of them.

In my last blog, I wrote about the key questions to ask while evaluating a Drupal module. The questions are:

1. Is the module well maintained?
2. How much of the requirements does it cover?
3. What is the effort to customize / add / remove features?
4. Does its design employ Drupal’s best practices for writing modules?
5. Is the code well commented and easy to understand?

It is most likely that you don’t get positive answers to all of these questions. How the answers affect your decision would depend on a number of things including:

1. The volume of traffic the sites is expected to handle
2. Your Drupal skills and ability to maintain modules
3. Time and resources available

Module Maintenance

A well maintained module with a lot of community support can be safely adopted. Following is the screen garb of the Webform module taken form the Drupal website.

As you can see there is continuous development and maintenance happening for this module and is current with Drupal’s latest release. The Maintenance Status says “Actively Maintained”.

Another indicator is usage statistics. While this need not provide the complete picture, it is a good indication of adoptability of the module. Here’s a screen grab of usage statistics for Webform module:

As you can see, there is a large and growing user base making it very safe to adopt.

It is also important to take a look at what are the pending issues for the modules and have a good understanding of them. If some of the pending issues come in the way of using the modules, consider fixing them and sharing them with the community.

Requirements Coverage

The best way to understand how much of your requirements would be met by the module is to install it and try it out. Some modules provide screen shots and demo sites with which you can experience the functionalities.

If you don’t have a development team capable of customizing modules then you don’t have many options. Pick up the module that best suites your requirements and use it.

There are modules which can be used as a basic framework to build specific functionalities on top of it. Organic Groups (OG) module is an example. Many people use OG to create and manage user groups and build custom functionalities on top of it.

Many of the popular Drupal modules provide well structured interface functions / APIs for extending the module’s functionalities. Such modules can be easily extended without worrying about how the code is written and the possibility of breaking upgradeability. This very useful if you wish to use the module as a basic framework to build specific functionalities.

Effort for Customization

If you have the skills and resources then you can compare the effort of developing a module yourself with customizing an existing module. Module customization can involve both extending functionalities and equally importantly, removing unwanted functionalities – which can be a very hard thing to do. Therefore, careful analysis of the design is required to assess the effort requirement.

Too much customization required? You are very likely to break the upgradeability of the module. Well maintained modules receive regular patches covering various fixes including the ones related to security and functionality enhancements. Over customized code is very likely to break during patch updates and upgrades. However, if you have the skills and resources to maintain your own code then you can still make use of code blocks from the module saving some development time and effort. Again, if you think what you are building is generic in nature, consider giving it back to the community.

Employment of Best Practices

Drupal website has a detailed guide to module development . While certain methods and guidelines must be followed by all modules, others are ‘best practices’ and therefore optional. For example, a module can by-pass Drupal’s APIs to directly query or update database tables. Similarly, a module can use custom code for database access rather than using Drupal’s API. While there could be valid reasons why some of the guidelines are not followed, employing best practices will make it more maintainable and easy to understand.

Coding Standards

Code written by experienced developers are always well structured and easy to comprehend. If you plan to customize or maintain the module then make sure that the code can be easily understood. A well organized code is also an indication of bug-free code.

Can’t find it? Build it.

With ever growing base of contributed modules, it is very likely that you will find a module that meets your requirements. The very reason you are looking for a module is because, your requirement is generic in nature. Therefore, in case you don’t find the module you are looking for, build it as a generic module and contribute to the community. And when you build it, ensure that it has all the qualities that you were looking for in a module!

Please leave you comments below. If you like this blog, please follow.

Drupal makes it easy for developers. How easy?

This is a question that comes to the minds of people who are considering Drupal for developing their applications. Unfortunately, there is no single answer to this question. While it is possible to get a fully functional website up and running in less than an hour, certain websites can take several hundreds of hours to build. 

Before trying to answer the question, we need to first understand in what ways Drupal makes it easy to build websites. There are basically 4 ways in which Drupal does this:

1. by providing a versatile content management framework to build content-based websites
2. by providing a robust platform for building community and collaboration applications
3. by providing a library of “contributed modules” which provide wide range of extended functionalities
4. by providing a robust development framework to build complex web applications

The more you leverage these features, the easier it is to develop. How much you can leverage each of these depends on a number of parameters some of which can be very specific to the task on hand. 

Drupal as a Content Management System

If your requirement is to build content based websites such as corporate websites, newspaper websites, blogs etc. then, Drupal can save you enormous amount of development effort. It is actually possible to get a simple corporate website up and running in less than an hour. 

Drupal provides a number of features which, can be used to build most complex content based websites you can imagine. The effort required to achieve this are mainly in two areas:

1. building the custom user interface– a process called “theming” 
2. configuring various parameters to crate the content architecture, menu structure, content types etc.

If your site has sophisticated UI elements such as flash elements, ajax elements etc. and several content types where each need to be presented in different layouts then it can take hundreds of hours to build the site. Similarly, if you are not happy with Drupal’s standard publishing interface then it can be customized, requiring additional effort.

Drupal as a Community and Collaboration Platform

Drupal was originally conceived as a platform for collaboration. Therefore, it is inherently easy to build community portals in Drupal. Durpal’s node system provides sophisticated content creation and publishing mechanism with change logging which is ideal for building wiki pages. Drupal also provides modules for building discussion forums, user groups and social media networking functions. 

While many of the functions of the community applications are standard in nature, you will find that Drupal’s “community” modules need to be customized to suite your specific requirements. Many people use these modules as “platforms” and customize and extend them to build the application. This, depending on the extent of customization, can require considerable effort. For example, to build an application similar to Facebook, you will need to customize and stitch together a number of modules which will involve significant effort.

Drupal’s Contributed Modules

Drupal has several hundreds of modules contributed by the Drupal community and you are very likely to find modules for every requirement of yours. However, evaluating a module and using it can be a challenging task. This is where many people tend to get carried away and the experience and knowledge of an application architect is put to test.

Modules such as CCK, View, Organic Groups etc., are standard recommended modules of Drupal, and are built and maintained by high quality developers. These modules evolve along with Drupal. Therefore, when we say “contributed modules”, we are referring to the non-standard modules which are maintained by developers to meet certain requirements, mostly specific to the project for which they were originally created.

The 5 most important questions to ask while selecting a contributed module are:

1. Is the module well maintained?
2. How much of the requirements does it cover?
3. What is the effort to customize / add / remove features?
4. Does its design employ Drupal’s best practices for writing modules?
5. Is the code well commented and easy to understand?

In an ideal situation you will have positive answers to all these questions. However, most of the time, the situation will be less than ideal. Moreover, there are other aspects like performance to consider if your application has to support heavy traffic. It takes an experienced application architect to weigh various pros and cones and come to a conclusion. The process of analyzing and selecting modules itself can be a time-consuming activity. 

I’ll be writing another article covering the module evolution process in detail.

Drupal as a Development Framework

If your application has very specific requirements that cannot be met by Drupal’s modules, you can still use Drupal as a Development framework. Although Drupal is popular as a CMS, its architecture allows it to be used for building applications which have got nothing to do with content management. (I admire Drupal for its architecture, which in simple terms, is object oriented thinking implemented using a procedural language! While the object oriented approach makes it elegant and versatile, use of PHP makes it popular.)

There are a number of reasons, most of which are technical, why you should use Drupal as a development framework. However, it is very important to understand that no platform can provide everything that you are looking for. There may still be certain things that the developers need to do to meet your specific requirements.

There are several features that can be used with minimum or no customization such as user management, authentication, menu system, cache management, site configuration system (to control various standard functions / parameters of a website) etc. Similarly, there are features which can be used as foundation to build the specific requirements on top of them. This includes the node system, CCK, views, forms API, access rights, notifications system, etc.

So, how easy?

As we have seen, any non-trivial web application that can be built using plain PHP and MySQL can be built much faster and better using Drupal. No matter how you make use of Drupal, it makes the development easy enough to justify its use!

Please leave your comments below. If you like this blog, please follow.

Firefighters

During the recent recession and slow down of IT industry in particular, one of my friends working in an MNC told me that he would join Fire Force if he lot his job because, his job in the organization was to fight fire!

In fact, there is an unofficial Fire Force within every organization which is an elite club. One can find the best of people in the organization serving as Firefighters. Anything can catch fire: project, customer relationship, vendor relationship, people relationship, investor relationship… the list goes on. The most inflammable of all is project.

Every component of a project including (poor) project planning, project (mis)management, (poor) quality of resource and (lack of) technical skills can create  necessary friction and produce sufficient heat to set the project on fire.

Sales folks have their own contribution. Unrealistic delivery commitments can create tremendous amount of pressure on every department of the project.

Even customers can contribute to the fire. Ill informed customers can make unrealistic demands. Their ever-changing requirements can set off a chain reaction in the system creating pressure and friction everywhere.

What is primarily at stake when a project is on fire is the pride of the company. Unfortunately, unlike a real fire which can be felt by the light and heat it generates, and is most often noticed at the beginning, a project fire is invisible and is felt only after it creates substantial damage. By the time Firefighters are called in, it would be a herculean task to control it. But, the Firefighters have no option but to douse the fire as the company’s pride is at stake!

What makes the Project Firefighters greater heroes than the real Firefighters is the fact that the former fights with no real tools and equipments in hand. The most important tool they have is their instinct. The other tools are endurance and perseverance. There are various special tools: technical and non-technical skills that are suitable for the nature of the fire.

The irony is that, it is seldom easy to differentiate a Firefighter from someone who is creating the fire. If you find a person working long hours in office and while away from office, attending continuous phone calls, be certain that he / she is either dousing a project fire or setting a project on fire. It will need experienced eyes and ears to spot the difference.

Coming to the key question: is it possible to fire-proof projects? This is a question that software gurus have been trying to answer ever since the advent of software projects. They have created not one, but several solutions - each one suitable for a certain type of project but none capable of providing 100% protection.

No matter which solution you adopt, the Firefighters are here to stay.

Disclaimer

The article has no intention to degrade any person, role or profession. The author is a Firefighter himself but has also been a fire-setter on several occasions.