We are confident that we will get customers and we will be able to multiply our customer base fast once we cross the incubation stage. But reaching that stage needs massive amount of research and development effort. And that cannot be sustained by us on our personal savings – and definitely not without quitting our corporate careers.

And to do all this we need Seed Funding – it’s a vicious circle which probably every entrepreneur faces. Most entrepreneurs overcome this phase by sheer determination of cutting through the hardship – even borrowing money to run their dreams. We would probably have done the same – if this was a smaller venture which could be incubated on less money, but we don’t think it is like that. And so the wait is on – for the VC who would help in Seed Funding and kick starting.

Till then – we reminisce on the mistakes we committed and try to learn from them. May be for this venture, but if not then for another one, whenever it comes!

Concluded.

Index of all posts in the series: Bloozle – the Startup that never was

Continued from Product Development Mistakes (Bloozle – the Startup that never was - Part IV)

We probably still would have survived, because at the end of the whole charade – we still had a working prototype*, a proof of concept and most of all a revenue model – which hardly any online startup in those days had. But unfortunately for us – recession had to set in just when we were readying our b-plan and reaching out to investors.

In the months since October 2008 and today – we have heard responses from umpteen VC’s^ that they are not even considering investing in seed stage startups till the recession goes away. Most of them of course camouflage their response by saying that they would have invested if we had customers (essentially saying no to Seed Stage and asking us to reach beyond that stage).

Unfortunately for us, personal lives are at a cornerstone where we could not have risked our personal savings (beyond what we already had) in taking this concept beyond the seed stage. We knew (and still know) that this is an idea which needs incubation time – a couple of months may be, but may be a year – before we can approach our first customers. And we know our personal savings will not help last that far – so relying on them is a sure road to an unfinished race.

Next - Conclusion

*Thanks to Aniruddha Maru, our second developer, who developed the missing pieces of the working prototype. Aniruddha is one the most intelligent and quick to learn chaps I have met. He picked up the app-architecture and the code within hours from Manpreet. He was always quick to code new functionalities. His strength though became one of the weakness for our team – he thought so fast that he often coded things even before we could crystallize our ‘specs’ :-) and hence we could never document stuff.

^Kalpesh Khivasara also deserves a note of thanks – he has been helping us since 2007 working on concept development, helping contact VC’s and researching the web. I am sure he will be the first person whom I’d contact if I were to restart bloozle or start another venture.

Continued from Product Vision mistakes (Bloozle – the Startup that never was - Part III)

Its important to get at least one section of your site work completely and bug-free than have your complete set of services rolled out but all in a half baked shape. While it is true that beta users are usually tolerant, but they can't be tolerant towards a product that looks full blown, but doesn't work even for some basic requirements. They would rather have fewer sections - but those few work well. Project Management lesson - make sure you get your priorities right!!

Get commitment from the development team that they will not desert the concept before it reaches its logical completion. Our development team changed hands often – what made matters worse was that I was so preoccupied with the product vision and marketing aspects that I never got a chance to dig deep into the technology aspects. So, at one point when our lead developer went away and I got in a new team to carry forward the work, I had to spend my own 2 weeks understanding the way the code worked before I could navigate the new team.

Make sure you have a captive group of users who would be prepared to participate in your beta before you launch. This captive group could be your own developers if you have a large enough team, or your friends – but it must be a group of ‘real’ users. While we tried to create a captive group by asking a few friends initially and later offering a chance to barCamp participants – in true essence, every new feature rolled out was tested only by the developer and me before launching. We did not do cross browser testing – ignored Internet Explorer downright – and our testing too was never rigorous. As a result the product when it came out was bug ridden and every subsequent feature made matters even worse (increasing loading time for the site, but not offering any core performance improvement).

Use standard libraries/development platforms wherever you can – if required take extra time before starting your development to discover the different tools available. When we coded the first version of bloozle, we started from scratch building the most basic Javascript functionalities ourselves. Where we could have crunched our development time by a fourth using Prototype or jQuery, we spend in making our Javascript scriptlets compatible with different browsers. Since, we had just one developer for most of the time, we never used SVN which became a problem going forward when more people got involved with the development.

Document Document Document – we never documented our code or even the basic application architecture. Software development practices such as naming conventions used, class names and database table names were documented (thanks to Manpreet – our first developer who did a fantastic job!) but the working of our code were never put in words. This again became a big problem when the code had to change hands – which unfortunately happened twice over the last leg of the project. I happened to the only person apart from Manpreet to know the architecture of the code when it changed hands and there was no document which I could pass on.

Next - Environmental Factors

Continued from - The Concept (Bloozle – the Startup that never was - Part II)

But call it limitation of technologies of the times (2004-6) or our inability (ignorance?) to harness them, but the concept of aggregating feeds based completely on automated algorithms did not appeal to us. Instead we decided to develop a Feed Reader for users which would be our means to enabling aggregation.

However, once we set out to build an RSS reader – we got too engrossed in it. The means became the end – we got lost in the barrage of features which we needed on the reader to make it more user friendly to our users.

Even worse, unfortunately for us, we came up with a RSS reader just when RSS reader usage peaked and was just about to start its decline [RSS is dead]. Being at its peak, the major user share was taken by the big players (Google, Bloglines, Newsgator) – and our bug-ridden product became a student experiment never to see the number of even a 100 users.

The key reason, in hindsight was to leave to vision of the goal and follow a highway which led to a different direction. Just because the road is a highway does not mean that it leads to your destination and not every wave can be ridden.

We ran on the RSS Reader highway and tried to ride on the RSS wave, in pursuit of an audience which was never our target, using the right concepts (rating, tagging) but for the wrong purpose, concentrating on features (like a ‘post filter’ within the reader) which had nothing to do with our core product/service and hence we failed.

Next - Product Development Mistakes

The idea is simple – also a clever combination of various existing concepts like Social Bookmarking, FriendFeeding, RSS Readers, news rivers, co-ranking (digg/stumbleUpon):

• Users would subscribe to their favourite blogs in our custom developed feed reader.
• They would read their regular blogs and would rate and tag blog posts they read
• Incoming blog posts would also be automatically tagged based on the labels/tags which the authors attach them when posting. Going forward the system will also perform intelligent tagging based on factors like source, number of times a word appears in the post body, words in the title etc.
• The rating and tagging would be aggregated by our server and then blog posts would be rejigged (segregated) – grouped under tags and ordered by ratings.
• Users would subscribe to their favourite tags (such as technology or sports) - also called TagFeeds - and they would receive the top-most rated blog posts which have been tagged under the same tags by other users of their site (from blogs which they don’t follow).
• While users would be able to take care of their information overload (surf your own favourite blogs and read other popular stuff through tagFeeds), we would use the same meta-data (rating/tagging) to generate our blog-newspaper (christened bloozPaper)

It all looked pretty good on paper – and I believe it still is – but only for the lack of users. We made a series of mistakes, which resulted in few users using our site and ultimate demise of the whole concept for the lack of traffic and therefore the metadata which was the core need of the concept.

Coming Next - some mistakes and other environmental factors which lead to the untimely demise of our product and stillborn startup.

One such idea was to create a newspaper out of blog content – essentially as we realized later, we wanted to build an intelligent aggregator of user generated content. Fast forward to 2006, when I conceptualized the idea in words and posted a prelude to it on my blog. The idea then developed further on in discussions with Aurko, Shubham and Manish.

I developed a very basic prototype of the idea (I learnt Ajax during this development phase) but it was looking very amateurish. About the same time, I got hooked on to using Google Reader and following increasing number of blogs and the realization that information overload was a potent problem also started taking root in my mind.

Finally in the summer of 2006 when I was in London and Hemant in Geneva, we met for a 5 day long Swiss tour and during the journey we finalized what we were looking for. Thoughts on our Google Reader habits, information overload (which both of us were experiencing), our canned idea of newspaper-of-blogs amalgamated into the first product spec for bloozle (a name which we came up with over the GChat brainstorming session soon after).

Soon after I came back from London and Hemant back from Geneva, we recruited* Manpreet – one of my engg college juniors – to do the core development. Manpreet, the amazing programming brain he was, created the complete website from scratch – including a basic set of JavaScript libraries with cross-browser compatibility, the core PHP based API engine for the feed reader and aggregation routines, and the front-end in HTML+JavaScript including the webpage designing in Photoshop.

... to be continued