Prateek Dayal

Getting Real is one of my favorite books on writing software and I love reading it every now and then. However when it comes to real projects, one is very likely to skip the advice given in that book. Its very easy to overbuild a product especially if you love coding. I have seen this in Muziboo and also seen it in a couple of other projects that I have been closely associated with. On the other side, I have seen a lot of examples of release early release often in successful products and have come to believe that it is in general a good idea to write less code initially and write more as and when required.

Its not the features, Its the idea

People should come to your service for the idea or the philosophy of your product and not for fancy features like ajax search. An example that I really like is @ replies were not part of twitter. They were introduced later when people started using twitter that way. Same goes for video response feature in youtube which was introduced when people started responding to a video with another video. Assuming that your service will not take off until there are enough features to wow everyone is a mistake. Delaying launch to add more features is an even bigger mistake.

For wide adoption, build what people want

If people start using your service in ways you did not imagine and you build a feature that facilitates such usage, its gonna have adoption. Both @replies of twitter and video responses of youtube were such features. Its a good idea to not let the geek in you decide what features to implement because the coolest new feature may not be what people want. When your users ask for a feature, they adopt and evangelize it. In case of Muziboo, some features that we built did not have huge adoption but surprisingly features offered as part of pro account had good adoption even though they are paid. These were the features that we rolled out after users asked for it.

Don’t underestimate the cost of a feature

A feature is not just a hundred lines of code that you can hack together in a few hours. When you have a live site, a feature is much more. It is

• Real estate on the page
• Cross browser compatibility work
• Documentation work
• Bug tracking and fixing

Make sure you factor in all of above before you decide to implement something new.

Don’t listen to everyone

Finally don’t listen to everybody. Don’t listen to the geeks and coders who love coding new features or use cool new technologies. Whenever in doubt, ask your users.

If you have not already read, I highly recommend reading the Getting Real book.  By the time you finish the book you will realize that constraints are not such bad things after all :)

Popularity: 14% [?]

Tags: getting real, release early release often

This entry was posted on Monday, June 23rd, 2008 at 2:22 am and is filed under bootstrapping, learning, muziboo, productivity tips, startups. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.