Customer evidence and product execution · Video
Turn customer feedback into an engineering brief: a worked example
Created by Light Reach with AI-assisted writing and synthetic narration. The import example is illustrative. Actionairy footage uses staged workspace data. The GitHub draft was created separately for demonstration; the recording does not show an autonomous run creating it.
Transcript
0:00 · Start with a testable outcome
A customer says: retry the import, but keep my workspace. Before anyone writes code, turn that request into a brief that another engineer can review. Here is a worked example you can use with or without an AI coding agent. This is an illustrative scenario from Light Reach. The Actionairy recordings use staged workspace data, and the sample GitHub draft was created separately for demonstration.
0:28 · 1. Separate evidence from assumptions
First, record the evidence. Keep the original request, the observed failure, and an authorized source reference. In this example, a workspace and saved import checkpoint already exist. The interruption cause and checkpoint validity are still unknown. Write those unknowns down. A plausible explanation is not the same as a reproduced failure.
0:53 · 2. Describe observable behavior
Next, define the outcome in behavior you can check. A retry should resume from a valid checkpoint in the same workspace, preserve committed rows, and avoid duplicates if the user retries again. An invalid checkpoint should produce a clear recovery state. That is much more useful than a task called improve onboarding.
1:17 · 3. Find the rule that owns the fix
Then name the owner, the repository, and the scope. Find the boundary that owns workspace identity and import recovery. Look for analogous retry paths before patching one screen. The shared rule is simple: preserve identity and committed rows across retry. Keep a broader onboarding redesign outside this brief.
1:41 · 4. Write acceptance checks before work
Write acceptance checks before execution. Start with committed rows, interrupt the import, then retry. Check that the identity and rows remain. Repeat the retry and check for duplicates. Try an invalid checkpoint and inspect the recovery state. Test the shared rule where it is owned, then verify related paths conform to it.
2:05 · 5. Make approval explicit
Finally, specify approval and delivery. Who may authorize starting work? Who reviews the diff? Who approves release? Ask for a bounded change, the checks actually run, and unresolved limitations. If evidence or access is missing, surface it. A running status is progress, and a draft pull request is review material. Neither proves release or a customer outcome.
2:34 · The brief in a product workflow
The staged Actionairy footage illustrates how a conversation, proposed scope, and approval can be reviewed together. The separately created GitHub example illustrates the delivery format: a draft diff and test evidence. It does not establish an end-to-end production result. Keep that distinction in your own demos and in every handoff.
2:58 · Use the eight-field template
You now have eight fields: problem, evidence, outcome, ownership, scope, acceptance, delivery, and approval. The free template and written guide are at lightreach dot io, under guides, customer conversation to engineering brief. Use one real request, keep private evidence in authorized systems, and see whether a teammate can tell exactly what must change and how it will be checked.