Webyantra is slowly evolving into a discussion forum for product design & strategy with regard to web based products. This is a modified version of an earlier post (from my personal blog) about key lessons I have learnt in designing and building web products.

For the last two years, my primary role has been to lead the product development team at my startup. We have built two web products, both of which are unique, one-of-its kind. The first of these is a user research software solution for the B2B space, while the second is a Web 2.0 social media sharing application in the consumer internet space.

It’s been two long, hard, grueling years of relentless, uncompromising and serendipitous product development work. This post is a wrap up of my key learnings during this period. You could think of these as design principles, work practices, or simply some observations about the Web 2.0 space, that I would like to share with the readers of this blog. I must add that, all these learnings are experiential; they are based on the mistakes I have made and the lessons I have learnt.

I have learnt that…

Design is a Differentiator

Good design is a big differentiator; it sets you apart from your competitors, it puts you in a different league. It could be any aspect of the product design- the visual design, the process design etc. A great designed product ensures that you define the industry standards and others play catch-up. The example of Apple is a case in point.




The UI is the Software

This may sound preposterous to many, but for many a web 2.0 product, it is true. For the vast majority of users, the software is defined by the user interface. Their impressions (and thus their verdict) of your software are hugely influenced by how they react to the user interface. It’s like the proverbial tip-of-the-iceberg theory where people see only the tip (the UI) and are blind to its huge base (the backend) that is its actual foundation. What this implies for new software products is that a disproportionate quantum of time/effort should be spent on the user interface.




Users are distracted

Users today are being bombarded with a deluge of stimuli; hence catching their attention is becoming increasingly difficult. Every day, they are being exposed to newer applications/products, all of which promise them the moon. The product that you built (after all the hard toil) is just one drop in the deluge. Latest research indicates that users are making like/dislike decisions for new websites in as little as 50 milliseconds! This has huge implications for how you plan to introduce your product to first time users.




Users are empowered

We all are celebrating the power of web2.0 with its emphasis on user-generated content. However web2.0 is not necessarily good news for product companies; for it has hugely empowered users. Every user now thinks of himself/herself as an amateur journalist, a photographer or a movie shooter- thanks to user generated content. Users are in the driver’s seat. As a result, they don’t want to hear your sales pitches or go through long product demos; they want to interact directly with your product and make their own judgments. Designing a product for this web 2.0 generation of users is a different ballgame altogether.




The requirements document is dead

Agile web application development and its growing popularity means that the traditional model of software development with its emphasis on the requirements document is getting obsolete. Product development is increasingly being seen as an evolutionary and flexible process with actual user feedback influencing product design, as opposed to the rigidity of the requirements document model.




The only certainty in life is death, taxes & DESIGN CHANGES

This is a corollary of the above learning but it is more internally focused (within the development team). The team has to be made to understand the logic behind frequent design changes that the agile product development process entails. They need to appreciate the fact that design changes being affected, are not an outcome of management indecisiveness; rather they are necessitated by changes needed to the product based on feedback from users.




B.Y.O.M (Bring your Own Money)

This is different from the generally understood benefits of bootstrapping. I strongly feel that if you are self-financing your product development (as opposed to being financed by private equity), you end up making a better product. The is because when you are financed externally, product design decisions start getting influenced by external revenue and profitability deadlines (often set by your equity partners). Instead of making the best product, you (probably) end up making a compromise product that is geared to meet revenue deadlines. My experience tells me that you should have the freedom to restructure/redesign parts of your product at any stage (based on user feedback). This freedom/flexibility is usually not afforded by an externally financed model.




K.I.S.S (Keep it Short & Simple)

Keeping it short and simple is possibly the most abused product mantra. In a technologically overloaded environment, your product should be great at doing something, rather than be good at doing everything. Every new product feature adds complexity, costs and confuses the users, so one has to be very stingy in adding any new features to your product. The 37Signals philosophy of ‘building less’ explains this best.




Prevention >>> Cure

Early stage user testing works live preventive medication. While this has always been understood, it assumes special significance in an agile development model. Letting users interact with early product prototypes not only throws up bugs, it also gives fundamental insights into product design inadequacies that would otherwise surface only when the product has been launched.








Welcome the Devil’s Advocate

Many of the successful Web2.0 software products are coming, not from software companies but from ‘fringe’ players like web design studios, usability companies, media companies etc. This shows the importance of having people from diverse backgrounds participate in product design decisions. Such people tend to act like the devil’s advocate, asking the right questions and being a safety net against the tendency of software engineers to ‘geek out’ with the product development. In my own startup, we have a mix of people from different backgrounds (i.e. cognitive psychology, software engineering, marketing & market research) and I think this has helped us tremendously.




Execution is all that matters

Finally, it is always the execution that matters. The product idea, by itself, is nothing; the devil lies in executing the idea really well. As the saying goes, success is 1% inspiration and 99% perspiration.