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

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