This comment is at the heart of so much that is wrong with modern software: > Which features of our software are people using, and where do we need to concentr

This comment is at the heart of so much that is wrong with modern software: > Which features of our software are people using, and where do we need to concentrate the most with our limited resources and bandwidth to provide our users the best possible experience. That a team of product managers and UXers can answer this question even half correctly with a bunch of metrics and A/B tests is one of the biggest fictions of our time (not to mention pure arrogance). Talk to your users, or better yet be serious users of your own product. > What are the biggest build- and run-time errors, and are they a result of the developer experience, and can we fix this through either better documentation or better error messaging. Invest enough in quality so that users see errors so rarely that they get in touch directly when they do. > What are the paths to successful adoption of our software, and can we nudge potential users (through documentation or developer outreach) to get on one of those paths. This is an anti-pattern. Your adoption is irrelevant, only the utility of your software and user happiness matter. If those things aren't compatible with you making money, you shouldn't make money. Using telemetry for this purpose decimates the already weak value of telemetry for improving your software. If you are building applications with telemetry for this purpose, please stop. > We polled our users and they said that they want feature A, but our usage data shows that a vast majority of our users need feature B to be more successful faster. This is the height of arrogance. Quite incredible that anyone would think like this. I would immediately end the relationship with any provider who believes that their usage data, of all things, is enough to reliably decide that the users don't know what they want and need and the provider knows better. > Our software is used most often with other-tool-A. Can we strike up an agreement with the team that makes A, in order to give our users a better experience when integrating both tools through documentation, tighter API integrations, etc. The level of telemetry required to know not only how I use your software but what other tools I'm also using is quite terrifying. Pretty much total surveillance. Try talking to some users instead.