
Should you deprecate a feature untouched by 95% of users? - RegEx
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
======
jasonwatkinspdx
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!!!"_

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

~~~
revorad
I'm aware of the "different 20% for everyone" problem, but I thought I
qualified my statement enough to make that obvious.

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

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

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

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

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

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

~~~
owenmarshall
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
(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
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.

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

~~~
PotatoEngineer
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?

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

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

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

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

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

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

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

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

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

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

------
BadassFractal
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
I did that and still now months later that 5% hasn't ceased to complain about
it.

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

------
pointyhat
You should have not implemented it to start with :)

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

~~~
pointyhat
Unless you _ask_.

~~~
scott_s
Again, I think you're being unfair. What people say and what people do are not
always the same. People may say "Yes, that's a great feature!" and then not
actually use it when it exists.

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

