Building an AI-Driven Product Management Operations System in Cursor

 Explain the Meta Data

This artifact covers the internal AI product-management system I originally built to speed up my own workflow, then expanded to support marketing, customer experience, and engineering. The project is archived due to restructuring, but the architecture can be reproduced anywhere.

How it was built: The system lived inside Cursor as a lightweight “operating system” wired into Jira, GitHub, and Help Scout. Around ten purpose-built agents shared the same resource files and platform integrations, handling everything from strategy shaping to triage.

Goal: The goal was simple and slightly unhinged: clone my brain so I could move faster. Once that worked, I extended it to cross-functional needs. CX got automated insight and QA reports; marketing got tools that made campaigns smarter and more consistent.

Impact: The system produced full triage flows, cross-functional reporting, and cut my time from idea to strategy + PRD by roughly 50%.

The Challenge: Navigating Rapid Change, High Stakes

This system wasn’t conceived for novelty — it was built for survival.

“Ops” was born out of the LearnDash 5.0 pivot — a moment when everything needed to move faster, but the process couldn’t keep up.

The roadmap took a hard right. Dependencies were tight, high-stakes, and scattered across teams. Communication loops kept collapsing under the weight of context switching and overly technical concepts. I was managing simultaneous engineering calls, internal documentation and enablement, customer and integration-partner readiness, and stakeholder alignment — and every minute of my time was precious.

I needed a way to rebuild my workflow mid-disruption — something that could stabilize operations, surface clarity, and keep the roadmap alive as it evolved. That need led to an AI-driven product operations system: a lightweight structure designed to take on the tedious pieces while I did the thinking.

The Build

In Cursor, I designed a lightweight AI operations system — part workflow engine, part thinking partner.

The system didn’t replace human thinking, it extended it. Each agent was trained specifically to work in the right way for our team and standards.

For example, the Engineering Advisor always referenced the contribution.md file and custom instructions from the lead LearnDash engineer before answering me at any given time.

It didn’t automate decisions — it framed them. The structure combined prompt templates, API-assisted automations, and natural-language scripting — all woven together to keep information flowing more efficiently while still keeping a human – me – in the loop. The result felt less like a bot and more like a sidekick

The final prototype structure looked a little like this:

/ops
├── handler.py           # Dispatch, routing, guardrails
├── agents/
│   ├── triage_agent     # Ticket completeness + coaching
│   ├── engineering_advisor # Code-aware analysis, feasibility
│   └── ticket_manager   # Safe Jira CRUD, preview/confirm
├── docs/                # Process templates, naming, briefs
├── registry/            # Reusable prompts, rubrics, labels
├── platforms/           # Jira • GitHub • Help Scout adapters
├── shared/              # Formatting, validation, auth utils
├── deliverables/        # Reports, comments, release notes
└── logs/                # Read-only traces, cost tracking

 Expand/Collapse Nerdy Details

System Capabilities

• Summarize support-ticket trends..
• Produce cross-tool performance reports.
• Synchronize tasks and dependencies across tools.
• Draft documentation, release notes & internal updates.
• Triage software bug reports. 
• Recommend engineering strategies and generate code scaffolding.

Technical Highlights

• Cursor as the backbone: Modular, fast, and developer-friendly.
• Unified registries: Central control for tone, prompts, and rubrics.
• 5-D Feasibility Framework: Balanced engineering detail with roadmap logic.
• Thin adapters: Lightweight integration layers for easy maintenance.

Safeguards and Oversight

• Read-only by default.
• Sensitive data scrubbed before analysis.
• Rate limits and cost budgets per run.
• Validation checkpoints to ensure data quality.
• WCAG-aware tone templates for accessible communication.
• Safe secret key storage in .env files or direct connections in Cursor.

Design Principles

This prototype was an evolving project. I learned as I went, but I did have a few key principles I wanted to include up front. These became the core design rules — simple enough to follow, strong enough to scale.

Teaching by default.
The system should guide and inform, not replace human thinking.

Context at every step.
Each output should understand why it exists — not just what it is.

Human in the loop.
AI could summarize, suggest, and surface — but decisions would stay human.

Lightweight by design.
If a solution added friction, it wasn’t the solution.

Outcome

The impact was subtle but powerful:

• Fewer pings, more strategic conversations.
• Routine reports auto-generated in seconds.
• Customer insights were powerful and instantly available.
• Communications improved without more meetings.
• Developers were able to work on tickets quicker.
• Support agents started writing better bug tickets.
• Technical feasibility conversations with Engineering took only minutes.

Within weeks, the experiment saved several hours per day — personal gains that compounded across the team. More importantly, it proved a concept I’d been chasing: that AI in product management isn’t about automation — it’s about amplification.

This build became the foundation for how I now think about human-AI systems: lightweight, contextual, and unmistakably human in intent.