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 problem before Work becomes ready.

Is a feature request evidence?

A request is one useful input. Treat it as the start of an investigation, not an implementation order.

Feature request
  -> user + workflow + observed behavior + expected outcome
  -> source-linked Evidence
  -> reviewed Work
  -> ready for delivery

The review may confirm the literal request, uncover a different problem, narrow the affected users, or decide that no product change is justified.

From request to evidence-backed work

The agent preserves the source moment and separates the observed problem from a proposed solution.

Request: Add CSV export.

Context: A team lead needs to share selected evidence with engineers who do not use the research workspace.

Observed behavior: The lead copies material into a spreadsheet, removes reviewer-only notes, and rebuilds the source links manually.

Expected outcome: Share a safe, traceable subset without recreating the evidence packet.

Reviewed problem: Cross-team evidence handoff requires repeated manual cleanup and can lose provenance. The reviewer still has to check whether this pattern is current, sufficiently supported, and worth solving before Work becomes ready.

The answer might be export, a shareable view, a tracker integration, or no change. Evidence clarifies the problem; it does not dictate the feature.

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 draft Work?

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 Work ready.

This gives a delivery agent a reviewed problem with inspectable support, not a literal request or an unverified generated conclusion.

What if evidence is missing?

Missing evidence is useful because it prevents a strategy decision from borrowing a research story it does not have.

Choose one:

  • link existing Evidence that genuinely supports the decision
  • run a focused study against the uncertain workflow
  • mark the work 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.

Move only reviewed Work into delivery

Continue with From User Interviews to Linear and GitHub Issues after Work is verified and ready. After Linear completion, Track Resolved Evidence explains how future similar evidence returns for recurrence review.