Should you deprecate a feature untouched by 95% of users?

The value of a feature is frequency of use * impact to those who use it. Cutting a feature on frequency alone will lead you astray.

Comment #13 on the OP says it very well (aside from english errors):

"I bet 95% of all emails sent across the world doesn't have any files attached. Let's remove the ability to attach files to emails!!!"

If you were to hypothetically say "We're killing X" and that didn't cause a nightmare for support, I'd take that as an extremely strong bit of signal regarding how important X and X-like things were. By the same token, words like "This feature seems to me so important that I don't think we can live without it" (direct quote from customer!) are solid gold for directing future priorities. Dave McClure suggested pre-emptively killing a feature every week just to elicit responses like that. That seems both a) valuable and b) cheap to do, since saying that X is on the chopping block is essentially free. Heck, you could wire up an A/B test with a "Got a problem?" button right next to it, and it wouldn't take you more than ~5 minutes.

If you're building a time tracking software and your customers are using it to do project management... you might be in the wrong business. Something to think about.

It is, of course, possible that folks paying you $12 a month get very attached to one particular thing. $12 a month does not buy you a whole lot of development priority, to put it mildly. It is occasionally necessary to tell them "Nope, sorry, it appears that we're not the best fit for your needs."

It reminds me of Joel Spolsky's 80/20 myth article.

"80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it's never the same 20%. Everybody uses a different set of features." http://www.joelonsoftware.com/articles/fog0000000020.html

Depends on how important that 5% of users is to your product and your business. Also depends on whether the feature is a credibility indicator of some sort (i.e., it's seldom used, but people like to know it's there and/or will think less of your product if it's not).

The Pareto Principle comes into effect here. If the 5% of users adopting the feature are your most important customers, or if they're bleeding-edge users or opinion leaders to the other 95%, then it's worth keeping them appeased. On the other hand, if they're users you neither care about nor need, then consider whether the feature is extraneous -- or, worse, whether it's actually annoying the 95%.

This is why you should always carefully consider what features you add to your product. It is always easier to add a feature than to remove it (even if it is only used by 5% of your users).

Would you remove ramps because 95% of your visitors climb the stairs?

Only after testing to determine the issue. Perhaps the other 95% don't know how to use it, how useful it is, or even what it is.

If the issue is truly usefulness, and keeping/maintaining the feature could negatively impact the majority of non-users, then deprecation is warranted.

I know exactly how to handle this as I did it before and it worked really well.

1. Make sure the feature can be completely hidden from the UI.

2. Add an option somewhere in Advanced section of Preferences that toggles the visibility of the feature.

3. Turn the feature off for all new users and keep it on for all existing ones.

4. If it is possible to detect whether the feature is used by an existing user, then if it is not used, show one-time message saying the feature is being turned off and how to turn it back on if needed.

That is it. Graceful deprecation.

In defense of these guys:

1. The feature is highly tangential. The core product is a time tracking app. A time tracking entry (core) can be associated with a "project" (metadata), which in turn can have "notes" (metadata about metadata). These guys built a time tracking app and ended up maintaining, in a dark corner inside of it, blogging software (functionally speaking).

2. This is the sort of feature that just grows and grows. Already we've gone (guessing here) from what was a project note to "notes" plural. Someone presumably had to figure out how to sort the notes and how to delete a note, etc.

Next the users will be asking for text search. After all, if you have 100 notes on a project, with people using them as a repo of project knowledge, search is kind of a basic feature, don't you think?

And it would also be nice if there was a pretty archive view with a nicely formatted calendar so you could easily go back in time without clicking through endless pages of old notes.

Oh, can we have RSS feeds per project, too? I'd like to see when there's a new note.

Oh, also, we should be able to attach an image to a note. Pretty basic.

Hey, if we can attach images why not videos? Can we embed tweets, too? Audio? Will you support HTML5 for my iPad AND Flash so we don't have to transcode to ogg for Firefox?

Oh and this text entry form is looking a little, hmm, primitive, could we add WYSWIG controls?

Etc. etc. They are smart to nip this in the bud when their product is still young, IMHO.

Important questions about that:

* How many users are 5% (there's a difference between 5 people and 5000 people)?

* How critical is this feature to them (Meaning: Will they drop our product if we remove it? Or just be slightly annoyed?)

* How much money do we make off these users and how important are they in public (will they cause enough bad will to form via ratings/blogs to affect further sales?)

Think, analyze, ASK.

To answer to the question in the title of this submission:

You should not. As soon as a feature has got released to all users of a software, you won't be able to disable it without some users becoming really dissatisfied.

The solution is not to release a new feature to all users.

Before even thinking about releasing a new feature, first ask yourself:

What is the goal of this new feature?

The answer to that question is your hypothesis, you need to try to answer by experimenting. That is, perform an A/B-test:

Launch the feature to a subset of your users and check if it achieves its goal. This goal must of course be measurable and ideally there are KPIs that you can use to check the success or failure of your experiment.

When the experiment is successful you deploy the feature for all users. If the experiment fails, you remove it for the subset of users and the rest will never know about it.

This also helps the codebase to stay clean, features not making it into the product, is code not making it into your codebase, which means less code to maintain, less complexity.

> We aim, though, to only deliver features that have exceptional value to everyone, and drop everything else.

Personally I think this aim is where they're going wrong. It's unreasonable to think that all your features are going to be used by everyone, much less have "exceptional value". If it's not causing much maintenance, why not just leave it in? Why go through all this trouble?

This feature is notes which isn't completely unrelated to their app. I don't use their app but something they could do is just make it less noticeable if they really don't want people using it for some reason.

Quick answer: No. The best example is Google's I'm feeling lucky button, which a very high percrntage of users don't use. But turns out people still want this feature. Marissa Meyer had a discussion about this.

I don't even know what they're talking about, but I'd wager 95 percent of Microsoft Excel's features are never used by 95 percent of its users.

What if they set it up in such a way where you could either upgrade your subscription or pay a one time fee and have it enabled for your account? Maybe give a trial for new users to see if try want the feature? That might take care of the "5% of users" and maybe bring in some new revenue.

I'm not quite sure if it'd work how I imagine but, if it could work, it sounds like a pretty good idea.

The way I handle this problem with my web app is to quietly move highly unused features to a state where administrators can still use them but customers can't see them. I let them hide there until I'm satisfied that there won't be a problem removing the feature permanently. I have not had a "roll back" request to date.

The other thing to consider is to ask whether the presence of this feature is obtrusive or bothersome to the 95% who don't use it. Does it needlessly clutter some user interface? If instead it is mostly invisible to those who don't use it, then there is little harm is leaving the feature where it is.

Maybe the question they should be asking what did they do wrong with this feature that only 5% of people are using it. Maybe it's hard to use? Maybe it's hidden in the UI? There are other potentially fruitful ways of looking at this question other than people just don't like or need the feature.

5% is actually pretty huge. Here's my simple heuristic, I call it the Income-Loss-Wince-Factor: How would feel about a 1% decrease in income next year? How about 5%? 22%? Ouch.

Also could keep in mind the loss in revenue to your company if you were to cut that feature. If the 5% users is paying all of your bills, then you need to be careful.

I did that and still now months later that 5% hasn't ceased to complain about it.

The metric is invalid on its own, and in Toggl's case, potentially disastrous. 5% use it? Who are they? What if a big chunk of those 5% are managers? What if the 5% is concentrated in your biggest customers?

Without a lot of research and care, you could potentially lose more than 5% of users with such a move.

And what happens if they find another feature that only 5% use? And another?

"Rarely used" is not the same thing as "not essential".

You should have not implemented it to start with :)

I'm aspiring to work at Microsoft so I'd probably opt to make that unused feature the most prominent one in the next release.