Prioritize product feedback with evidence and ownership

Prioritize product feedback by the work that is blocked, the evidence of that problem, and who owns the decision. Request counts alone reward the loudest channel. A useful process separates the proposed feature from the underlying need, then decides what to investigate or change.

The output should be a decision with an owner, not a longer backlog that everyone can add to and nobody can resolve.

Keep the request and recover the problem

Save the original wording, but add the user’s role, task, context, and current workaround. “Add bulk editing” might mean repetitive work, an import failure, or a permissions model that prevents delegation. Those are different problems with different solutions.

Ask what the person tried, where they stopped, and what happened next. Separate observed behavior from the team’s interpretation. Note whether the evidence comes from a support conversation, a session observation, or telemetry; each has limits.

The UK Government Service Manual recommends choosing research activities that answer the team’s questions with appropriate evidence and effort. Use the unresolved question to choose the next investigation instead of automatically scheduling another survey.

Use a small decision queue

Group reports by underlying problem without losing affected roles or languages. Five messages from one account are not necessarily five independent examples. A lack of complaints from invited users may reflect their limited support access rather than a lack of trouble.

Evidence field	Decision it supports
Blocked task and consequence	How serious is the problem?
Affected users and opportunities to encounter it	How broad is the exposure?
Workaround and assistance required	What is the present operational burden?
Confidence and missing evidence	Should the team investigate first?
Owner and review date	Who will close the decision?

Treat a serious defect or access-control problem through incident or defect triage rather than waiting for a popularity score. For ordinary improvements, compare severity, reach, confidence, and effort, but keep the reasoning visible beside any score.

A hypothetical export request

Suppose three hypothetical customers ask for spreadsheet export. Two need a monthly management report. The third needs to transfer records into another system every day. The requested button is the same; the operating needs are not.

The team inspects the report workflow and observes that a missing filter makes the existing report unusable. For those users, a filter may solve the problem without exporting sensitive data. The daily transfer needs a separate integration decision with ownership and recovery rules.

Do not merge both into a generic export ticket and claim the entire demand is addressed when it ships. Record which problem a proposed change covers and which remains open.

Close the loop after the decision

Use explicit outcomes: investigate, build, defer with a revisit condition, or decline with a reason. Communicate the decision without turning an exploration into a promised delivery date. Give a deferred request a trigger, such as an upcoming workflow change, rather than an indefinite “later.”

After delivery, check the original task with the affected role. Feature usage is useful evidence, but the question is whether the block and workaround disappeared.

At the next planning meeting, take a small group of recent requests and rewrite each as a problem record with an owner. Use those records to scope custom software development work that can be checked against the reason it entered the backlog.