Skip to content
Tech News
← Back to articles

Don't Answer the First Question

read original more articles
Why This Matters

This article highlights the importance of engaging deeply with users' underlying needs rather than just providing surface-level answers. By exploring the real motivations behind questions, developers can improve their tools and foster better understanding, ultimately benefiting the entire tech ecosystem. This approach encourages more meaningful problem-solving and product evolution, which is crucial for innovation and user satisfaction.

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