soo much this!
Sometimes a user might think they need feature A to make task B easier when in reality instead of doing B they actually want to do C but they never thought of it that way.
If you implement A, you take on maintanance burden when C would be way easier to implement and potentially much more useful for the majority of your users.
Isn't there a decent amount of psychology research showing this isn't the case. Not with happiness with a service in particular, but that we poorly report on our internal state and often are biased by factors that impact our self reporting but not our choices. What people say and what people do do not always align and thus it is possible for there to be a gap between what people want and what people say they want. If you try to meet the latter you can end up losing out to someone who tries to meet the former.
Now, that is research on average people (and particularly average college students), so when dealing with software developers talking about software issues it may not apply.
A typical story relevant here is that of a news site boasting about a rise in daily reads, where they define a read with being on a page for 3 seconds... that is clearly a meaningless number that maybe just means users are skimming through all your articles in hope that not all you have is terrible (could happen if you had some good content or a loyal audience)
And most importantly, even if my self-reporting isn't accurate, you don't know better, and telemetry won't tell you. If I say that I didn't press this button because it was red, you can doubt the accuracy of my report, but you don't get to conclude that my real reason was that the button was square and not round, or that it was on the left and not on the right. Or that the button is useless. Telemetry will only tell you I don't press it. Or perhaps you can run an A/B test to learn that I press the button when it's blue and round and on the right side (but you may miss the fact that I pressed it out of confusion, and reverted its effects three screens down the line).
Software developers are no different than real people, except that they have much more experience with computers - which means both familiarity with the UI and the ability to instinctively form a mental model of what's happening underneath, which sometimes leads us to intuitively avoid doing things that would break the application :).
--
[0] - https://wiki.lesswrong.com/wiki/Egan%27s_law
[1] - Plenty of motivations could be embarrassing, or weird. E.g. for a long time, I avoided using GNOME desktop and related software, simply because I had a visceral revulsion towards their logo, which featured a footprint. It's a kind of motivation that did affect me, but I wouldn't be too willing to reveal unless asked directly.
[2] - Also people sometimes report on motivations behind what they want to do, but not on the incentive conflict they're facing, and they then proceed to do something you wouldn't expect. This leads to silly arguments like "something is good because of revealed preferences", which latch on the difference between expressed preferences and observed behavior, completely ignornig the fact that observed behavior is heavily incentivized, essentially making people go against their preferences.
yes, but it does let you know where to place the ads and “special offers”
Disagree. User feedback, however biased or incoherent, is a direct representation of real people with real issues. Telemetry is a stream of context-free data from which you need to infer the hidden user feedback. Telemetry data seems to me to be much more prone to finding in it whatever it is that you want to find, or all the other failure modes that happen when people who analyze it have more skills in statistical tools than in doing science.
> Compared to direct user feedback where a user might use some functionality twice a year, but rank it high as something that needs to be improved because it's sort of backwards. Instead of improving the performance and flow of the functionality they use hundreds of times daily, because they're reasonably happy with how it works.
And all I want, all my life when using software, is for companies to fucking listen to that. If I say I'm reasonably happy with things I spend 95% of my time, then I am reasonably happy. I want you to fix the 5%-time case.
There's no direct relationship between how often you use a feature and how critical it is. To give a simplified example, when I'm using 3D Studio Max, 99% of my time is spent modelling, and only 1% (or less) is spent on saving the file. And yet, without that feature, I wouldn't even buy the program. This is of course a silly example, but most software has plenty of very important features executed very rarely (and some that are executed rarely because the experience sucks). Relying only on naive telemetry analysis is going to lead you to misprioritizing work on improving the product.