# A feature request hides a need
Understanding · diagnostic · https://build-here.africa/book/chapters/04-02-a-feature-request-is-not-the-problem.html

## 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 does not know what it 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 solution proposed by someone who knows their problem better than you do. It is often a good one. But "an export" can hide a monthly check, a transfer into another tool, or a format requirement. Those three needs do not call for the same work.

Ask about the final use: what do you do with the file, right after? The answer sometimes shows a smaller solution. Sometimes it shows the requested format is a real constraint and your shortcut will not do. Either way, you build the right thing.

Acknowledging means saying the request is understood and when you will answer. That is all.

The move holds everywhere: asking for a meeting, a form or a document is already proposing a solution. Ask what it will be used for.

## Check this

On a request in front of you, 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 real constraints and one possible answer. After the first use, compare the result to the expectation. A little-used feature can still be useful: some operations are rare and important.

## To discuss

Which recent request changed once we asked what it was for?