The challenge
The platform serves four internal customer groups. Each uses the system in a different way, each wants very different things, and each is vocal about it.
As the only product person, I set up a customer reporting channel for each group: an open line, like a customer support channel, where users posted problems as they hit them. I monitored all four, caught critical errors as they happened, turned reports into defects, triaged them, and put them into sprints.
That intake work came on top of writing requirements for six engineering, data science, and QA teams. The first batch of features took 22 days to go from stubs to groomed stories, and leadership often learned about slips and drift too late to act.
My role
I designed and built the system myself. The goal was to automate as much of the monitoring and intake as possible, capture every issue accurately with a ticket behind it, and onboard others on the team to take in defects.
That freed me to focus on what only I could do: keeping executives informed, and telling each group when its issues would be resolved and closed, based on severity.
How I solved it
- 1
Automate issue intake
Claude multi-agent workflows connect through MCP to Microsoft 365 and read all four customer reporting channels each weekday, capturing reported issues and critical errors and flagging which ones need a defect. Reports can contain protected patient data (PHI), so agents never create defects themselves; I onboarded teammates to log them, so intake no longer depended on me.
- 2
Track every incident to closure
I built an incident tracker dashboard that ties each reported issue to its ticket number and status. It shows when the team misses an SLA or skips follow-up after a fix, so I can coach the team and step in early.
- 3
Standardize the requirement package
Every feature ships as the same package: mockups, ID-tabled acceptance criteria, and rendered screenshots built from shared story templates. Each screen change carries a static mockup, rendered in a headless browser and attached to the ticket.
- 4
Prototype before engineering
I build working React and Python prototypes and walk engineering through each scenario before work starts, so stories arrive tested rather than described.
- 5
Turn signals into decisions
Each weekday the agents also read the Azure DevOps board, the Notion roadmap, email, calendar, and standup transcripts, and produce a status digest, a risk and drift report, and an audited run log, so leadership sees slips before it decides.
- 6
Keep AI governed
Work on protected patient data runs in Claude Code on Amazon Bedrock, every agent run is logged for audit, and an Obsidian vault keeps the decision record.
From 22 days to 2
Spec turnaround, from the first stubs to groomed stories on the engineering board.
Time to an accepted prototype
Time from first file to accepted version for 10 workstreams prototyped since April 2026, with 30 tracked version changes.
The toolset
Results
- Wrote requirements for and led delivery of 95 features from May to September 2026 (392 user stories).
- Cut spec turnaround from 22 days on the first batch in July to 2 days by September.
- Cut feature delivery time 67%, from 6 sprints to 2.
- 166 logged automated runs from Aug 10 to Sep 15, 2026, with 85% completing cleanly.