Product Design - K.I.S.S.

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.