Sanity Check for New Product Features

From "Cutting Through"

Here’s a simple technique to use on a regular basis as a ‘sanity check’ for the technical requirements of a development project. The idea is that you guard against the tendency to load the system with glamorous - but unneeded - features that will increases the risk of project failure.

The process is extremely simple:

1. If it’s not already been done, write out the functional specifications as a numbered list of requirements.
2. Do the same for the business requirements that were identified in the earlier stages of the project.
3. Take each functional requirement in turn and cross-reference it against one or more business requirement. At each iteration, ask yourself “what business benefit does this feature deliver?”
4. If there are any functional requirements that can’t be linked to a business requirement, ask yourself if it’s needed - and be very sceptical of the anwer if it’s “yes”.

The idea is simply that each and every feature of a system should deliver some value to the business - if it doesn’t, you’re in danger of building in flashing lights for the sake of it. And there are numerous dangers with that approach:

• The system will take longer to develop.


• It will become more complex to use.


• The internal interactions between features will become more complicated, and unintended consequences will become more likely.

This technique is just the “keep it simple, stupid” approach put to work. But in virtually every organization there are development projects that have gone wrong because of feature creep and its consequences - so this is a technique that’s simple enough to be done quickly to try and guard against these kind of disasters.