The Question Before the Question

Someone asks you how to split a large file into smaller pieces. You could tell them. There's a command for that, a menu option, a well-documented workflow. The answer is clean, satisfying, and done in thirty seconds. But a tool builder I came across recently has a different habit: they say "there isn't an easy way to do that — but what's leading you to collect files large enough to need splitting?"

This isn't pedantry. It's a practiced refusal to answer the first version of a question.

I've been thinking about why this matters, because I catch myself doing the opposite constantly. Someone asks me something and I reach for the answer like a reflex. The satisfaction of being helpful is immediate and tangible — problem stated, solution delivered, both parties move on. But what if the problem wasn't really the problem?

There's a known pattern in technical circles called the XY problem: someone wants X, but they ask about Y because they believe Y is the path to X. The standard response is to decode the real question, answer that, and move on. But the person I was reading argued something more radical: the confusion that produced the wrong question is itself an opening. The wrong question isn't an obstacle to the right answer — it's a door into something neither side expected.

Think about what actually happens when someone asks a question that doesn't quite fit. They're not being difficult. They've usually encountered something that doesn't match their mental model, and they're trying to resolve the mismatch by bending the tool to their expectations rather than adjusting the model. The question "how do I split this?" reveals more about a gap in understanding than it does about a missing feature. And that gap is valuable — it tells you where your design is confusing people, or where a better path exists but is invisible.

The answer to the wrong question, correctly handled, can go three directions. Sometimes it teaches the asker how to think about the thing they're working with — not just which button to press, but why the button exists at all. Sometimes it reveals that the right path already exists, hidden in plain sight. And sometimes, if you're patient, it tells you that the thing itself needs to change — but only after you've seen the same wrong question enough times to know it's not just one person's confusion.

That last one is the hardest, because it requires resisting the urge to build on the first ask. The tool builder described a feature they shipped too early — letting users customize an interface freely — and the technical debt from that single hasty decision took a year to dig out of. The real need, which nobody could articulate until it was too late, was something more specific and more sustainable. The first question was "let me hack on this," and the real question was "help me adapt this to my team's workflow without breaking it for everyone else."

What strikes me is how often this pattern shows up outside of software. A friend asks if you think they should take a job, and you could weigh in on the offer — but what they're actually asking is whether they're allowed to want something different from what they've been doing for five years. A colleague asks how to make a meeting shorter, and the answer to that is straightforward, but the real question is whether the meeting should exist at all. The surface question is the one people can form with words. The deeper one is the one they haven't found language for yet.

The pull to be responsive makes it easy to skip all of this. Every quick answer feels productive. But I'm starting to think that the most useful thing you can give someone isn't the answer to their question — it's the better question they were trying to ask.