To Feature or not to Feature? That is the Question (Never Asked Enough)

On my first day of work at Microsoft as a PM six years ago, I sat down with my first manager for our first one-on-one and at the end she asked, Are there any questions? I said yes -- one last one: "When do we decide to remove features?" -- Garry @ Posterous

That's a question that definitely is not asked enough in the field of Product Management - particularly with regards to Online. We spend all our time trying to get developers to cram more features into a product and then wresting with designers to make sure these features are accessable to the public that one of two possibilities is bound to occur:

The feature is designed and implemented but caused project slipped due to the addition of this feature or
the feature is built but is not thought out completely, not implemented correctly, and hence - never used.

In my job at TayaIT whenever there is a new product or feature suggestion I always make sure to ask one question: Why? Why should we implement this feature - what value does it add to the user, what value does it provide to our system, Why? If a sufficiently good answer can be provided to this question then we can start moving into the feature vetting stage - and start analyzing it in detail. Whats important here to note is that immediately at the moment of feature conception and / or presentation - we question their validity immediately - if it can pass this very simple test - only then does it begin to go through a three stage process which will validate the feature as viable to be implemented within our product:

Alignment with Product Value Proposition: How does this product effect our Value Proposition? Is it in line with our VP? Does it add value to our Existing VP? Does it add additional VP's that are in line with the original VP? All of these questions need to be asked between the marketing team and the production team and they need to come to a consensus with regards to all of the above questions.
Graceful Implementation: So now you know that yes, this feature will add value to the product that is in line with the direction that the product is moving in Because - and this applies particularly to features being added to an existing product - your original design didnt incorporate these features - you need to ask yourself whether truly, this feature can be gracefully added to the existing product without unnecessary overhead - perhaps it requires a UI overhaul in order to be accessable, or major changes in order to add value? These things should not be assumed but confirmed with your design and development team.
Cost Benefit: Sad but true - at the end of the day - we are all in business here - so the final question that must be asked is what is the cost of implementing this feature in terms of Person Hours vs the actual benefit that this feature offers (note the use of actual here vs implied benefit - here we discuss the value of a feature from a User's perspective) Is this a feature that only techies / developers are interested in? Or does it add real value to real people (not that developers arent real people ;) their just not the average user. Remember that any issues that were discovered in the previous stage here may add or remove from the cost of the feature.

At the end of all this a proposed feature now has three ways it can go - Yes we absolutely need to have this feature it totally alignes with our Value Proposition and will be a cinch to implement - Not now, Shelve it for later review, Not now, get rid of it. Note that more likely then not a feature is more likely to be shelved or tossed then implemented - and I think thats an important thing for product managers / product owners to realize - "we have more features" is an argument iv heard all too many times, and I cant remember a single time that it was made by a company that had too many other arguments to make.

I was talking to my AIESEC trainee the other day about innovation in the field of product management. He wasn't impressed with the fact that we weren't coming out with ridiculously innovative features (crazy login boxes and the like). My response? People keep thinking innovation is about coming up with the snazziest way to do something or a completely new product idea that has been never done before. Yes - thats innovation, but its probably 10% of innovation. Why? Because 90% of innovation lies in taking an existing idea and implementing it better. And one of the best ways to do that? Take something and make it simpler.

Building a complex project is easy.

Building a complex project that is simple - that's tough, and that's where the creative thinking is required.

This post was inspired by an absolutly great post by Garry (Quoted Above) titled "Practicing Product Minimalism" Definitely worth a read!