How to test a feature request before adding it to the roadmap

A feature request is evidence that someone has proposed a change. It is not yet evidence that the proposed change solves the underlying problem, serves a wider segment, or deserves priority over other work.

Keep the request intact, then investigate the situation that produced it. What was the person trying to accomplish? What happened? What did they do instead? The answer may support the feature, suggest a smaller change, or reveal a need that requires a different solution.

This guide introduces a request-to-evidence worksheet. The worked example uses a fictional invoicing product and a request for a spreadsheet export. It is a design exercise, not a real customer finding.

Preserve the request and its context

Record the person’s words, the date, their role, and the task they were doing. Mark whether you heard the request directly or received a summary through sales, support, or another colleague.

“Customers want exports” loses useful detail. “An office manager asked to export a list while preparing a weekly payment review” gives the team a starting point for investigation.

If several colleagues report the same request from one account, retain the relationships between those reports. They are multiple records of one customer context, not automatically independent evidence of broad demand.

Describe the need without prescribing the feature

Ask the requester to reconstruct the latest occasion when the feature would have mattered. Explore what they wanted to do with the exported information, who needed it, and what happened without the export.

GOV.UK’s user-needs guidance distinguishes the problem a person needs to solve from a possible solution. Use that distinction to rewrite the request as an outcome without erasing the original wording. Read the user-needs guidance.

For the fictional example:

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 sentence is still a hypothesis. Confirm it through the person’s account rather than treating your translation as a finding.

Complete the request-to-evidence worksheet

Field	What belongs here	Fictional example
Trigger	Event that created the need	Preparing a weekly payment review
Task	Work the person needed to finish	Identify invoices awaiting approval
Constraint	Condition the solution must accommodate	Approver works from a different tool
Current response	What the person actually does	Manually assembles a review list
Consequence	What happens because of that response	Still to be established
Desired outcome	Observable completion of the task	Approver can identify and decide on the right items
Proposed feature	The requester’s suggested implementation	Spreadsheet export
Evidence gap	What the team does not know	Which fields and decisions the review requires

Leaving a cell unresolved is useful. It identifies the next question. Filling it with a plausible story makes the worksheet look complete while reducing its value.

Investigate the workaround before designing the replacement

A workaround contains information about requirements. Ask which fields the person copies, how they organize them, what they add, and who receives the result. If they can safely demonstrate with non-sensitive material, observe the process rather than asking them to describe every click from memory.

The goal is not to celebrate or dismiss the workaround. Understand the job it performs. The spreadsheet may supply calculations, comments, a familiar review format, offline access, or a way to combine data from several systems.

An export that contains the wrong fields could satisfy the literal request while leaving the work unchanged. Conversely, a more focused review view might help some users but fail for people who need to combine outside data. Those possibilities should shape the test.

Keep alternative solutions alive

List several plausible responses before selecting one. For the fictional export request, the set could include an export, an in-product review view, a scheduled report, better access for the approver, or a clearer explanation of an existing capability.

Also include doing nothing for now. That is not dismissing the customer; it is recognizing that product work has tradeoffs and the available evidence may be insufficient.

Compare alternatives against the same task and constraints. Avoid giving your preferred feature a detailed description while leaving the others as vague labels. Each option should state what the user could accomplish and what remains unsupported.

Choose a test that addresses the largest uncertainty

If the uncertainty concerns the task, conduct another behavior-focused interview or observe a current review. If the task is understood but the proposed layout is uncertain, test a prototype. If an existing capability may suffice, investigate whether the person can find and use it.

Do not ask only whether the proposed feature looks useful. Give the participant a relevant task and inspect what they can do with the proposed approach. State in advance which observations would support continuing and which would send you back to the problem.

For the example, an initial test might examine whether a sample review contains the information an approver needs to make a decision. It would not establish production reliability, future adoption, or market-wide demand.

Separate observations, interpretations, and actions

After the test, write what happened before writing the recommendation. “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. Keeping those layers distinct lets another person challenge the reasoning without disputing the underlying record. Read the analysis guidance.

Include counterevidence. If another relevant participant completes the review using the current product, examine the difference in workflow or context rather than ignoring the account.

Close the loop with the requester

Explain what you learned and what the team will do next. A useful response might say that the team is investigating the payment-review task and testing which information belongs in the output. Avoid promising a release date before there is a delivery commitment.

If the feature is deferred, preserve the reason and the condition for reconsidering it. “Need more evidence about the approver’s workflow” is more actionable than “low priority.”

The finished artifact should connect the original request to a demonstrated task, a set of alternatives, and a bounded next action. That lets the roadmap reflect customer evidence without turning every requested implementation into a promise.