Stated another way, distinguish observations (facts) of a story from the inferences--don't dismiss the observation/facts when rejecting inferences. This is analogous to an XY problem.
I have the role of "chief troubleshooter" in my engineering group. I have a bit of a nervous tic that forms when I hear absolutes like this.
Don't assume the customer is always an idiot. Don't assume ANYONE is always an idiot. It limits you as an engineer.
Listen to everything. You don't have any need to abide any of it, but listen to it all.
I've had some of the least-qualified people throw out something which absolutely ended up being insightful, although sometimes in a way they didn't expect.
Indeed. A timing problem was my first thought when I read the title which was obviously provocative, maybe that's because I deal with timing problems often so I got lucky there, but I rejected the idea, thinking the user would have noticed it too. Nope.
I used to do some help desk as part of my dev job, and from my experience, users easily assign any random fact as the source of the problem. Often things like "correlation is causation" or *post hoc ergo propter hoc" (after that, therefore because of that). Good as heuristics, but bad when they are substitutes for reasoning.
Users cannot diagnose at all because they have no idea of how the thing they are using works (which often normal - we are the engineers, they are the users) (in this regard, users that think they know "that stuff" are among the most difficult to deal with). One cannot properly diagnose something one doesn't understand well.
To me the moral of the story (and my experience) is: user's problems are usually real, but don't trust their ability to diagnose the actual cause.