Automating product operations as shipping velocity scaled
As agentic development increased shipping velocity and PM bandwidth stayed thin, I built connected systems for prioritizing customer issues, turning scattered signal into backlog decisions, and pushing what shipped back to customer-facing teams.
The problem
Engineering started shipping faster with coding agents. The PM team did not grow. Customer issues, sales call notes, support tickets, and Slack threads piled up in different places. Customer-facing teams had trouble keeping up with what shipped.
What I did
I built three connected systems with AI agents. Each one runs on a schedule.
Daily customer issue triage. Every day it reviews new customer-reported issues and scores them. The score covers technical severity, how many customers reported it, and fit with our strategy. A separate score covers commitments to key accounts. Security issues and regressions go straight to critical. It posts a ranked summary each morning.
Insight to backlog. Collectors pull raw signal from support tickets, sales calls, Slack, and product usage. A triage step groups related signal. A ticket author drafts backlog items with the evidence attached, so a PM can decide quickly.
Release Radar. A report every two weeks for sales, customer success, and support. It groups releases by the customer job they help with. Each release has short enablement notes grounded in the actual code changes. A conversation starters section gives the field talking points. Reviewer comments on each draft become standing rules for the next edition.
How I kept it trustworthy
- The scoring rules live in fixed code. The AI writes the explanations. It does not change the math.
- An automated reviewer checks every triage run after it finishes. It flags scores that change when their inputs did not.
- I rebuilt the triage in a shadow copy first. It ran in parallel with no writes to Jira until the results matched what we expected. Then we switched over.
What I learned
- Audit the defaults. One fallback rule quietly put over half of all tickets into a single category and raised their scores. Nobody noticed until we measured it.
- Simple routing rules last longer. We tried routing tickets by topic to specific epics. We reversed it two weeks later and sent tickets to one intake per source.
- Shipping is only half the job. Customer-facing teams need to know what changed and how to talk about it.
- Write down every correction. Each piece of feedback became a rule the system follows next time.