Product Management - Feature Creep

One thing I am becoming acutely aware of while developing products is that feature creep can kill a product on many levels. Equivalent to scope creep in a project, if it’s not managed carefully or specified properly, it can get seriously out of hand.

I would much rather see our team produce high quality products that focus on a few key tasks, rather than lots of features that are all half baked. If it’s the latter the product becomes -

• Frustrating to use for the customer.
• Frustrating for the support staff to train users.
• Hard for the sales staff to believe in the product, or “stand behind it” with the conviction that there is no other solution but ours.

To combat feature creep – introduction of features needs to be formailsed and signed off on in key areas in order to minimise impact. These areas include:

1. The specification stage
2. After a review during development, after a “Change Request” has been submitted by key stakeholders. If accepted (that is, signed off) with additional costs approved, it should be written back into the specification. The development team should be appropriately notified.
3. After a product has been released, once again using appropriate Change Requests.
   

Change Requests are necessary to level out those “heat of the moment” ideas that seem like a fantastic idea at the time, but when revisited may seem more like a “what was I thinking?” brain fart. They give all involved parties an excellent tool for evaluating why the change is good (or bad), and what’s needed to get it happening.

Other types of feature creep such as developer “Gold Plating” also need to be managed. If a developer wants to introduce a nifty feature they thought of over the weekend, they need to first sell it to the stakeholders rather than compromise the final product – get them excited about it, and treat it as a form of up-selling. Ultimately it’s just the software development way of saying “would you like fries with that?” with an accompanying explanation (in the form of a Change Recommendation) of why it’s good for the end user – and putting a positive spin on charging a little extra for your efforts instead of trying to fit it in to existing project requirements. In developer utopia, it would be fantastic, especially if the client always agrees wholeheartedly. In reality – developers aren’t salesmen and not always able to cope well with rejection, so this easier said than done. This is where the production team needs to develop a good relationship with their sales team; another topic altogether.

Unfortunately it all sounds very formal and time consuming, but it’s a necessary evil to ensure the quality of what you’re delivering, both to your customers (it’s usable) and to management (it’ll cost you this much time and money to change, that ok?).

Keeping it all together

A challenge I see ahead: – many products developed for specific things (hence keeping it simple) means there needs to be some level of interoperability between them all, or at least some of them. Be assured, there will be many as time passes, and you’ll need a way to get data or files from one app to another with minimal effort. This is especially important when keeping everything in the big picture.

Web services makes this conveniently possible these days, and once again Google is the poster child in this so far with their Google account as far as a good model to follow, where one account gets you into their entire product offerings. Once you’re in one of their offerings (e.g. Gmail, or Adsense, or blogger, etc.) it’s entirely focused to the task at hand – but it’s easy to get from one application to another. They’ve even gone so far now to open up an API called GData (http://code.google.com/apis/gdata/) to allow information to be moved about. In my opinion Microsoft’s “passport” was poorly implemented – but, so was their entire online product offering except for hotmail, which was bought anyway. Hopefully they get it right with Microsoft Live.