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

http://support.toggl.com/discussions/questions/289-what-do-you-mean-in-the-section-notes-by-will-be-deprecated-on-nov-1st-2011#comment_9929078

by RegEx • 15 years ago

55 43 15 years ago

support.toggl.com

ambirex• 15 years ago

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).

jonnathanson• 15 years ago

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%.

tlholaday• 15 years ago

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

owenmarshall• 15 years ago

If somehow I ended up spending an inordinate amount of time performing ramp maintenance, and if the presence of ramps made it difficult for me to install an escalator or an elevator, I'd yank them in a heartbeat.

Having a bunch of features isn't always good, especially if the features are half-baked, require constant attention, or impede more useful features.

davvid• 15 years ago

(I think) the parent poster was making a subtle reference to access for handicapped persons when he made the ramps vs. stairs comment. I believe his point was that there are times when keeping a seldom-used feature is the right thing to do.

It's probably not the best analogy, though. Maybe if this discussion were about alt tags on images then it would make more sense.

jemka• 15 years ago

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.

pointyhat2• 15 years ago

You should have not implemented it to start with :)

scott_s2• 15 years ago

I don't think that's fair. You don't know how useful a feature will be until its implemented and in users' hands. You will have a guess, of course, which is why you implemented it in the first place. But you don't know. And surely, a certain percentage of the time, your guess will be wrong.

pointyhat2• 15 years ago

Unless you ask.

jasonwatkinspdx• 15 years ago

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!!!"

revorad2• 15 years ago

That email analogy is flawed. Even though most emails don't have attachments, most people use attachments sometimes.

If really only 5% of your users are using some obscure feature and it's getting in the way of other improvements, then you should probably deprecate it unless those few customers are disproportionately more valuable to the business.

jeffdavis• 15 years ago

"If really only 5% of your users are using some obscure feature and it's getting in the way of other improvements, then you should probably deprecate it unless those few customers are disproportionately more valuable to the business."

I disagree, in the general case at least. For one thing, you need to decide the granularity of "feature". It can be anywhere from the entire project to a single line of code. It can actually get even more specific when you start talking about combinations of things as a "feature".

If you try to apply a "only 5% of users will use this" rule to any significant project, I think it will quickly start to feel incomplete. Users can tell. They develop expectations about the features that should be present in a certain class of application. When they come across a need for the feature, even if very minor, they will be very frustrated if it's not present. That frustration will destroy the user community.

Another thing is that often software is bought in bulk for an organization. The accountants will demand support for X in the standard software package, and IT will demand Y, and pretty soon you need a full-featured product. If you say "only 4% use X and only 3% use Y", and eliminate both, then you've just lost an entire organization worth of users.

If you're a startup or have a new product, then I'm not saying you need to reach that level of maturity before 1.0 release. But when your product gets big, you will need to invest in this kind of completeness.

thematt• 15 years ago

Interesting, but I think it's a slightly different metric. The email example is 95% by volume, whereas the OP is 95% by users. Even though they don't use the feature every time, most people have/will use attachments at some point, so by removing it you'll impact almost everybody. If only 5% of the entire user base is/will use Project Notes, it may not be as big of a deal.

nknight• 15 years ago

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".

TomOfTTB• 15 years ago

I don't understand why they wouldn't just level with their users. Explain to your users that each feature costs money to maintain and almost no one uses this paticular feature. Then ask those who use the feature...

1. If that feature is essential to them

2. if they'd be willing to pay a little more to keep it

I find most people are very reasonable when you explain exactly what the problem is to them.

marquis• 15 years ago

Completely agree. We've been in this position before and worked with users to find a solution where they paid a premium for us to offer support in a difficult environment.

grsites• 15 years ago

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.

RegEx• 15 years ago

I'm an avid Toggl user, and I've never used the project notes before, nor have I felt pressured to by the interface. The notes feature is completely unobtrusive. It takes a few clicks to get to it.

Mavrik• 15 years ago

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.

mstroeck• 15 years ago

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.

tomkarlo• 15 years ago

If 5% of users utilize a feature, and it's pulled, you're going to lose a fraction of those users. Being afraid to lose a few users sometimes leads to horrific swiss-army-knife products where the existing users are placated but you lose new users to some simpler product that comes along and covers 50-70% of your use cases but has a much simpler and more efficient UX.

I've seen this firsthand too many times: the loss of users when removing a feature is more concrete than the gain in simplicity (particularly because new users are generally not well represented in feedback vs. old users) so there's paralysis over removing features that just never really got traction.

patio11• 15 years ago

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."

PotatoEngineer2• 15 years ago

So if I'm using that app, I'd have to check the developer blog, or some "news" section, every week just to see if one of my favorite features might get axed? It sounds like a really annoying thing for a user.

jellicle• 15 years ago

I think the parent comment is suggesting something like, in a new version of the software, doing this:

-- remove the button for the feature, replace it with a "Give me back my feature!" button

-- when the "give me back my feature!" button is clicked, send a GET request to mydomain.com/theywantedthefeatureback.php , and give them back the feature button

-- look at your server logs to determine whether anyone actually uses the feature

This is no big hassle for the developer or the user and it will tell you rather quickly whether anyone actually uses feature X.

Jun8• 15 years ago

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.

AgentConundrum• 15 years ago

More people use "I'm Feeling Lucky" than probably realize it. I don't know how it is today since I've got so much stuff wired directly to keywords on my install now, but it used to be that if you typed a non-URL into Firefox's address bar, it would run an "I'm Feeling Lucky" Google search for you. I think they changed it a few versions back, but many people (myself included) messed with the 'about:config' page and got it back. HTTPS-Everywhere seems to mess with this though. I should fix that.

esrauch• 15 years ago

Whether you want an "I'm feeling lucky" button is completely independent of whether you can have a browser feature that does a similar thing (though I just checked and it looks like the default for chrome is to direct you to a full search)

npaquin• 15 years ago

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.

mattm• 15 years ago

> 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.

Monkeyget• 15 years ago

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

pbreit• 15 years ago

I wonder if that might be a myth? It appears that Office has probably peaked and is losing customers to less featured offerings like Google Docs.

JLFamous• 15 years ago

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.

measure2xcut1x• 15 years ago

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.

BadassFractal• 15 years ago

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.

true_religion• 15 years ago

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

latitude• 15 years ago

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.

PotatoEngineer2• 15 years ago

When do you remove the feature entirely? Or do you just discourage users until, at some future point when a change breaks it, you don't get any complaints?

MattGrommes• 15 years ago

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.

mynameishere• 15 years ago

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.

mapgrep• 15 years ago

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.

JustAGeek• 15 years ago

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.

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

Related Stories