Should you include a much-requested feature that is fundamentally wrong?

Question

In our main product, we've got a feature request that's been around for a couple of years now that's been requested quite a few times. It's technically easy to implement, the problem is that it will fundamentally change the concept of what the tool does, and will likely cause more bug reports as people mis-use the new feature to match the new concept (which we won't be able to work around). We've got a separate feature that works around the issue quite well, but we still get requests to implement the new one.

Should we

• listen to our users, and implement the new feature, even though it changes the concept of what the product does and what we want it to do, and will increase support costs
• add some more support articles explaining how to use the workaround
• make the workaround more obvious in the UI so the users find it more often
• something else

Answer 1

Implement it as a plug-in.

• It will be available for users who really want it, but won't fundamentally change your product.
• Most users won't end up installing it, so your support base will be smaller.
• It won't get in the way of users who don't use it.

Answer 2

I would try to re-design the UI for your work around to make it easier and more obvious for your users. At the end of the day, the customer pays the bills so we have and obligation to meet their needs. When what they ask for will cause more problems, it comes back to us to offer a different solution such that we don't create more future bugs, and we still keep the customers happy.

Answer 3

It's almost impossible to answer this, as we don't know exactly what you're talking about.

Having said that some points:

• The number of users who actually want the feature, probably are far higher then you think, as most users will never log feedback.
• You describe a 'workaround', this implies your product either has a problem, or it's UI needs to change.

I'd be inclined to implement it, as this will make your customers happy.

An option would be to give them a menu option, which directs them to both methods.
Possibly a wizard of some sort, which helps them decide which workaround to use.

Answer 4

Define "our users". Is it 5% of your user base, 80%, 95%? Have you surveyed enough of them to find out if this is something that the vast majority of the users want, or is it just a rogue group of users (they can be the most difficult and hard to please).

I think that needs to be established first. If it's the majority of your user base and it adds value in their eyes, then I would try to reach a compromise where you meet in the middle, not compromising the integrity of your product, but still offering the customer an alternative solution that would still meet their needs.

Answer 5

Announce the workaround as the solution to the request to those who have requested it. Make the workaround more prominent in the UI / easier to use.

Answer 6

I would go with whatever has more potential ROI. Will you increase profits by implementing this feature? If so, does that exceed the cost of supporting the new feature? If potential profits are greater than your support cost, I'd suggest going with the feature.

If there is no gain to be made either finacially or by lowering costs for support, then it makes no sense to do it.

Answer 7

If you don't implement the the feature as a plug-in, I would do as you suggested and fix the UI. Also I would not refer to this as "workaround" for your users. Calling it the "correct workflow" or something similar would leave a better taste in their mouths.

"Workaround" sounds too much like a bug.

Answer 8

While not a programming question, I've seen quite a few people over the years struggle with this type of issue.

You need to ask yourself a few questions

1) Have you, or management, done a cost-benefit analysis? Ask yourself "How will the feature.."

• increase sales? i.e. will more people buy it
• decrease sales? i.e. loosing customers that are put off
• impact customer service?

2) If the product will change radically - would it make sense to spin it off to an entire new SKU?

3) Management will get what they want in the end. Do you want to work with them to provide your customers the best experience possible & be the hero, or against them and look for other opportunities.

Answer 9

If this feature runs counter to the philosophy of your product, it indicates that the product does not conform to the mental model of your users. The consequences of that are much larger than just a single missing feature. You need to get inside your users heads, and figure out how to adjust your model to their expectations, or guide their expectations towards your model.

Put enough thought into this and it could become a great opportunity for you.

Answer 10

In 'The Mythical Man Month' (which you have read, haven't you?), Brooks says words to the effect that 'conceptual integrity of the architecture is the most important thing'. That means that if the requested feature breaks the conceptual integrity of the overall design of your product, you probably should continue to avoid implementing it, regardless of how much it is requested. Or, you need to reshape the architecture so that the requested feature fits into the revised architecture.

One of the products I work on has a 'much requested feature' that was added. It behaves unlike any other feature in the product. It is a horrid wart. But since the competition does it, we had to do it. But instead of remaining true our architecture (which happens to differ fundamentally from the competition's in this area), we aped the competition's feature, down to silly details.

I still bitterly resent the fact that the feature was botched into the system with broken semantics w.r.t the rest of the product. To rub salt into the wound, I had to present the new feature as the 'greatest thing since sliced bread' to our customer base -- that really hurt.

Having said that, no-one has complained (as I think they should) about the feature. It probably gets used sometimes. It is one less difference that the competition can use against us.

(And note: I was not against the feature being implemented in a style consistent with our product's normal way of working; I was only against it being implemented in the style that our competition uses - because the other related features work analogously to the broken implementation in their system, whereas our system is more sane and friendly.)

It's tough. Sometimes the market wins out.

Answer 11

I'd go with a simple guess at the cost (in terms of usability) versus the benefit, at least as a major factor to weigh. For example, if the feature will likely help 45% of users but make the program harder to use for the other 55%, don't do it.