* No one seems to use American express, so let's remove it from payment options. Turns out, the site had a bug that made sure 100% of AMEX transactions would fail. By fixing, we picked up 6% in sales, and lost a UX associate who was (and probably still is) arguing to drop AMEX because analytics.
* Since very few people actually click the apply button on the job board, let's remove the apply feature. The idea was we could send candidate profiles to employers based on views instead of apply clicks. Had to revert this one.
* Same company: let's take job posts out of our mobile job search app because most interactions end on a job post (and a click on the apply button). Best ticket the next day, "I can't find any jobs in this job search app?"
* No one uses the UI customizer (dashboard colors, fonts, and preferences). 100% of the tickets the next day were from people who were PISSED BEYOND BELIEF that we removed their favorite feater. Turns out the customizer basically was invisible to our app analytics. Had to revert this and re-do two sprints of work because the other new features wouldn't work with the customizer.
In 100% of the cases, talking to actual users would have been beyond wise before using analytics data to make decisions.
It seems the telemetry-driven product development in the past decade has made significantly worse apps than in previous decades. There are definitely a higher quantity of apps on a wider variety of platforms, but it seems harder to find apps that are powerful enough to allow a wide variety of users to do all the things they need.
The general lesson in your examples isn't that telemetry isn't useful, but that telemetry gives an incomplete picture.
Would the AMEX issue have been found without telemetry drawing attention to it?
It's hard not to see the recent sale of Audacity and the introduction of telemetry as the beginning of the end of an otherwise stellar piece of software.
People made "product decisions" before the internet.
I just generally dislike this trend of putting telemetry in every singe application, it sets a bad precedent and can easily be abused by less principled developers (especially for closed source software) in order to syphon data for all sorts of purposes.
That's an unproven assumption. More information does not lead to better decisions, it just leads to more confidence in those decisions (whether justified or not).
People still pull numbers and assertions out their asses all the time. That doesn't mean it is, or was, good.
Designing good telemetry is hard, interpreting the data well is harder (and it's tempting to cherry-pick post facto to justify your decisions). Are users not using functionality X because it's useless or because there's some other issue preventing its use? Or maybe users just don't know that it exists?
Crash reports are more of an unmitigated good IMO however, since they can be used to pinpoint the source of crashes and identify regressions.
The biggest problem facing any use of data is quality of the collected data. For example, if you wanted to train a model but all you had were examples of a particular class... well, you excluded yourself from being able to predict any other class from the git-go. Data collection itself require a deep understanding of statistics and probability. Otherwise you’re just shooting yourself in the foot.
But let’s be honest, machines don’t “learn” things, people do. Machines have no teleology they determine for themselves.
People are both the problem and solution. Anyone who thinks big data and ML will be able to generate the answers are deluded and have already turned off or lost completely their critical thinking skills.
Data collection in the form of telemetry is only a mechanism for finding solutions and an incredibly INVASIVE one at that.
From personal experience, I've always had more insights into actual usage patterns from sitting next to a random user for 30 minutes than I could have had from heaps and heaps of telemetry.
That being said – even if they had communicated transparently and discussed openly – if their goal was to get good telemetry maybe self hosting allows more users to trust you, and therefore you receive more telemetry? Because the overlap within the venn diagram of users who trust Audacity and users who trust Google/Yandex will always be considerably smaller than the overlap of people who trust Audacity and people who trust Audacity.
2) No you don't.
Considering sharing user data with some cloud service is reckless enough to cast a serious shadow on a company's intent and morality, even without an actual GDPR breach.
This is floss were talking about, so budgets are a factor.