- Ask what the customer can do differently.
- Use the PR for evidence and the product screen for the explanation.
- Confirm rollout and permissions separately before sharing.
The engineering source says “Add CSV export to the reports page.” A customer wants to know whether the file includes all rows or only the rows currently shown. Explain the answer in terms of the task, not the implementation.
Extract the customer-visible claim
In the GitHub example, the release notes say that the CSV contains the rows shown by the active filters. They also say that the file name includes the report and the date. Those facts are specific enough to check. They are more useful to a customer than the name of the export handler or the files changed in the PR.
Write the claim in a sentence a customer can use: “Filter the report first, then export it to download the matching rows.” Ask the release owner whether this behavior is deployed for the intended account. A merge or a note in a repository is not evidence of that account’s rollout.
Request the explanation beside the engineering source
The real GitHub walkthrough shows a 15-second PR request, the bot’s progress reply, the finished explainer and a release-note example. Use the GitHub integration when the relevant change lives on the PR or release. The clip follows the GitHub request through to its reply.
For a customer-facing draft, ask “Explain which rows someone gets when exporting a filtered report. Show the filter state, the export action and what the file contains.” If your original source is an IDE conversation instead, carry forward only approved product facts and observable behavior.
Show the product test the viewer would run
Choose two rows with clearly different values, apply a filter and export. Open the file and check that the surviving row matches the report. Use demonstration data. Record that verified result if the audience must reproduce the task. When you do not have current UI footage, explain the behavior in words and link the guide rather than drawing a fictional control.
Use the feature announcement workflow for the public cut. Keep code paths, environment settings and internal tickets in the reviewer’s source notes.
Publish the explanation your audience can verify
Have a teammate follow the steps as a customer with the intended permission level. If their file contains different rows, investigate before editing the wording. Use the changelog guide for a collection of changes. A single CSV change usually needs one focused example and a link to the full release notes.
You just read it. Now watch it.
ngram turns this post into a short explainer video: scenes, voiceover, and motion graphics included.






