[dematz]

Probably a lot of comments will bounce off the title to discuss the XY problem in general, and especially stackoverflow. The article does claim to go further than XY though!

"Diagnosing the ask" and "When they’re missing the philosophy" seem to me like traditional XY problem answers - the user doesn't know what the right question is, we need to step back to guide them.

"When the product needs to change" on the other hand is about figuring out what users want in order to add it to the product. Which takes a lot of figuring out, because it adds debt and you can add things the wrong way. This feels much less condescending to me than traditional XY where it's just tech support for a dumb user. Instead now figuring out questions from enough users helps direct new features.

"When the right path is hidden" I think the text for this one could do more to discuss helping direct the product as well, specifically in terms of documentation, if https://perfetto.dev/docs/getting-started/periodic-trace-sna... exists why is it hidden instead of where people find it when wanting to visualize a long trace.

If you read the title and just want to talk about XY eh fine, but the article's last sentence is the difference, "Both sides almost always walk away with more than they came in with."

[tzs]

In the particular case of SO what is annoying is that even if the person who posed the X question really did actually have a Y problem and responders figured that out and solved Y, that doesn't help people who really have an X problem who come there later.

When people who really have an X problem find that every SO answer to X questions is an XY answer and try to ask a new X question clearly stating that they have looked at all those other questions and none of them answer X...their question gets quickly closed as a duplicate by the idiots that moderate SO.

[atoav]

The solution to this type of problem is typically escalation.

I have worked in IT support and the problem is that the vast majority are problems of users who won't read even the most basic instruction, error message or hint. That means two things (1) users suck at describing their problems ("My account does not work" which could mean anything from a full network fail to them having forgotten their password) and (2) actual technical problems where something really is the fault of the tech are the minority of cases.

This means when someone says their account doesn't work that could mean anything from the utterly absurd like their laptop being broken, over hardware failure (broken patch cable), all the way to actual technical problems like their email address containing an umlaut and being parsed wrong, and it wasn't a problem till the last update. Since the dumber reasons are much more common your issue will stay at the dumb level until you convinced someone it needs an actual technician to look at. And the best way to skip to that level quickly is to do your homework, make sure the rest of the reasons aren't it and communicate clearly what is working and where things fail and how that failure presents itself. Basically by not coming across as one of the dumb reasons as much as you can.

In my whole IT support time I have probably received one well-written request.

[locknitpicker]

> This feels much less condescending to me than traditional XY where it's just tech support for a dumb user. Instead now figuring out questions from enough users helps direct new features.

I don't really agree. I think the blog post tries to put together a case that a textbook XY problem is not a XY problem because they explore a way to force Y onto all users seeking X. It's still condescending to accuse users of being confused and asking the wrong questions. It doesn't make it less condescending if they can claim success in persuading users to give Y a try.

A fairer and better way to frame this is to claim they avoid introducing changes to the service by convincing users to accept tradeoffs, such as tolerating a less than satisfying solution today than waiting for an acceptable solution tomorrow. At the end of the day users still do not get what they want. That is a problem, not a reason to pat themselves in the back.

[ncallaway]

I don't think that's it at all.

If a user says: "how do I do X in your product", I think a response of "Hey, there's not a great way to do X right now. We're thinking about the best way to make that work in the product though, and want to better understand what you're trying to do and why you need to do X. Would you mind spending 30-45 minutes talking to us about your specific needs in exchange for a $XX incentive?" strikes me as very different from what you're describing

[locknitpicker]

> I don't think that's it at all.

Quoted from the blog post:

> *Instead, the confusion that produced the wrong question is itself an opening, and the conversation it sparks is valuable to both sides. The user walks away with a better mental model of the tool. I walk away with a clearer picture of where the product confuses people.*

The blog post clearly frames the user as a confused individual who, by asking for X, has a bad mental model and requires guidance to be directed towards Y.

It's not only terribly condescending, it also spins the problem as an issue caused by ignorant and clueless users.

And it's a textbook example of a XY problem.