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

Asked 9/12, 2009 at 18:32 Answered 9/12, 2009 at 18:42

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

Stretto answered 9/12, 2009 at 18:32 Comment(8)

Assuming you are asking about a commercial product, are you really going to make a commercial decision based on what a few random people on the internet, who know zilch about your product, think? If not, this is not a real question. And it is also not programming related. – Spherule 9/12, 2009 at 18:35

But is something that programmers (especially in small companies and OSS projects) will come across, and have to deal with. – Stretto 9/12, 2009 at 18:39

I am sorry to say, programmers do not make product level decisions: a product manager does. – Keener 9/12, 2009 at 18:40

@jldupont: Depends. I've made product level decisions as a developer (it's a small company), and this is very likely to happen in OSS projects. – Commentator 9/12, 2009 at 18:42

In small and mid-size companies (at least those I've worked at), programmers contribute to product-level decisions all the time, and in many cases implicitly have the final say. – Eshman 9/12, 2009 at 18:43

You know, reading the question, I really wouldn't recognize an answer as being correct. I'm voting to close as "not a real question". – Commentator 9/12, 2009 at 18:44

What kind of feature is technically easy to implement and fundamentally changes the concept of what the tool does? :boggle: – Nicholle 9/12, 2009 at 18:48

@Jeff in fogbugz it was the ability to report fixes/developer/time - which turns it from a bug tracker into a HR tool – Solomon 9/12, 2009 at 18:59

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.

Maliamalice answered 9/12, 2009 at 18:35 Comment(2)

According to Joel, Fog Creek added plug-ins to FogBugz for precisely this reason. That way ancillary features can be implemented as plug-ins without them having to fundamentally changing their product. – Reservoir 9/12, 2009 at 18:39

More importantly, implement it as a plug-in that you can charge for. This way the feature becomes a revenue stream as well. Balance the cost for the plug-in to put off casual users who would be "misusing" the feature, but accessibly priced for users who have seriously considered why they want to do things in this alternative way. – Commit 9/12, 2009 at 18:47

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.

Onassis answered 9/12, 2009 at 18:32 Comment(1)

+1 I experience this everyday. Just because someone else does it one way, does not mean you need to do it the same way. There are many ways to skin a cat – Scintillometer 10/12, 2009 at 2:10

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.

Innutrition answered 9/12, 2009 at 18:32 Comment(2)

+1 Good point. Users will make or break you. However, the customer is NOT always right. – Scintillometer 10/12, 2009 at 2:10

They're not always right, but they're always worth understanding. If their thinking is different than yours, that's a dangerous gap - either you should be modifying your thinking, or figuring out how to get them to understand yours. – Innutrition 10/12, 2009 at 3:37

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.

Cody answered 9/12, 2009 at 18:39 Comment(0)

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.

Menon answered 9/12, 2009 at 18:32 Comment(0)

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.

Mcmahon answered 9/12, 2009 at 18:38 Comment(0)

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.

Adriel answered 9/12, 2009 at 18:32 Comment(0)

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.

Byzantium answered 9/12, 2009 at 18:40 Comment(1)

It's in the top 5 most requested features – Stretto 9/12, 2009 at 18:44

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.

Triboelectricity answered 9/12, 2009 at 18:40 Comment(0)

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.

Formation answered 9/12, 2009 at 18:42 Comment(0)

Recommended topics

Hot tags