How to validate feature requests: find the job behind "just add export"

To validate a feature request, find the task the person was trying to finish, then test whether the requested feature is the best way to help with it. The request tells you someone proposed a change. It doesn't yet tell you that the change solves the problem, matters to other customers or beats the rest of your roadmap.

So keep the request intact and ask about the moment that produced it. What was the person trying to do? What happened? What did they do instead? The answer may support the feature, point to a smaller change or reveal a need that calls for something different.

Here is a made-up example used throughout: an invoicing product, and a customer asking to "export the invoice list" to a spreadsheet. It is a design exercise, not a real customer finding.

1. Write down the exact words and where they came from

Record the person's words, the date, their role and the task they were doing. Note whether you heard it directly or secondhand.

"Customers want exports" loses the useful detail. "An office manager asked to export a list while preparing a weekly payment review" gives the team somewhere to start.

If three colleagues report the same request from one account, that is one customer mentioned three times. Keep the reports linked so they don't get counted as broad demand. (The account manager who brought it up in every standup still counts once.)

2. Rewrite the request as the need behind it

Ask the requester to walk through the last time the feature would have mattered. What did they want to do with the exported information, who needed it, and what happened without the export?

GOV.UK's user-needs guidance separates the problem a person needs to solve from a possible solution. Use that to restate the request as an outcome, while keeping the original wording:

Request: "Let me export the invoice list."

Possible need to investigate: "Prepare a payment review that shows which invoices need a decision, using information the approver can understand."

The second line is still a guess until the person's own account confirms it.

3. Fill in a request-to-evidence worksheet, and leave gaps empty

An empty cell is useful because it names your next question. Filling it with a plausible story makes the worksheet look finished and makes it worth less.

4. Study the workaround before you replace it

A workaround is a requirements document someone already wrote for you, in spreadsheet form. Ask which fields the person copies, how they organize them, what they add and who receives the result. If they can safely show you with non-sensitive material, watch the process instead of asking them to recall every click.

The spreadsheet may be doing several jobs: calculations, comments, a familiar review format, offline access or combining data from several systems. An export with the wrong fields could satisfy the literal request and leave the work unchanged. A focused review view might help some users and fail people who need to combine outside data.

5. List several solutions, including doing nothing

Before picking one, list the plausible responses. For the export request: an export, an in-product review view, a scheduled report, better access for the approver, or a clearer explanation of something the product already does.

Include doing nothing for now. Product work has tradeoffs, and the evidence may not be enough yet.

Describe every option against the same task and constraints. If your favorite gets a paragraph and the others get two words each, the comparison is rigged.

6. Test the biggest unknown first

Match the test to the uncertainty:

• If you don't understand the task yet, watch the person do a current review.
• If the task is clear but the layout isn't, test a prototype.
• If an existing feature might already cover it, check whether the person can find and use it.

Don't just ask whether the feature looks useful. Give the participant a real task and see what they can do with the proposed approach. Decide in advance which results mean continue and which send you back to the problem.

In the example, a first test might check whether a sample review contains what an approver needs to decide. It would not prove production reliability, future adoption or market-wide demand.

7. Write what happened before what it means

After the test, separate three layers. "The approver asked for the original invoice date" is an observation. "Dates may be necessary for this review" is an interpretation. "Add a date field to the next prototype" is an action.

GOV.UK's analysis guidance separates observations, findings and actions in the same way. Keeping them apart lets a colleague challenge your reasoning without arguing about what happened.

Keep the counterevidence too. If another participant finishes the review fine with the current product, look at how their workflow differs instead of setting the account aside.

8. Tell the requester what you learned

Say what you found and what happens next, such as testing which information belongs in the payment review. Don't promise a release date before there is a delivery commitment.

If you defer the feature, write down why and what would make you revisit it. "Need more evidence about the approver's workflow" is more useful than "low priority."

The finished record should connect the original request to a demonstrated task, a set of options and one bounded next step. Start with the next request in your queue: find the person, and ask about the last time they needed it.