The symptom
A customer asks for an export. The team ships it, but the difficulty they reported comes back. The team knows the file exists; it knows less well what the file was supposed to make possible.
The signal
“What are you trying to get to, and how do you manage without it today?”
What’s going on
A feature request is a proposed solution. It can be a very good one: the person knows their business and may already have compared options. Understanding their need lets you check that proposal, not tell them in advance that they are wrong. Behind an export there may be a monthly check, a transfer into another tool, or a format requirement. Those situations do not all call for the same work. The context, the frequency and the expected result change what has to be built.
A smaller solution is sometimes enough. In other cases the format requested is a real constraint and the shortcut the team imagined will not do. Ask for an example of the final use rather than deducing the answer from the name of the feature.
Acknowledging is not committing to deliver. You can say the request is understood and say when an answer will come. If a commitment already exists, say so before proposing a change, and have that change approved by whoever is responsible.
This move also works outside software: asking for a new form, a meeting or a document is already proposing a solution. On a first project, examining a single request with the person who made it lets you practise without launching a full study.
Check this
On a request within reach, ask two questions:
“When do you need it, and what do you do with the result?”
“How do you manage today, and what causes the trouble?”
Note the constraints confirmed and one possible answer, without promising beyond your mandate. Agree what will let you check the usefulness at the next use.
After that use, compare the result to the expectation. A little-used feature is not automatically useless: some operations are rare but important.
From where you sit
- Product: separate acknowledging a request from committing to deliver.
- Engineering: check the constraints before proposing a smaller solution.
- Customer relations: ask for an example of the expected result, without contesting the need.
- Operations: explain what has to happen after the export or the form.
To discuss
Which recent request did we tie back to its final use, and what did that change?