Some bugs, even quite severe ones, can seem to your users like very nice features. Bugs that are likely to reach this status are those that make work smoother at the expense of security (for example, not enforcing part of the permissions mechanism), faster by letting users skip steps that should be mandatory (for example, leaving fields blank) or simpler by making assumptions (for example, setting default values where a user should really be forced to make a choice). When you fix these bugs, your users won’t thank you. In fact, they might complain; as far as they’re concerned you just damaged their user experience.

It’s quite easy to determine if a bug is mistaken for a feature: if it’s a useful bug, the QA are using it in the same way as the users. You may even find that Technical Support instruct people to use it (especially where you accidentally provided some short-cut for procedures).

There are two things you can do with useful bugs: you can leave them (and reinforce the back-end, if you think it’s necessary) or – if they must be fixed – you can communicate with the users when you deploy the fix. For example, if you’ve just enforced the permissions mechanism where it was once neglected, add an explanation to the message that blocks the user about why this is suddenly happening. If you’ve changed procedures so that now they’ll take longer, make note of that when the user first starts the procedure on the new version. And if you’re no longer setting default values, explain why you thought it’s important that the user does this.