3 ms·

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

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 15y 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 15y 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.
  - revorad 15y ago
    I'm aware of the "different 20% for everyone" problem, but I thought I qualified my statement enough to make that obvious.
thematt 15y 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.

revorad 15y 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 15y 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.
- revorad 15y ago
  I'm aware of the "different 20% for everyone" problem, but I thought I qualified my statement enough to make that obvious.

thematt 15y 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.