How Dennis Yang Automates Product Management and Prototypes AI with Cursor

Most people use the AI-native code editor Cursor to write software. Dennis Yang, a principal product manager for generative AI at Chime, uses it to write everything else. He’s turned a tool built for engineers into a central hub for product management, automating the entire lifecycle from PRD creation and feedback to Jira ticketing and status reporting, all without writing application code.

Cursor gives Dennis four things in one workspace: access to several models, a local file system, reusable instructions called Cursor Rules, and connections to tools like Jira, Confluence, and Notion through the Model-Context Protocol (MCP). This combination lets him keep a single source of truth, a Markdown file, and use AI to translate it for all the different systems and audiences a product manager has to serve.

In this episode of How I AI, Dennis first demonstrates how he moves a product document through review, ticketing, and reporting. The second workflow uses Cursor itself as a no-code runtime for an agent prototype, allowing him to test instructions and models before writing an application.

From PRD to status report in one workspace

Product managers repeatedly translate the same source material into documents for different audiences, a process that leads to cognitive fatigue. To avoid this, Dennis keeps the product requirements document (PRD) as reusable context and lets AI derive the next artifact from it instead of rewriting from memory.

Make Cursor comfortable for writing

Because large language models work well with Markdown, Dennis writes his product documents in that format. To avoid reading raw syntax all day, he uses a rendered preview pane.

1. Preview: The Markdown Preview Enhanced extension automatically opens a formatted pane when he selects a Markdown file. This avoids needing to remember the Command-Shift-V keyboard shortcut.
2. File organization: Product artifacts live in a dedicated local directory that Cursor can search and update.
3. Version history: Dennis keeps the documents in Git. He is also exploring whether product artifacts should live beside the code they describe in the same repository. This adjacency could encourage engineers and AI coding assistants to refer to the most current requirements, rather than an out-of-date PRD stored elsewhere.

"I'm wondering is that if I think I wanna start to see if the artifacts are actually sitting inside the repo into which the code is being developed, adjacency actually encourages the engineers and the ai. Coding assistant to continually have access to this."

Publish a PRD to Confluence for team feedback

Dennis drafts locally in Cursor, then uses an MCP connection to move the document into the collaborative systems where colleagues can comment. At Chime, this means publishing to both Confluence and Notion.

1. Write: The PRD remains a local Markdown file in his product directory.
2. Check tools: Before making a request, Dennis confirms that the relevant MCP server is enabled and available in Cursor’s settings pane.
3. Publish: A natural-language request tells Cursor which document to publish and where to send it.

Let's publish it into Confluence. Don't overwrite the other one we already pushed, make a copy please. And I'm demoing this capability!

A previous successful run showed the Confluence tool creating the page and writing its URL back into the local PRD, closing the loop. The live publish attempt in this episode failed because the MCP server was having problems, a realistic reminder that a conversational interface still depends on authentication, configuration, and service availability.

Review comments and draft replies

After colleagues add comments in Confluence, Dennis asks Cursor to read the page, organize the feedback, and suggest replies instead of processing them manually.

1. Retrieve: The MCP reads the latest comments from the published Confluence page.

Looks like people have been commenting on the PRD. Please go through the comment one by one and let's see how we'll respond.

1. Organize: Cursor grouped the comments into high-priority, medium-priority, and clarification categories, then drafted a response to each one.
2. Approve: Dennis reads each comment and its proposed response, applies his own judgment, and decides which replies to post.
3. Post: The authenticated MCP publishes only the responses Dennis approves, posting them under his account. He notes that his colleagues are aware he uses AI in this part of his workflow.

Turn the approved PRD into linked Jira work

Once the PRD is finalized, Dennis asks Cursor to create the implementation structure in Jira. This keeps the full product context available for generating high-quality tickets.

1. Epic: The prompt names the destination Jira project and asks for a parent epic based on the PRD.

Read the PRD and create an epic in the TIA project.

1. Stories: A second request creates individual stories and links each one to the new epic. Dennis added a Cursor Rule for this after earlier attempts created orphaned tickets that weren't properly associated.

Let's create story tickets that are all associated with the parent Epic for this feature.

The generated tickets included detailed descriptions, Gherkin-style scenarios, and acceptance criteria. This level of detail is often lost when a busy PM manually creates tickets and just links back to the PRD. The tickets remain generated drafts for the team to inspect and change, not a replacement for engineering review.

Derive a weekly status report from Jira

To prepare status updates, Dennis uses Cursor to query Jira directly instead of gathering updates manually across Slack and other channels.

Let's write a status report and describe everything that has happened since 9/24 for this epic I'll give it this epic here.

The Jira MCP writes JQL, checks for state changes and comments, and drafts a report. Dennis first refined the report format interactively, then saved the final structure as a Cursor Rule for weekly reuse. He also noticed a positive side effect: engineers started adding more detailed comments in Jira once they knew those updates were being read and used in status communications.

Prototype an AI agent before building the app

Dennis began his idea for a personalized morning-briefing agent in a ChatGPT Project. Repeated daily use helped him observe when the model’s memory and context worked well, and after about a month, he noticed the briefings began to drift and become less relevant.

Test the behavior in a general chat product

For the initial prototype, Dennis repeatedly used a simple two-word request, morning briefing, and let the project rely on its existing conversation history for context.

Write me a morning briefing based on what you know about me.

After about a month of useful results, the briefing became less relevant and stopped including topics he expected. This degradation gave him concrete questions about memory, context, and the need for explicit instructions to guide the next version of the product.

Make Cursor the prototype runtime

Dennis calls the next stage a "Super MVP." Instead of writing Python or TypeScript to implement an agent framework, he uses Cursor’s existing model access and tool-calling capabilities to run the product instructions directly.

1. Definition: He uses a PRD and a technical design document to describe the problem, desired output, and prototype approach.
2. Instructions: A Markdown file tells Cursor which user configuration to load, what tools to call, how to process the results, and how to format the final report.

The demonstrated instruction sequence was:

• Load the user’s briefing configuration and topic profile.
• Call the news-search MCP for the requested subjects.
• Read and summarize the returned material.
• Produce the briefing in the specified report format.

1. Run: Dennis references the instruction file with an @-mention and asks Cursor to generate that day’s briefing.

@super_mvp_agent_instructions run today's briefing.

Cursor executes the instructions, calls the news tool, and creates the report without a separate agent framework. The Super MVP workflow shows how Dennis compares behavior across models while keeping the prototype inspectable. Production still requires deliberate orchestration, authentication, and testing.

The verdict: a central hub for product context

Dennis’s workflow is powerful because it’s interoperable. The model can read a local artifact, call the systems where colleagues work, and bring new context back into the source document. When one connection fails, as it did during the live demo, the rest of the workflow remains inspectable rather than being hidden inside a black-box automation.

This system is worth copying for any product manager who spends their day translating the same core ideas for different audiences and tools. The most useful starting point is a single round trip: draft a document, publish it to a review system, and bring the comments back for human-supervised replies. Once that loop is working, you can add downstream automations like ticketing and reporting. It’s a practical way to reduce administrative toil and keep product context flowing.