20 comments

[ 3.5 ms ] story [ 41.8 ms ] thread
(comment deleted)
(comment deleted)
While this strategy is fine for clueless users, I suspect that it will lead to immense frustration for the ones with clues
People who really have a clue add enough context in their request to understand why they are trying to do the thing in question.
There's a fine line here when dealing with customers. Sometimes it works well to answer the exact question, if you can, and follow up with "Can you tell me a bit why you're asking so I can understand a bit more about the problem?" Once you tease out a bit more about how they got there, it's often possible to offer better solutions and it never feels like you blew off their original ask.
“well the answer to your immediate question is X but that’s a pretty strange thing to ask for because of reason Y. Can you tell me more about the wider problem you’re trying to solve?”

This is the right way to answer these questions. SO was famous for the infuriating "You shouldn't do X, so as a favor to you I'm not going to tell you how." or "Before I answer thee, thou must first answer me these questions three!" kinds of answers.

Edit: Don't want to take credit for this. It's a quote from the article.

I believe this is the process that defines Julia Evans' writing (and cartooning)!
This isn't a black-and-white tactic. If you do this with people who know their stuff, they will just take it as you undermining them.
> If you do this with people who know their stuff, they will just take it as you undermining them.

That's because they realise that other party is simply trying to answer the question they wished was asked instead of the question that was actually asked.

Domo is now apparently "Governed Data for AI Agents".

The desperation for commodity services and second-tier products to stay relevant is widespread. See also intercom.com "The only helpdesk designed for the AI Agent era".

The funny thing is, this works well with people too. Not to literally not answer, but dig into the question or problem they bring up to understand their mental model and whether there was just a miscommunication or an actual disagreement.
> with people too

I'm pretty sure the article is about interacting with people.

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."

> 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.

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.

And sometimes, I get some bloviating idiot who DEMANDS that my question is a XY issue, constructs their own strawman, and solves THEIR strawman.

No, I had a reason why I asked the way I did. You're just too arrogant and think only your procedure is the "right" one.

I do want to clarify my point of view since there does seem to be some interpretation which I didn't entirely anticipate (wholly my mistake):

1. I'm not claiming that every interaction with a user needs to be turned into a full discussion. There are lots of cases where the answer is "this is what you're looking for, here's a link to the docs". In my experience, this has gone down a lot over time because people tend now to rely on AI much more heavily for those sort of questions in the first place so they won't even reach you. But it does happen and in that case, the best thing for both sides is to point to the documentation and move on.

2. If I am going to employ this strategy, I always try and both give the direct answer to the question and, as a separate point, ask them the context. Quoting directly from the post:

> well the answer to your immediate question is X but that’s a pretty strange thing to ask for because of reason Y. Can you tell me more about the wider problem you’re trying to solve?

3. This does necessitate that you are in some sense an "knowledgeable" on the problem space someone comes to you with: I would never employ this strategy in an area I didn't already feel I was quite well equipped to give my 2c on.

4. If the person I'm speaking to I know for a fact is already knowledgeable on an area, I would be very hesitant to use this approach because I try and be charitable with assuming that people generally know what they are talking about. While yes, I'm not going to be perfect every time in judging this, I think you can get a pretty good sense from the way they ask their question and how clearly they respond to your initial answer whether they are not (ties to 3 as it requires you are good enough in the space to judge this).

5. If someone pushes back, I will always defer to their read of the situation, I'm not here to make people do what I suggest, I will simply say "well I think you should do/not do A because of B reason but at the end of the day your call" and leave it at that. I think it's a good thing to be able to have respectful discussions on topics even if both sides agree to disagree.

This is in many ways what user experience designers might call "the five whys". People don't express their problem in the form of a problem, but a solution they've thought of. They don't say "I'm hungry, find me a way to get food" they say "I need a ride to the grocery store".

I always teach designers to remember that users and stakeholders aren't software designers. So we should pay careful attention to their problems, but not assume their solution is the right one (though it can be).

Getting these questions answered without insulting the requester (especially stakeholders) is an important soft skill. You have to make them feel heard, intelligent, and supported.

> there isn’t an easy way to do that, but what’s leading you to collect traces large enough to want to split?

That's basically every first Stack Overflow answer. It was obnoxious then, and it's obnoxious now.