alt Hacker NewsI have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons to not implement the feature, but other times it makes me delete the whole reply and work on it instead because I have worked it out. Sometimes doing so ends up taking less time than writing the full reply. Often the feature ends up being even better than what they originally requested.
In contrast, if a user has been rude, entitled, and high maintenance, I may end up not even trying to reply in the first place because I know they’ll just be combative every step of the way, and giving them what they want just makes them demand more, seldom being appreciative. These tend to be users who want something a very specific way and refuse to understand why the thing they are asking for is profoundly selfish and would shit the interaction for everyone else to satisfy their own desire. So I don’t do it.
This has been a bigger sidetrack than I originally intended. I guess the moral of the story is don’t be a prick to the people you’re asking something from.
Replies
A variant of the first is the highly imaginative user who keeps coming up with new variations or expansions of their idea. It’s not malicious but it can be exhausting.
Especially if you try to address their core need but their imagination doesn’t extend quite far enough to see how your effort would help, because they love their ideas.
Due to the XY problem what they ask for often isn’t what they need. And what they yell about won’t make them happy.
By and large I’ve gotten better feature requests out of looking at patterns of frequently asked questions and turning them into tasks instead of reacting to negative feedback.
There are few things so valuable as a good user who is willing to work with you. Many years ago I worked at a company that was going to shutdown a very buggy product. There was one user who relied on it heavily and convinced the CEO to make one more release, and I was tasked with working with that customer to make it happen. Over the next month, we fixed the bugs (I coded, he tested). We wound up making a stable and more user-friendly product. It was a real pleasure to work with that guy. The company still mothballs the thing, but I know we had at least one happy customer in the end.