Product design
Turning Audience Insight Into Agent-Ready Specs
A proposed workflow for turning customer evidence into a brief an agent can execute: preserve sources, state the decision and define how another person will verify the result.
By Terry Chen · Updated
Originally published
A product brief needs to preserve why the work matters as well as what to build. When an agent receives only a summary of feedback, it may have too little context to resolve a disputed requirement. The design proposal here connects three records: the source evidence, the decision and the accepted result. It is a workflow to evaluate, not a report of measured customer outcomes.
Keep evidence separate from the decision
Retain the source, date, relevant context and any limits on its use. Label a reported experience as a report. Then state your interpretation and the product decision separately, so a reviewer can challenge one without losing the others.
The W3C provenance overview describes provenance in terms of the entities, activities and people involved in producing something. The practical adaptation here is to record which source supports a requirement, who made the decision and what changed during the handoff. This brief format is our proposal; it is not a claim of PROV conformance.
For example, repeated requests for screenshots may suggest a sharing problem. They do not establish that public sharing is the right solution. Access rules, missing context or the format of the report may explain the same behavior. Keep those alternatives beside the proposed requirement.
Write a brief with decisions the agent can use
- Outcome and audience. Name the person doing the task, the trigger and the useful result. Give the agent a way to recognize completion.
- Evidence and rationale. Link the relevant source records and explain why this outcome was chosen. Keep uncertainty and conflicting accounts visible.
- Constraints and permissions. State which data and actions are permitted, who may see the result and which changes require a decision from the owner.
- Acceptance conditions. Describe observable behavior, including a meaningful failure case. A screenshot of a successful screen is only one part of that evidence.
- Open questions and ownership. Mark unresolved choices explicitly. Assign someone who can answer them and record the answer when it changes the brief.
Keep the first implementation small enough to exercise the complete task. Decomposing work into tickets is useful only if the tickets retain the shared constraints and the same definition of completion.
An illustrative handoff: reviewing a shared report
Illustrative scenario — no customer result is claimed
Reported problem: a teammate asks for screenshots because they cannot open a report link. The reason for the access failure has not been established.
Decision to test: allow an authorized reviewer to open the intended report in a fresh session, while retaining the existing boundary around private source material.
Acceptance conditions: the intended reviewer can open the saved report; another account cannot gain access through the same link; a revoked reviewer loses access; and refreshing the page preserves the saved result.
Open question: does the intended reviewer need a different presentation, or is the existing report sufficient once access works? Observe that before expanding the feature.
The brief gives the agent a concrete outcome and a reviewer something to verify. It does not treat a suggested implementation as proof that the original problem has been understood.
Verify the experience from a fresh starting point
Follow the task from its actual entry point, through the action and saved state, to the result another person can use. Check the relevant account and permission conditions. Retain the source revision or deployed version used for the check so a later reviewer knows what was tested.
Record failures and incomplete boundaries along with successes. A generated artifact can be correct while its link is inaccessible; a visible result can disappear after refresh. Use these observations to revise the brief or implementation, then retest the affected behavior.
To evaluate this proposed workflow, compare briefs on a defined set of tasks and record clarification requests, rework, acceptance failures and review effort. Preserve differences between tasks rather than turning an informal comparison into a productivity claim.
A brief you can copy into the work
Outcome, intended user and entry point: Source references, dates and relevant context: Interpretation, counterevidence and decision: Inputs, permitted actions and access boundaries: Acceptance conditions and failure cases: Open questions, owner and recorded answers: Implementation or release revision: Verification evidence and remaining gaps:
Keep private evidence in its authorized location and reference it from the brief. A concise summary should make it easier to inspect the source, rather than silently replacing it.
Connect the method to a supported research task
If public X conversations would help define the question, review CrowdListen’s X research scope and agree its coverage, output and estimate. Your team owns the product decision, implementation brief and acceptance review. This article does not promise an automatic cross-platform feed-to-code pipeline.
Review X research scopeFor evidence spanning text, images and video, the multimodal evidence framework explains how to retain the location and limits of each observation.
