It is very often that we find ourselves analyzing metrics and coming to the same cross-roads, do we remove this feature because it's not needed or do we change the way it's presented because it's not found. What techniques do you employ to determine if a feature's low usage is due to poor discoverability or because the end user doesn't care to use it.
If you have feature requests, complaints or questions on your forum or even public places (StackExchange, Quora etc) from your users asking for solutions to problems that normally should already be solved by the implemented features, then you need to rework that part.
If you have very low usage with no requests then it is safe to assume is not something widely needed, at which points the problem simplifies to how much effort it is required to re-implement it or rework that part vs the benefits.
Another way to do it, is during user testing. Try to create scenarios involving that specific feature and see what happens. If people spend too much time looking for a way to solve the problem then you are in a case of "can't find". If people find it fast enough or you have issues in actually creating a user scenario involving that feature than you are in a case of "don't need".
In case user feedback is not available
It is quite dangerous to simply decide in removing functionality without having the usage information from your users so I think a better focus for your resources would be towards improving the existing use cases and workflows that are making use of that particular functionality. Working on workflows might show you if you really need it or not, if it can be replaced, if there are workarounds or how to improve it so it is easily found and used.
But really, you do need the user feedback to ensure your efforts are going towards the right functionality.