Prateek Dayal

Since I started working on Muziboo, I have been a big fan of release early, release often philosophy. We launched Muziboo one month after getting the idea with very basic functionality and a very simple design. Since then, we have been listening to our users and continuously improving it. However I have to accept that many times in retrospect, I have been embarrassed by what I released. At times, I have also renounced release early release often for a few weeks (in search of design/functionality zen) only to realize later that its a bad idea and that I don’t have much progress to show for those weeks. I recently listened to a Mixergy interview with Eric Ries and started thinking about why we still don’t see that many examples of release early release often and see so many stealth mode startups around us. Here are a few points I think influence people:

A different kind of vacuum

I think everyone agrees that there is nothing worse than building in a vacuum. However I think the second worst thing that you can do is to build with feedback from people that are not your potential users. Most stealth mode startups take feedback from their close friends, family and other people in their network. The problem with this approach is that if someone is not your potential user, he/she is always gonna compare your product with the successful products of the world and not based on ‘that one thing’ that you do really well. You are only gonna get very generic feedback like “design is not that cool” or “you should try to use more ajax and overlay windows”.  In fact its very easy to get wrapped up in refining your product’s interface and delay your launch.

Ideally you should just get the basic functionality right and launch the product. You should not care if a lot of people think  that your product sucks (it does, but thats ok). Get your first few real users and listen to what they say. Solve a small problem first and then grow from there. Sure, you are going to lose some people who are never gonna come back to the site but thats ok. Internet is a large place so won’t run out of users anytime soon and once you have critical mass, most likely they will come back anyway. Find the first set of users who care for the solution that you are offering to them (because it solves one of their pain points) and grow with their feedback. Don’t obsess with UI before launch just because your ex-boss is still not impressed or because that big blogger won’t write about you unless you have a nicer interface (he won’t write about you anway and it does not matter again).

Stealth mode as a marketing technique

Another reason I see a lot of people doing stealth mode startup is to create buzz with the bloggers and potential users. Get over it. Most likely stealth mode strategy won’t create the buzz for you unless you are already very popular. Its just gonna give you too much time to work on stuff that does not matter. Some startups do end up creating some buzz (or curiosity) but in the wrong circle. Your twitter followers and your blog readers will probably get to know that you are working on this next cool thing but thats as far as it goes.  Most likely your target audience will never hear about your stealth mode product and wait for its launch. If people are coming to your site, show them the real thing and not a text box to add their email address to the wait list. Hunch can pull it off but you probably can’t.

Working in stealth mode?

Trying to avoiding rejection (and embarrassment)

More often that not, people are just not comfortable releasing something thats not upto their standard of perfection. They don’t wanna release something they are not extremely proud of on the day of launch. Right from childhood, we are taught to work on our weaknesses and we simply can’t release something that other people can easily point holes at. My advice is that its ok. In my two years of entrepreneurship I have realized that you can’t avoid hearing from some people how your product sucks or you that you have no competitive advantage. You cannot avoid those uncomfortable moments where some people tell you that they would never use your product in the current shape and that it has a long way to go before it gets any where. You cannot avoid that situation by postponing the launch by three more months and working some more on it. As an entrepreneur you have to learn to accept some rejection (atleast early on). You cannot and should not try to please everyone.

In the end most of what I have said is from my personal experience and observation. There are always cases where working in stealth is better and if you have the vision and domain knowledge to pull it off, you should do it. However if you are like most bootstrapped startups, you can benefit a lot from releasing early, talking to your real users and then releasing often with their feedback. As Eric Ries says in the Mixergy interview, understand the difference between your product launch and PR launch.

Popularity: 32% [?]

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% [?]