I Stopped Using Cursor Like a Developer. I Started Using It Like a Product Manager.

Product Managers don’t need another AI chatbot. They need an operating system.

When Cursor first became popular, almost every video, blog, and tutorial revolved around one thing:

“Look how fast it writes code.”

As a Product Manager, I remember thinking…

“That’s great… but where do I fit into this?”

I don’t spend my day writing React components.

I spend my day understanding ambiguous requirements, talking to stakeholders, writing PRDs, breaking features into stories, creating workflows, reviewing designs, and helping engineering teams build the right thing.

For a long time, AI felt like it belonged to developers.

Then I discovered something that completely changed how I use Cursor.

Cursor isn’t just an AI IDE.

It’s an orchestration platform.

Once that clicked, I stopped thinking about prompts. I started thinking about workflows.

Instead of asking ChatGPT to “write me a PRD,” I wanted something that behaved like an experienced Product Manager.

Something that followed a process.

Something that asked the right questions before giving answers.

Something that wouldn’t jump directly into writing User Stories without first understanding the business problem.

That’s when I built my first Product Management Agent.

It Started With a Single Command

Instead of opening a blank chat and writing enormous prompts every day, I now invoke a single command.

/analyse

The input can be almost anything:

• A rough requirement
• Meeting notes
• A Business Requirement Document
• An Azure DevOps or Jira Work-item
• Even a few bullet points copied from Slack or Teams

The agent’s first job is not writing a PRD.

Its first job is understanding.

It identifies:

• What problem is actually being solved
• Who the stakeholders are
• Missing assumptions
• Business rules
• Functional requirements
• Non-functional requirements
• Risks
• Dependencies
• Use Cases

Only after building that understanding does it generate a structured Product Requirements Document.

But here’s where it gets interesting.

This isn’t a one-off output.

This is the first stage of a workflow.

From Discovery to Design to Delivery

Once the requirement is analyzed, it doesn’t stop there.

The output is handed off.

PM Analyst → PM Designer → PM Deliver

PM Analyst

• Converts raw input into structured understanding
• Produces a Top 1% quality PRD
• Identifies gaps, risks, and assumptions

↓

PM Designer

• Translates the PRD into user journeys
• Creates swimlane diagrams
• Builds sequence flows
• Generates working HTML prototypes

↓

PM Deliver

• Converts everything into execution-ready artifacts
• Creates Features, User Stories, Tasks
• Defines Acceptance Criteria
• Generates Test Scenarios

And this is where it becomes extremely powerful. The Deliver stage doesn’t just stop at documentation. It connects to real systems.

Using MCP-style integrations, it can:

• Create Features in Azure DevOps
• Push User Stories into Jira
• Structure and prioritize backlog items automatically
• Maintain traceability from PRD → Story → Task

This is no longer just “AI helping you write.”

This is “AI participating in your delivery lifecycle”.

The Biggest Shift: I Stopped Prompting

Most people think using AI is about writing better prompts.

I’ve started to believe it’s about building better systems.

Instead of asking AI to “be a Senior Product Manager” every time, I created an environment where it already knows its role.

That environment is made up of four key building blocks.

Understanding the Building Blocks

1. Agents

Agents are roles.

Think of them as specialized Product Managers.

• One analyzes
• One designs
• One delivers

Each agent has a clear responsibility and doesn’t try to do everything. This separation is what makes the outputs consistent.

2. Commands

Commands are how you invoke behavior.

Instead of writing long prompts, you trigger intent.

/analyse

That single command activates:

• The right agent
• The right workflow
• The right structure

This is very different from traditional IDEs or chat tools where you repeatedly explain context. Here, invocation is standardized.

3. Skills

Skills are reusable capabilities.

Think of them as modular expertise.

For example:

• Requirement analysis
• PRD structuring
• User journey creation
• Story breakdown

Instead of rewriting instructions every time, skills are referenced and reused across agents. This is what makes the system scalable.

4. Rules

Rules define behavior. They ensure consistency. They guide how the AI thinks, not just what it outputs.

This is where .mdc files come in.

Markdown vs Markdown Context

Markdown (.md)

These are knowledge files.

They contain:

• Templates
• Documentation
• Structured outputs

They define what should be produced.

Markdown Context (.mdc)

These are behavioral files.

They define:

• How the AI should reason
• What steps it should follow
• What constraints it should respect

They influence how the AI thinks.

This distinction is subtle but powerful.

How This Differs From Traditional AI Usage

In most tools today:

• You write a prompt
• You get an output
• You repeat

Every interaction is isolated.

In Cursor:

• You invoke a command
• The system activates an agent
• The agent uses skills
• Rules guide behavior
• Outputs are structured and reusable

It’s not prompt → output.

It’s intent → workflow → outcome.

Thinking in Agents Instead of Prompts

One realization completely changed my workflow.

A Product Manager doesn’t perform one job. We constantly switch hats.

Sometimes we’re analysts. Sometimes we’re designers. Sometimes we’re delivery managers.

Instead of trying to build one gigantic AI assistant, I started separating responsibilities.

Each agent focuses on a single responsibility before handing work to the next.

That sequencing alone has made the outputs significantly more consistent.

And more importantly, more usable.

Cursor Feels Less Like an IDE and More Like a PM Workspace

Today, I spend far less time staring at blank documents.

I don’t start with “Write a PRD.” I start with context.

The agent handles the structure. The designer translates it into flows. The delivery agent converts it into execution.

I focus on product thinking. That’s probably been the biggest productivity gain.

AI isn’t replacing my role. It’s removing repetitive work so I can spend more time solving actual product problems.

My Biggest Takeaway

If you’re a Product Manager who has avoided Cursor because you assumed it was “just for developers,” I’d encourage you to look at it differently.

Cursor isn’t limited to writing code. It’s a platform capable of orchestrating repeatable knowledge workflows.

And Product Management is full of repeatable workflows.

• Requirements
• PRDs
• User journeys
• Feature decomposition
• Acceptance criteria
• Delivery artifacts

The real shift isn’t better prompts. It’s better systems.

I’m only getting started, but building my first Product Management Agent fundamentally changed how I think about AI.

And this feels like the beginning of a much bigger journey.

How are you using AI in your product workflow? I’d love to hear what’s working for you.