IT Product design when left in the hands of the developer tends to include everything the programmer, or the team thereof, is capable of accomplishing. As a result the product tends to have many Swiss Army knife type features, but lacks any real cutting edge, since the development time gets distributed around many small features while the main functionality does not get enough attention to be robust and mature (read fault tolerant, adaptible, portable, et cetera.) The latest technology article on HBR, Feature Bloat succintly discusses this phenomenon and its cures:
1. Consider long-term customer equity and not just customers' initial choices.
2. Build simpler products.
3. Give consumers decision aids.
4. Design products that do one thing very well.
5. Use prototypes and product-in-use research.
The fourth tenet above deserves special attention: focus on the one functionality that the product was conceived for in the first place; for should it fall short at its core, no amounts of bells and whistles can rescue the product from the consumer's ire. Imagine a cell-phone with a 10 Mpix camera but without battery life or talkability.
The Pareto Principle too should be kept in mind: 80% of the work gets done in 20% of the time. Blame it on beginner's luck, blame it on the freshness of the work, but it is very true. What you, as the manager, should NOT want is for your team to spend a single moment of that valuable 20% time on features that are not central to the product.
Lastly, one thing the manager should learn to avoid is giving in to the whims of the programmer. As such it is great to have very talented, experienced and innovative team working on a project. Such members are most likely to have ideas about what features can be integrated and each developer will have ideas based on his / her experience / ability. The more of them there are, the more the gizmos that will get added. DON'T fall for it. Keep the fourth tenet above and put away early add-on ideas; work on them later if they mature in the time it takes to have the core functionality up and running.
And always remember one evergreen principle of software design: Keep It Simple, Stupid!
Note: This blog is not meant to be against product complexity - due complexity reflects well formed requirements gathering and testing processes. Such complexity is in fact desirable compared to simplistic design. The blog and the article cited concern the utility, not the internals.
3 comments:
i agree with the points about the product developement and features the produce wants to include in their product.
But when anybody tries to sell his product in the market amongs the competetors, he have to take care of the features that he is going to include in the product. if i am a customer i would like to buy a product with as many features as possible when the price offered to me by any producer is somewhat same. we can see the products focused on few features in the market at the same time we can see those products have less competetors as compared to products which have many features and they have a brand also. It is true that one should look for customer loyalty and satisfaction in a long run but what if the customer is not buying your product initialy.
well all these things depend on the product and market segment targeted and many other things.
yes... keep it simple is the mantra for any new pdt... be it technology or fmcg...
and also the single functionality bit, in today's day of competition doesnt hold true. i mean u have to give the consumer something more than just extra battery life (read example abt cellphone). look at all the models today, they all have similar battery shelf life, but how much memory and what Mpix camera decides the final sales figures...dunnit?? unless u happen to be the minority that lives by the basics...
yes, you are both correct, but a camera-phone doesn't compete with a basic cellphone and neither competes with a pda or an mp3-player phone (characterized by a good codec and a load of memory) and so on. so while bells and whistles may take different shapes, the camera-phone example is not an exception to the KISS principle.
Post a Comment