Not the words you want to be hearing from your users if you are a developer on a web site or application. Unfortunately it happens more often than you would think. A fantastic new feature is dreamed up and added. It’s tested thoroughly, it looks really good, it will save heaps of time. But no one uses it. Why? Because it isn’t needed.
Its an easy trap to fall into and I don’t always think its the developer’s fault. I’ve seen more than few cases where the analyst has misunderstood (read: not correctly identified) what the user needs and that has been translated into code by the developer. You also tend to get users that want things that seem like a good idea at the time (to them) but isn’t something they will ever use.
A good way to avoid this situation is to follow the advice from Getting Real, a free eBook from 37 signals, the company behind BaseCamp and Ruby on Rails among other things. In the chapter on feature selection, they point out that you should Start with No. This might seem harsh, but it makes perfect sense. Every feature you add is a burden. It requires ongoing maintenance. As suggested in the book, you should look for trends — reoccurring requests before you add something new.
My basic strategy for adding a new feature into a web site or system after it has gone live is something like this:
- Is there a workaround for the feature?
Yes -> don’t fix it.
No -> Next question.
- Has the feature been requested before?
Yes -> Next question.
No -> Say no (nicely). Don’t fix a system used by hundreds/thousands/millions of people just because of one request.
- Is this feature going to be difficult to implement?
Yes -> Say no (nicely) based on the difficulty. Wait for it to come up again.
No -> Next question.
- Does the feature add value?
Yes -> consider it. Make sure it is given a low priority for now. Wait for more requests for that feature before moving it up.
No -> Say no (nicely) due to more important priorities.
This my seem quite harsh, but it helps to reduce the amount of new features you are adding to a site or system, and lets you concentrate on fixing up any existing bugs.
Unfortunately this won’t always work if you work at a relatively large organisation where you generally have to do whatever is requested. However, you can still try to apply this approach. Remember every feature you add is something you will potentially have to support and maintain in the future …