2026-06-21: That is a Weird Question
There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question. - Carl Sagan
There are many kinds of questions (including, yes, unfortunately, dumb questions). Users will frequently come to you to ask you how to do something. In many cases, these questions will be perhaps direct and straightforward, both in their nature and answer. Underlying such questions, however, may be a deeper opportunity. A question asked (especially for the first time) about a novel way to use a capability or feature is usually a sign. If you are observant, these questions present to you an invaluable dual opportunity: to both set the user off in a better direction, and to use this as feedback to improve your product.
Redirection
Users have a very specific idea about the world they are operating in. This is perfectly reasonable, as most users are simply trying to get their job done. But it also means that they have framed their activities, their thinking, in terms of specific workflows, of specific capabilities, and specific features, of specific ways of doing things. Users, especially the good ones, often think of new ways to do things. But because they are blind to the underlying structure of the system, the architecture, the ways in which distinct features or capabilities might be used together, they often conceptualize ideas in terms of what they already know how to work with.
If a user comes to you and says "how do I set my car on fire?" you might take pause and question why they would like to engage in arson, rather than simply telling them what you think is the best approach to igniting the automobile. But if a user comes to you and says "how do I create specific per-drug per-claim plan maximums?" you might simply oblige them with the necessary configuration and so on. But if you pause for a moment, and consider the question itself, you might eventually come to the conclusion that such a thing is a bit unhinged. Why would a plan subject its members to this? Why are the maximums per-drug and per-claim? What is the goal of this arrangement? As you dig and dig, you might actually come to realize (as I did) that what was actually being asked for was a per-drug amount attributed to product selection penalty. What the user was asking for was not what they wanted after all!
Despite the two outcomes being, in aggregate, mathematically equivalent for the patient, implementing the penalty as a plan maximum hides the fact that it is a penalty. It is a maximum masquerading as something else! Perhaps that does not matter initially, or now, but does this matter in the future? What if the plan changes the behavior of what happens when the plan maximum is exceeded, for example to reject such claims? Well, now all such claims reject! Or perhaps the plan would like the penalty amount to apply towards, say, the maximum out of pocket (but not amounts exceeding the plan maximum). This sort of category error is problematic because it can hide issues later, especially when testing for such things is not robust or adversarial enough.
Feedback
Feedback is decidedly not a gift. Real feedback almost always has to be discovered. It has to be read from between the lines. So when a user asks a question, especially a very direct one about how to accomplish some goal you have never heard of before, you need to read between the lines. You need to ask questions. You need to attempt to discover the underlying source of their question.
Consider the following: a user has come to you and requested a function to format dates in specific way in an outbound data feed. You could easily oblige the user, providing just such a function, that formats the date in the requested manner. But then the user returns next week, and this time they need a slightly different date format (perhaps the consuming system does not allow leading zeros on dates). You could of course continue to repeat this (there are probably about a dozen or some somewhat common date formats) or you could use this as an opportunity to enhance your product more broadly. To see the bigger picture, as it were. You could instead supply the user with a function that allows them to define their own date format! Then the user will only have to bother you about the format language (or you can just share the documentation of the underlying library with them).
We could think bigger, too. But bigger is not always better. What if we allow the user to write their own logic in a custom DSL? Then the user could do nearly anything. This of course sounds like madness, and your users will usually not be technically able to do so. The users will complain they do not understand this DSL.
But maybe this (in addition to the capability we already added to allow customization of the date format) is beneficial to you and the user. Because now you can provide the user with the correct code from your DSL, and the user can go about their merry way. They might even just continue to copy and paste this. The big bonus here is the user did not have to wait particularly long. Maybe the user is implementing a data feed, and the account team committed to having it delivered by March 1st, without checking if it was possible (or perhaps even reviewing the requirements at all). Now, an analyst is attempting to configure this format sometime in February, perhaps because they have been busy working on other things. If your DSL escape hatch did not exist, you would fail to deliver the report to the client. And I mean you, the developer. It is your responsibility (actually, everyone's) to delight the customer, and usually in spite of the deadlines that others have promised.
Of course, this can easily get out of hand. Users will just come and ask you for endless new functions, and say they need them today. The efficiency you gave them has now tightened their own turnaround time estimates, which they have broadcast to customers and the account team! The custom functions continue to multiply, and while they are more efficient than sending the task through the development pipeline they are decidedly less efficient than a native feature.
But! You can easily query your database for commonly used functions, and then build them out as first class features! This is a win-win.
All of this, because the user asked a simple question, and we took a moment to think, instead of immediately moving to execute.