How I use a software is not an indication of how I want to use a software. It’s what I’m doing with the options the software has given. If I’m really lucky, I’ll be like everyone else, and an inefficiency in the software will be spotted and fixed so the software will be slightly easier to use. In practice, I’m just doing workarounds to accomplish things the telemetry won’t explain on its own; and even if other users would want to do these things, I’m one of very few actually doing them. So... I don’t really want to trade potentially a lot of personal information just for... I don’t know... to make it easier for developers to develop for the lowest common denominator rather than me?
"How I use a software is not an indication of how I want to use a software."
Exactly. The ergonomics of much software is pretty damn terrible with users struggling to get done what they want to do. Thus, developers who rely on telemetry only cement-in bad problems.
It's for this and privacy reasons I always turn telemetry off.
It's not even the options the software has given. It's the options you have awareness and recall of being given.
It's very valuable feedback to hear, "wait, it does that?" Yeah, we spend a quarter million dollars on a feature that our users don't even know exists.
"How I use a software is not an indication of how I want to use a software."
Sure it is. It's not a perfect indicator all the time, but can definitely pinpoint a common workaround users perform due to a lacking or unfriendly interface. It's just a helpful data point though, not a silver bullet.
I'm with you on the trust issues though when 90% of software companies abuse our data. Just another reason why we can't have nice things.
It really sounds like you’ve never worked on a product team that actually used analytics tbh.
> In practice, I’m just doing workarounds to accomplish things the telemetry won’t explain on its own
This is one of the most obvious things people are looking for in analytics. People will always use your product in unpredictable ways to get the whatever functionality it is that they really wanted. This is one of the things product managers are most interested in knowing about because they either want to properly implement that functionality, or they already have it and they want to know if they’re doing a bad job of getting their customers to adopt it.
It’s incredibly unlikely that you’re such an ultimate power user that what you want out of the product is so unique that you’re inventing your own usage patterns that others aren’t also following.
I completely agree that you should have the right to not share your information with anybody you choose. But if you choose not to share any information about your use case with the company that makes the product, then you don’t have much right to complain about it not doing what you want it to.
> It really sounds like you’ve never worked on a product team that actually used analytics tbh
Please don't cross into personal attack. You don't need to, it poisons discussion, and it evokes worse from others. Your post would be fine without that bit.
Analytics driven development is like flying a plane on instruments only with all the windows covered up. I mean, sure, you'll get there, but compared to flying normally you are missing out on so much.
Watching individual user sessions from session recordings provides more depth, but you are still missing out on great swathes of information.
Analytics and session recordings don't give anything near as much concrete data as taking the time to engage with your users. You then use analytics to confirm behaviour.
> Hum... On real life you would quickly discover how vulnerable all of your instruments are sensitive to both random and bad-intended interference.
Well no, commercial pilots have to be rated IFR. Flying via instruments only is completely normal and part of the training. Visual is perhaps easier for many people, but you lose the use of visual navigation in all kinds of circumstances, like at night, over the ocean, or in a storm.
Analytics driven development is a strawman. It’s simply one of many factors that can influence development decisions. Depending on the particular circumstances, it may be incredibly valuable, or not valuable at all.
> But if you choose not to share any information about your use case with the company that makes the product, then you don’t have much right to complain about it not doing what you want it to.
I generally disable the analytics in software I buy, but I do participate in surveys they send my way. Would that count for you?
Forums can also be a rich source of use case info for software developers who really care.
I haven't worked on a product that used analytics to drive feature development.
What you wrote here sounds very naive to me.
I might be completely wrong, but i assume if you have a large enough user base you would use telemetry only in an aggregated way, and then prioritize the majority of the user base. So I might totally be underrepresented but still have the same loss of privacy as everyone else.
I also feel i always have the right to complain about a product, publicly and vocally (it's just a different channel for analytics/telemetry, imo). Much like product owners have the right to just change it remove features that break my workflow.
What I have written here is based 100% on working with product teams who use analytics very competently to influence feature development (which is almost never driven by one single factor).
> I might be completely wrong, but i assume if you have a large enough user base you would use telemetry only in an aggregated way, and then prioritize the majority of the user base.
In some cases yes, but you need to get that aggregate data from somewhere. It’s also naive (and probably a bit arrogant) to assume that your requirements aren’t in fact well aligned with the majority of the user base.
This is however a somewhat immature way of using analytics data. There’s plenty of incredibly valuable data you can get from peculiar and unpredicted usage patterns. Any product manager will tell you that most customers are quite bad at expressing what they actually want. A good product manager can gather a fair amount of insight from what they choose to complain about, but analysing the most immediately obvious trends really only gets you so far. You’ll often get the most insight from the rare customers who are able to concisely articulate their feedback, and those that are frustrated and ingenuitive enough to subvert your application to their will.
For any motivated organisation, there’s countless ways to get insight out of their analytics. You’ve just described the lowest hanging fruit.
> I also feel i always have the right to complain about a product
Depending on where you live, you likely have the right to complain about anything you like. But if you want to prevent an organisation from analysing your usage of their service, then complaining about them not meeting the needs of your use case is hypocritical.
It’s also naive (and probably a bit arrogant) to assume that your requirements aren’t in fact well aligned with the majority of the user base.
No. In any high-dimensional space (in this case the dimensions are features used by a given user), the vast majority of the elements will be outliers in at least one dimension. Everyone has idiosyncrasies. It is arrogant to assume that everyone is the same as oneself.
