Prioritize Fixes With Evidence

Every team has more possible fixes than time. The risky part is not having a backlog. It is not knowing which work is grounded in real user pain and which work is just a convincing internal guess.

UserTold helps teams prioritize by keeping evidence attached from interview to work item. A fix is easier to trust when you can see what users said, what they did, where it happened, and who verified the source before handoff.

The pain this solves

Backlogs drift when evidence gets separated from the work:

  • a quote becomes "improve onboarding"
  • a support thread becomes a broad roadmap theme
  • a strong internal opinion becomes a high-priority ticket
  • a shipped fix gets marked done even though similar confusion keeps appearing

UserTold keeps the source trail visible so the team can decide what is ready, what needs more evidence, and what should stay out of delivery.

What evidence can tell you

Evidence can show:

  • what a participant said or did
  • where the moment happened
  • what task or decision was in progress
  • whether several moments point to the same problem
  • whether there are smooth completions or counter-examples
  • whether future interviews show similar pain after a fix ships

Evidence does not decide strategy, effort, revenue impact, or priority by itself. It gives reviewers a better starting point.

How to review a packet

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

  1. Read the grouped evidence.
  2. Open one or two source moments.
  3. Check whether the grouped moments really point to the same problem.
  4. Look for counter-evidence, such as users who completed the flow smoothly.
  5. Confirm the problem still exists in the product.
  6. Promote, defer, split, merge, or dismiss the packet.

This gives your delivery system a cleaner input: reviewed work, not raw research notes.

Why the method works

The method is practical: related moments can point to a pattern, but someone still needs to check that the pattern is real.

UserTold makes that review easier for builders. It groups related evidence, preserves quotes and context, shows missing or conflicting evidence, and keeps the work connected to Linear or GitHub after handoff. The fuller research basis is in Methodology.

What good prioritization looks like

Weak prioritization:

This has three mentions, so it is highest priority.

Source-backed prioritization:

Three setup interviews show the same API-key scope confusion at /settings/integrations. Two participants opened docs mid-flow and one abandoned setup. Existing smooth completions apply to the old provider path, not the new one. The current screen still says only "API key."

The second version tells the team why this work is ready and where the uncertainty still is.

Example decision record

## Decision

Promote to Linear.

## Why

Three setup interviews show the same API-key scope confusion at `/settings/integrations`. Two participants opened docs mid-flow and one abandoned setup.

## Source checks

- Reviewed playback from `ses_123` and `ses_124`.
- Confirmed the current setup screen still labels the field "API key" without scope guidance.
- Counter-evidence: existing smooth completions apply to the old provider path, not this flow.

## Delivery direction

Add provider-specific key scope guidance and a connection test before save.

When evidence is missing

Missing evidence is useful too. It tells you not to pretend.

If important work has little or no linked evidence, choose one:

  • link existing evidence that supports it
  • run a focused study
  • mark it as strategy-led work outside UserTold
  • defer it until there is a clearer user problem

Do not invent a research story for a decision that came from somewhere else.

After the fix ships

When a Linear issue completes, UserTold can resolve the evidence that justified the work and keep watching future interviews for similar pain. Treat that future evidence as a review cue, not automatic proof that the fix failed.

Next step

Use this guide when review packets need to become delivery work. If you have not created the packet yet, start with Find Where Users Get Stuck or Learn Why Users Switch.