Feedback cycles
Design a strategy for feedback cycles
Feedback is only useful if it reaches the right person fast enough to act. Two failure modes: too slow, and too noisy.
Notifications
Azure DevOps notifications can be scoped at organisation, project, team and personal level. The design rule is subscribe teams, not individuals — a team subscription survives people joining and leaving, and a personal subscription does not.
The noise problem is real: a subscription that fires on every build in the project trains people to filter the whole category to a folder they never open. Scope subscriptions to events that require a decision or an action, not to everything that happens.
GitHub Issues
Issues carry the conversation and the state. Templates make reports usable — a bug report without a version and reproduction steps costs more in follow-up than it saved in typing — and labels plus projects turn a list into a workflow.
Closing the loop back to users
| Signal | Reaches you as |
|---|---|
| Explicit | Issues, feedback requests, support tickets |
| Implicit | Telemetry — usage, errors, performance |
Both are needed. Explicit feedback tells you what users noticed; telemetry tells you what actually happened, including to the users who silently gave up. A strategy built only on explicit feedback systematically misses the second group.
Primary sources