Product Development Mistakes Bloozle – the Startup that never was - Part IV

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

If the service is not ‘personal data service’ (like email), then one should try providing as many features as possible, without requiring users to log in/register. Registration and Login is a big barrier in enticing new users (especially non-techies) to try the service out. If you cannot provide the service without registration, try to provide screencasts and previews or even better, guest logins (slideshare does that!) for new users.

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