I like that thought however let me add one point to it: if the metrics used to measure are not what the user is measuring then there is either a set of missing metrics or Apple is looking at the wrong set of metrics.
Some metrics are easier to measure than others. If you try to WiFi sync an iOS device and the connection fails, it might not be that easy to tell why it failed. When something crashes, it generates a crash log. Federighi explicitly mentioned in the podcast that the crash rate (of Apple's apps) was lower in iOS 9.0 than in any version of iOS 8. This was thanks to the public beta of iOS which was first offered for iOS 9 which gave them many more crash reports (and other user-provided bug reports) than they got from the developer betas in previous iOS versions.
Reducing the number of app crashes is certainly a worthwhile goal but certainly not sufficient on its own. Another example that came up in this thread is home sharing. It is certainly possible for iOS (in beta versions but also shipping versions) to record failed attempts at connecting to home sharing. But when it fails, the fault might not lie in iOS or in anything particular to the iOS device at hand. It might lie with iTunes, with the networking stack of the Mac or PC hosting it, or with the WiFi router (or a combination of several factors). While the user might have enabled the iOS device to send Diagnostic & Usage data (in Settings under Privacy) that might not be enabled on the Mac; privacy rules might also prevent the data of those two devices to be matched by Apple. But even if that were not a problem, if the user has experienced problems with home sharing before, she or he might have largely given up on it and thus her or his devices wouldn't report any problems on home sharing back to Apple. Apple can try to account for it (but at some point might run into privacy limits) but if those people with configurations that run into trouble with home sharing do not even try to use at all, no feedback can be sent back to Apple.
But for sure, Apple can improve its metrics and changing the metrics might one of the most important elements in an attempt to improve the user experience but there are limits to how much change can be done in a given amount of time and given external circumstances (eg, how successful Apple is in attracting and retaining programming talent). One such circumstance is an existing code-base that dates back to days when the cloud was much less important (Google's background is certainly much more cloud-centric both in terms of code as well as programming talent). This is just to say that there are things top management can change relatively quickly and easily and there are things where it is much harder to affect change.
Note that all of the above is referring to software quality. Software design as in user interface and functionality is yet another topic.
[doublepost=1455409043][/doublepost]
But for someone like myself (50GB library) iTunes and Apple Music are very poor pieces of software.
My iTunes library is 450 GB though only about 120 GB of that is audio, the rest is movies and TV shows. And while there can be some slight sluggishness (on a 2012 dual-core laptop), I can hardly call it a very poor piece of software.