Skip to content
Tech News
← Back to articles

Don't answer the first question

read original more articles
Why This Matters

This article emphasizes the importance of understanding the underlying needs behind user questions in tech support and development. By focusing on the real problem rather than the surface question, engineers can foster better communication, improve product design, and enhance user experience. This approach encourages deeper engagement and continuous improvement within the tech industry.

Key Takeaways

In my work on Perfetto, a performance debugging tool, one question I get often is: “how do I split a Perfetto trace into multiple files?” Instead of answering directly, I say: “there isn’t an easy way to do that, but what’s leading you to collect traces large enough to want to split?”

This is one of my golden rules at work. When a user asks me something “weird”: don’t answer the first version of the question.

On the surface this might appear like I’m talking about the XY problem, but that stops one step short. It treats the user’s stated question as a puzzle to decode: figure out what they really meant, answer that, move on. I think we can go much further.

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. And sometimes, between us, we figure out that the product itself needs to change.

I’ve written before about how I can still be a successful engineer while avoiding the spotlight. While that covered the general strategy, this is one of the concrete tactics that makes it work. I should also say this post is aimed at people who build things for other engineers. If you’re building a consumer product, or a B2B service, it will translate less directly, but the underlying instinct might still be useful.

Diagnosing the ask

Some questions are easy, routine, and purely a matter of pointing at documentation; those don’t merit much discussion here. The interesting cases are where something is out of the ordinary, and it’s rare that the user will have given me enough information in their first ask.

So I run a mental checklist to figure out where to go next:

Have I seen this before? If so, I might already have an answer to hand. If not, it’s uncommon enough that I want to slow down.

Does the question even sound reasonable compared to others I’ve seen? If not, why might they be asking it, and is there a more normal question underneath?

... continue reading