Watch the Work Before You Build the Feature Request

“Can you add an Export button?”

The request sounds complete. The screen holds a list. The user wants that list in a file. A button, a download, and the work appears finished.

Stay with the person for the next few minutes. They export the file, open it in a spreadsheet, remove half the columns, sort by a date the screen does not show, and mark a few rows for a meeting. Then they paste the marked rows into a message because the person joining the meeting cannot access the product.

The button was real. It was also the first visible answer to a larger difficulty. The person needed to prepare a small set of records for a conversation with someone outside the tool.

When someone asks me for a feature, I take the request seriously. I also ask to see the work immediately before and after it. The nouns tell me what the person imagined. The verbs show me what the product currently makes difficult.

Discovery map / 01

The visible request is only the first layer

1. 01 Visible request“Add an Export button.”
2. 02 Immediate taskPrepare selected records.
3. 03 Surrounding workRemove columns, sort, and mark rows.
4. 04 CollaboratorShare with someone outside the product.
5. 05 Real outcomeCarry a small set into a conversation.

Smaller answerExact featureDifferent workflow

Start with the minutes around the request

A feature request rarely arrives as a clean description of a problem. People do not spend their day writing product briefs. They encounter resistance, picture a way around it, and ask for the part they can name.

That is useful knowledge. The person has already studied the work from inside it. They know where attention breaks, which information is missing, and what they do outside the product to finish the job.

The proposed feature captures some of that knowledge, but it compresses the sequence. “Add Export” may mean the current screen cannot compare records. It may mean a customer needs a copy. It may mean the user trusts a spreadsheet more. It may mean one person lacks access and the requester has become a human delivery system.

Those are different difficulties. Building the same button for all of them can satisfy the request while leaving the work untouched.

I begin with a replay of the last time it happened, following the person from the result they wanted through the next screen, the hand edit, and the person who received it.

The questions should feel like interest, not an interrogation. The user should not have to defend wanting the button. The point is to preserve the knowledge inside the request before the proposed solution becomes the only thing anyone can discuss.

Sometimes the replay makes the answer obvious. The export is exactly what the work needs. Other times the scene reveals that the useful change belongs earlier, such as adding a missing date to the screen, saving a view, sharing one record, or giving the meeting participant the right access.

The small amount of observation prevents a common waste. A team can build the requested surface, announce that it listened, and still make the user complete the same awkward sequence with one new click in the middle.

The proposed feature carries real knowledge

There is a patronizing version of product discovery that treats every request as wrong until a product person translates it. The user asks for a button. The builder responds with a lecture about outcomes. Nothing gets built, and the person learns that reporting a problem creates more work for them.

That is not curiosity. It is status dressed as process.

The person doing the work may understand the difficulty better than anyone designing the product. They have repeated it. They know which shortcut saves the day and which missing field causes the argument. A proposed solution is often evidence of serious thought, even when it is not the final answer.

Taking the request apart should not take authority away from the person. Their words and example stay attached while the builder adds what success would mean and how the change could affect the rest of the product.

This matters most in operations software. Experienced users compare facts, make calls, and recover odd cases in ways that do not fit a clean product tour. I have written before about why operations software should follow the job rather than a preference for empty screens. Feature work needs the same respect for the operator’s view.

Respect does not mean agreement. A requested change may expose another person’s private data, weaken a permission boundary, create two competing records, or make a rare workaround permanent for everyone. The builder has knowledge the requester may not see from their seat.

That is why the conversation needs both sides. The user contributes the lived sequence and the cost of the current design. The builder contributes the wider product, the people affected elsewhere, and the burden the new behavior will carry after release.

Neither side should pretend the other is merely providing input. They are holding different parts of the same problem.

The best answer may be smaller than the request

Feature requests tend to name visible additions such as another filter, a second status, or a report with its own menu item. The difficulty underneath may need far less product.

Return to the export request. If the user removes the same columns every time, the screen may be showing facts that do not belong in that decision. If they sort by a hidden date, that date may belong in the current view. Sending the file to one colleague may point to a controlled share instead.

The smallest answer is not automatically best. A tiny patch can turn into a pile of private exceptions that nobody else understands. The aim is to find the smallest change that settles the real difficulty without making the product harder to explain.

Language can be enough. A user asks for a new status because the existing one has two meanings. Renaming the old status and separating its consequence may solve more than adding another label beside it.

Other requests should begin outside the product. A short manual trial can show whether the need repeats, which parts stay consistent, and whether permanent behavior would help. Software can wait until the team has learned what is actually stable.

The decision should account for how settled the work is. Custom software makes sense when the need is stable enough to own. The same is true at feature scale. A request born from a temporary policy or one unusual customer may deserve patience before it becomes permanent product behavior.

A smaller answer can respect the user more because it reaches the thing they were trying to finish. They asked for a button because the button was easy to imagine. They did not ask to fund a larger screen, train everyone on it, and live with it forever.

Sometimes the user is exactly right

Discovery can become a delay tactic. A clear request enters the process, several people restate it in more abstract language, and the original user waits while the team searches for a deeper truth that is not there.

Sometimes the export button is the answer. The person needs to send records to an accountant who works in a different system. The fields are already correct. The permission is understood. A plain export solves the whole problem.

In that case, build it. Treating requests as clues can become an excuse for endless interpretation. A team starts to act as if users do not know what they need, turning a modest change into a workshop while the work stays difficult.

The useful test is whether the requester can show a recurring moment and the proposed feature truly removes its difficulty. The answer also has to avoid creating a larger problem for someone else, and the work must be settled enough for the new behavior to make sense after the current conversation ends.

If those answers hold, more discovery adds ceremony rather than knowledge. The user did the product thinking already.

Good judgment also includes speed. A builder should know when to stop asking and make the clear change. Taking a request seriously means neither obeying it blindly nor holding it hostage until it sounds like your own idea.

After release, return to the same person and watch the same moment again. Do not ask only whether they like the feature. See whether the extra work disappeared. The answer may show that the button worked, that the difficulty moved elsewhere, or that a different person now carries it.

That last visit closes the meaning of the request. The product does not win because the feature exists. It wins when the person no longer needs to ask for the missing help that started the conversation.

The next feature should begin with the minutes before anyone asked for it.

Frequently asked questions

Should every feature request go into a backlog?

No. Keep the request and its example somewhere the product team can find, but do not turn every suggestion into promised work. A backlog without context becomes a list of old solutions whose original difficulty nobody remembers.

What should you write down when a request arrives?

Keep the requester’s words, the moment that led to the request, what happened before and after, who else was affected, and what a successful change would remove. That is enough to revisit the request without flattening it into a feature name.

How do you say no without dismissing the user?

Name the difficulty you understood, explain the consequence that blocks the proposed change, and say what the product can do instead. A person can accept a no when it proves their work was seen and gives them an honest path forward.

What if only one customer asks for the feature?

One customer can reveal a real need that others have not named. Look at the consequence, the surrounding work, and whether the pattern is likely to repeat. A short trial can teach more than assuming the request is either unique or universal.