Every once in a while, one finds oneself in a discussion over an important topic, having an opposite view as that of a colleague, friend, or family member. This is almost never a bad thing in my view. In the business world, for instance, I would not enjoy being in an organization where no one challenges my views or where I cannot challenge others'. Theres one aspect of such discussions, however, that I try to avoid as much as possible. It is best illustrated with an example.
Lets say I am having a discussion with Joe (a colleague) about the features of our new consumer electronics device. Now, lets say that I maintain that including a certain feature is not justified as it is an advanced feature that we've found is unlikely to be used by most of our users. Joe retorts with "Thats not true! My mother-in-law, who is not at all tech-savvy, regularly uses (and loves) this exact feature in our competitor's product". Hence, I must be wrong and Joe must be right.
While the flaw in the above reasoning should be obvious, its astounding how many times, as a product manager, you will find yourself in a discussion like this. Furthermore, this problem is often exacerbated by the HiPPO (Highest Paid Person's Opinion) effect during product reviews.
Its critical for you to identify whenever you are in a discussion of this nature and take steps towards ensuring that it doesn't lead you to the creation of a crappy product. To counter the threat of anecdotal evidence, follow this recipe of questions:
Does this increase product appeal and/or value?
If yes, does this increase the complexity of the product?
If yes, do the current metrics (quantitative, qualitative, or both) justify this complexity?
If yes, can this be built such that it doesn't adversely affect other, more critical metrics?
If yes, build it. If not, wait until the next version of the product and ask these questions all over again.
Note that I am not suggesting that you ignore input or anecdotal evidence. However, I find far too often that product managers (especially those new to the field) don't say No at the right time. By following a consistent evaluation process - with the underlying strategy of keeping things simple - you can avoid building a crappy product.
