“We’ll add the bells and whistles later”. Sounds familiar? Do we hear this? Probably yes and especially yes if you are into product development or implementing solutions.
I have been using this.. no.. I have been told this quite a few times and I have always found this phrase interesting . As usual (nature of mine), thought of doing some research to understand the who’s and why’s behind it. Wondering, who would have invented it? And that too under what circumstances !! As Etymology is for words.. is there something for idioms and phrases?? I don’t know (and if any one does, please do let me know). Bells and whistles basically refers to the additional features which are attractive but may not be show stoppers.
In my opinion, it’s this concept of bells and whistles, makes the job of product managers /owners (or equivalent) quite challenging. In the competitive world, your offering needs to have something attractive, some USP that differentiates it from the rest. Lets ignore the price factor for time being. If your product also does what others in market do, why should anyone buy yours? Therefore there is always pressure from the marketing side to put all those in the product ASAP. While the story in the development end could be different. Often the approach there is to get the architecture right, the basic product function and then move to the additional ones. And this does seem logical method of moving ahead.
The software development cycle has also evolved over the period of time. The design, user experience, quality etc. is factored in at every stage. So whatever comes out as draft /prototype/internal releases tend to be like near final /package-able item. Thus lot many features, including aesthetics, are already part of the product. The concern is what it takes from being near-final to final. Is it only the bells and whistles??
The product manager has to deal with all the problems which economists have been trying to define and propose theories to resolve the same all these years. Some famous economist has said “Human wants are unlimited and means to satisfy those are limited” [Point to note here I tried to figure out who exactly said this. I vaguely remembered Alfred Marshall. However couldn’t get any concrete result. Maybe my search terms were not appropriate]. Likewise the user requirements are unlimited, and the budget, resources and time to develop the same are limited.
So who decides – what are must-have features (from a final product perspective) and what are bells and whistles?? From a functional perspective, the USPs may not be show stoppers, while from a market perspective, USPs matter the most. On the contrary, there could be some features which will make the product comprehensive and a long term bet, but there’s no demand for it as yet. So should you make only what limited needs clients have or be prepared for future or give something to clients which even they haven’t thought of??
The product manager is now in a tug of war, and in fact being pulled from more than two stakeholders. Well I know that’s their job. A product manager can no longer be only a technical or the domain expert. They need to have some market sense, some futuristic vision and lots of judgemental skills. The success (and also the failure) to a great extent depends on the ability of the product manager to drive the product (and that’s true for any entrepreneur)
A product manager has to be like Lord Krishna in the battlefield of Kurukshetra. Not fighting the war himself, but directing the people and making things happen. Driving the chariot, motivating the Arjun’s and ensuring that the dharma wins (i.e objective is accomplished)
I actually don’t know what made me write about the product managers this time. Guess, it was more to acknowledge and appreciate the efforts which I have seen my colleagues put in while playing the role of product manager. Kudos to all. While I have liberally used product manager, this saga is true for anybody who in the position of taking decisions, motivating the teams, and charting out the path of success.
Simply me 