Feature Prioritizing

Prioritzing the features in the first version/launch is one of the major hurdles that any application/ service website would face. The common wisdom for web based services is to let out the first version with the bare minimum features that would keep a user hooked on and then add subsequent functionality/features around this "core" with the user feedback. Of course , this is assuming that you are able to gain atleast a small, but dedicated user base or fan following, whichever you prefer. Rephrasing Paul Graham from this post, "..your early adopters are fairly tolerant. Your product just has to do something, not everything.."

This approach is the surest (not the easiest) way to dodge the black hole of “feature creep” wherein the developers/creators spend lot of time integrating new “killer features” into the product without having the actual user’s perspective. The end result is that the consumer ends up with a heavily loaded (read complicated) product without having any inkling of what to do with it. Hence, at every stage of development, it is essential to step back and think from the consumer’s point of view. Better still, have actual users testing it all along.

Now focusing on our site, we had already spent quite some time dilly-dallying over our ideal offering and the benefits (I’d call it increased productivity) that our users could potentially gain. In view of the ever increasing competing services springing up, we pulled out all the stops and decided to fix a date and launch with as much as we could accomplish in the time frame. (It’s another story that even this date got postponed, well twice actually).

Agreed that this was not the ideal way of getting about with the launch, but we needed something concrete to go by. Then we sat down and ranked the features that we planned to have on two major parameters :

• Perceived utility to the users
• Effort required from our side in terms of time and manpower

There could have been n other parameters, but for an optimal result, these two or their variants would more than suffice. Once, this was done, it was not very difficult to handpick the features that would form the “core” of our initial offering based on the "points" the features scored on these parameters. The subsequent releases would build upon this and as time and manpower permit, we would be crunching out newer and better features.

This “feature prioritization” problem would be faced by all product/site developers. Joel Spolsky has an excellent post here dealing with exactly the same issue. Additionally, 37 Signals and Newyorker have helpful articles here and here respectively.