Turn Feedback Into Work Worth Building

“Add CSV export” is a request, not yet a problem worth building. It omits who needed the export, what they were trying to do, what failed, what they did instead, and why the outcome mattered. UserTold keeps that context attached to source Evidence so a human or project-aware agent can review the Finding before product triage.

Start with a reviewed problem

If the request is still vague, first identify the underlying user need. If you have recordings but no supported synthesis, analyze the interviews. Prioritization starts after you can name the problem and open the source moments that support it.

Review and priority are different decisions. A Finding can be well supported and still be deferred because it does not fit the product direction or the cost of addressing it is too high.

Compare problems with explicit judgment

Use a small decision table. Record where each input comes from instead of collapsing everything into an unexplained AI score.

Input	Evidence or context to use	Common mistake
User consequence	What progress failed and what the participant did instead.	Counting every inconvenience as severe.
Breadth	Independent source episodes, affected roles, and relevant analytics.	Treating interview frequency as population prevalence.
Product fit	The workflow and users the team intends to serve.	Assuming a popular request belongs in the product.
Effort	An engineering assessment of the actual implementation.	Asking interview evidence to estimate cost.
Uncertainty	Missing context, counter-evidence, and possible alternative causes.	Reading extraction confidence as business certainty.

Compare two supported problems

A team has two reviewed problems: users misunderstand an optional onboarding step, and a team lead manually rebuilds evidence links for an engineering handoff. Both may be real. The team checks which users are affected, whether existing functionality addresses either problem, and what each change requires.

If the onboarding obstacle blocks the team's current activation goal and can be tested with a narrow copy change, the team may investigate it first. The handoff problem can remain reviewed but deferred. That order comes from evidence plus product context and engineering judgment, not from which quote sounds more emotional.

Record the selected action, its rationale, and what would change the decision. Possible actions include a fix, another Study, using an existing capability, deferral, or dismissal.

What evidence can and cannot decide

Evidence can show:

• what a participant said or did
• where the moment happened
• what task or decision was in progress
• whether several qualitative moments may describe the same problem
• whether smooth completions or counter-examples exist
• whether similar evidence appears after a fix ships

Evidence does not determine strategy, engineering effort, revenue impact, prevalence, or priority by itself. A recurrence is a review cue, not proof that a fix worked or failed.

How should I review a draft Finding?

Use the generated summary as a lead, not as the answer.

1. Read the grouped Evidence.
2. Open representative source moments.
3. Check whether the moments really describe the same current problem.
4. Look for smooth completions and counter-evidence.
5. Compare the Finding with current product and project context.
6. Correct, split, merge, defer, dismiss, or mark the Finding reviewed.

This gives a delivery agent a reviewed problem with inspectable support.

What if evidence is missing?

Missing evidence is useful: it stops a strategy decision from borrowing research it does not have.

Choose one:

• link existing Evidence that genuinely supports the decision
• run a focused study against the uncertain workflow
• mark the decision as strategy-led rather than user-evidence-led
• defer it until the problem is clearer

Do not invent participant context for a decision that came from somewhere else.

Send reviewed Findings to product triage or delivery

Continue with From User Interviews to Linear and GitHub Issues after a Finding is reviewed. After Linear completion, Track Resolved Evidence explains how later similar Evidence returns for recurrence review.

Help me apply this guide to my UserTold interviews. Review the source evidence with me and work from what it supports.

Read this guide first: https://usertold.ai/guides/prioritize-fixes-with-evidence

Use my existing UserTold connection. If it is not connected, help me connect through https://mcp.usertold.ai/mcp and complete browser authorization. Ask for missing project details, use the available UserTold tools, and walk me through any steps that need the dashboard.