A Feature Request Is the Beginning of a Conversation

“Can you add a filter for this?”

That sounds like a reasonably small request. There may even be an obvious place to put it.

But before deciding what to build, I want to understand what the person is trying to do after they apply the filter.

Are they looking for someone? Preparing a report? Finding people to contact? Checking whether a program is working?

The answer can change the solution quite a bit.

I have become more careful about treating a feature request as a complete description of the problem. Usually, it gives us a useful place to start asking questions.

People describe solutions they can picture

If someone uses your product regularly, they become familiar with its building blocks.

They know it has tables, filters, tags, exports, and settings. When they run into a problem, they naturally describe an improvement using those things.

Could we add another column? Could this be included in the export? Could there be a new tag?

That is helpful input. They are showing you where the current experience stops supporting their work.

But the requested change may only solve the part of the problem they can see from that screen.

An export request, for example, might mean someone needs to share information with their team. It might also mean the report is missing a calculation, so they have to finish the job in a spreadsheet.

Those are different product opportunities, even though both arrive as “Can you improve the export?”

Ask about the last time

I find concrete examples more useful than general descriptions.

“What happened the last time you needed this?”

That question can uncover the sequence of work: where the person started, what they checked, what they copied into another tool, and where they got stuck.

It also helps establish frequency and impact.

Something that takes ten minutes once a year is different from something that takes ten minutes for every applicant. An awkward workaround is different from a process that regularly produces incorrect results.

Both may deserve attention, but they need different priority discussions.

I also want to understand who else is involved. Sometimes the person requesting the feature is preparing information for someone with a very different need.

Similar requests can hide different problems

Two customers can ask for the same feature and expect different outcomes.

Consider a request for more control over who can see something. One customer might be managing different groups within a program. Another might be trying to introduce a progression system where more becomes available as ambassadors participate.

A visibility setting could help both. But we should understand the difference before deciding how much flexibility to introduce.

The reverse happens too. Several requests that sound unrelated may point to the same underlying problem.

A filter, an export column, and a dashboard card might all be attempts to answer one question about program performance.

Looking at them together can lead to a more coherent improvement.

Discovery should lead somewhere

There is a risk of making customers feel they have to justify every request.

That is not the experience I want.

The purpose of the questions is to understand their work well enough to help. Sometimes that means building what they asked for. Sometimes there is an existing approach we can explain. Sometimes we need a different solution or have to be honest that we cannot prioritise it yet.

Whatever we decide, the explanation should connect to the problem they shared.

Internally, I want us to be able to describe the situation clearly: who is affected, what they are trying to do, what gets in the way, and what an improvement would allow them to accomplish.

Once we can do that, the feature discussion becomes much more useful.

A request gives us an idea of where to look. The conversation helps us decide what is worth changing.