Feature Request Triage: From Suggestions to Clear Next Actions

Feature request triage turns incoming suggestions into clear next actions. Preserve what the requester said, identify the problem behind the proposed solution, check what is already known, and assign a disposition with an owner. The immediate output is a manageable investigation queue—not a promise to build every requested feature.

This is part of product management’s work of connecting customer problems with product decisions. A request may reveal a missing capability, a defect, a discoverability problem, or a need outside the product’s scope. Treating all four as backlog features makes the queue harder to understand.

The worked example below uses a fictional delivery-receipt portal. Dispatchers, supervisors, and finance staff have submitted suggestions about finding proof of delivery. All requests and decisions are illustrative; they show how to reason through triage without presenting invented customer research as a finding.

Keep the original request and its context

Start with a stable request ID and the original wording. Store your interpretation separately. If a sales note says “the customer needs a dashboard,” replacing that sentence with “build a dashboard” loses the distinction between what was requested and what the team has agreed to do.

A useful intake record needs enough context for someone else to follow up. It does not need every detail about the customer. Keep sensitive source material in the appropriate restricted system and link to it rather than copying whole conversations into a widely shared board.

“Reported obstacle” is deliberately attributed. The team has not yet observed the work or confirmed which access level the dispatcher uses. Keeping that distinction avoids turning a secondhand account into a verified product defect.

Existing customer-feedback collection methods can supply requests from several channels. The triage record should keep those channels visible. An internal sales summary, a direct interview, and a support reproduction may support different conclusions even when they mention the same feature.

Atlassian’s insights guidance describes attaching supporting material such as customer quotations and support-ticket links to ideas. The useful principle here is provenance: keep enough connection to the source that a reviewer can inspect the evidence and its context.

Translate the proposed solution into a question

For R-17, “send a daily email” is a proposed delivery mechanism. The underlying problem may be locating missing receipts before reconciliation closes. Those are different statements: the first names a feature; the second identifies work that the team can investigate.

Write a tentative problem statement with a person, situation, obstacle, and consequence. For this example: “At the end of a shift, dispatchers may struggle to identify completed deliveries without proof, so they repeatedly inspect individual records.” The word “may” reflects the missing observation, not uncertainty about what the requester actually said.

Then ask a follow-up that could change the proposed response. “Which records do you need to act on at the end of the day?” is more useful than “Would you prefer an email or dashboard?” The first leaves room to discover that the task is exception handling; the second assumes the team has already understood the problem.

Another request, R-18, asks for a red badge beside unsigned receipts. Ask what “unsigned” means in that workflow. It could mean a delivery is still in progress, a signature was not required, or expected proof failed to arrive. A visual badge cannot resolve those policy and data distinctions by itself.

Do not force every request into a discovery exercise. If R-19 says an uploaded signature disappears, route it for support or defect assessment while preserving the source. If the reported behavior is reproduced, the immediate question is how to correct it—not whether enough customers have voted for signatures.

Group related problems without erasing separate reports

R-17’s daily email and R-18’s red badge may both relate to finding missing proof. Put them in a provisional problem group, but retain their individual records. Grouping helps the team investigate a shared question; it does not prove that the two people have the same task.

Give the group a descriptive name such as “Find completed deliveries that still need proof.” Add the hypothesis and the evidence that would challenge it. If the dispatcher only needs an end-of-day reconciliation list while the supervisor needs immediate intervention, the group may need two separate problems.

Distinguish duplicate submissions from independent reports. A customer email forwarded by sales and then copied into a support ticket is one underlying report with multiple references. Two people describing separate incidents provide different evidence. Keep both the report count and the affected organizations visible when relevant; neither number represents demand across all customers.

A group can also contain disagreement. Finance may want every receipt preserved together, while operations only needs exceptions. Do not average those needs into a vague “better reporting” feature. Keep the different jobs explicit so a proposed solution can be judged against each.

Once a problem is supported well enough to explore, an opportunity solution tree can connect it with alternative responses. Triage should provide the evidence and open question for that next step, rather than manufacture a preferred solution to fill the tree.

Assign a disposition that produces an action

Use a small vocabulary that people understand. A status should say what happens next. “Reviewed” and “interesting” describe attention without making a decision. The example queue below keeps investigation, support, deferral, and rejection separate.

These dispositions are conditional on the fictional product’s stated behavior and scope. In actual triage, “already supported” requires a check in the requester’s context. A capability available to administrators may still be inaccessible to the person reporting the problem.

Give deferred work a reconsideration condition. “Revisit later” lets a queue grow indefinitely. R-20 instead names the unresolved need that would reopen the decision. That is still not a shipping commitment. If a deadline or contractual obligation changes the situation, record it explicitly and route the decision to the accountable owner.

Keep urgency distinct from popularity. A reproducible failure blocking a critical task deserves the appropriate support response even if only one report exists. Conversely, many votes for a large feature do not supply an implementation estimate or settle its fit with the product’s goals.

Use a short board review to expose missing decisions

In Mockitt’s whiteboard, arrange the six request cards by disposition. Place the provisional missing-proof problem beside R-17 and R-18, with a visible link back to each request ID. Give each card one owner and a next action. Keep detailed or restricted source records in their existing systems.

Review one disputed group closely. The support representative explains what was actually reported; the researcher names what is still unknown; product checks the outcome and scope; engineering flags whether a reported failure needs immediate investigation. The purpose is to resolve a decision, not to make every participant vote on a favorite feature.

For R-17 and R-18, the board should expose two questions: which deliveries need attention, and when someone needs to know. If nobody owns the definition of “missing proof,” assigning a designer to draw badges is premature. Move the definition task to a named owner and leave the design option uncommitted.

Finish by reading each changed disposition aloud with its reason and next action. Update the authoritative request record after the discussion. The board is a shared working view; it does not automatically synchronize a support queue, create engineering issues, or notify requesters.

Close the loop without promising a feature

Respond in language that matches the decision. For an investigation, a useful message is: “We are looking into how dispatchers find missing receipts at the end of a shift. We have not selected a daily email solution. Could we review a recent example of that task with you?” It acknowledges the request and asks for useful evidence.

For an already-supported path, explain the relevant action and confirm access instead of closing the request with a documentation link alone. If the person cannot use the path, reopen the diagnosis. A discoverability issue may remain even after support has answered the immediate question.

For a decline, name the scope decision and preserve the underlying need: “Continuous location tracking is outside this portal’s scope. We have recorded the coordination problem you described and can clarify which delivery-status information is available.” Avoid “never” unless that is an authorized, durable commitment.

Review unresolved items by their next action and reconsideration condition. Close obsolete records with a reason, retain useful evidence, and reopen a decision when new information changes it. Move accepted opportunities into roadmap planning only when the team has enough context to discuss the trade-off. A well-triaged queue lets everyone see what is known, what is being investigated, and what the product has actually committed to do.