I do a lot of email support, and I find lots of examples of the XY problem masquerading as a feature request. [1] Someone will ask for some feature - and usua

I do a lot of email support, and I find lots of examples of the XY problem masquerading as a feature request. [1] Someone will ask for some feature - and usually its easy to add - but I try and understand the root problem first. Mostly they don't tell me the problem, they tell me their solution. This is often either a bad approach or a flat-out wrong approach. Implementing it "as asked" doesn't help. The only way for me to add a feature elegantly, and to documentation in a way that will be useful to others, I to understand the root pain it is fixing. This also makes it easier to sell. "Identify the pain. Make it go away" is a powerful sales technique. Lastly, sometimes the pain is internal - the Sales team need it fixed, not the customer. Some features get added because -decision makers- think its important, and it demos well, although we know full well that customers will never actually use it. [1] https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem