From the PMI talk · Partnering with AI

Cursor for PMs Who Build

I wasn’t a developer. I was a PM who needed something that didn’t exist off the shelf — so I learned to partner with AI in Cursor. The first hour feels complicated. This page is the path I wish I’d had: what it is, how to get in the door, and how to work once you’re there. Not a tour of every button.

What Cursor is (in PM words)

Think of it as an AI-assisted workspace that can see a whole project folder — notes, specs, drafts, HTML, whatever you put in there — not just one chat window with no memory of your files.

Copilot in Word helps you draft inside one document. Cursor helps when the work lives across files and you’re trying to build something: an action tracker, a status one-pager, a small internal page, a tool that fits your process.

When you open it the first time, it looks like a coding app. Ignore most of that. For a PM, you really need three things: a folder of sources, a place to ask, and the discipline to cut what’s wrong before anyone else sees it.

When to use it vs Copilot

Same quality bar on every tool. Approved tools only — check your company policy before you download anything.

Before you open it

Write the spec first. What problem, who it’s for, what it must do, how you’ll know it worked. AI came later for ATLAS. The specs are why people trust it.

Use Before You Build, Write the Spec — fill it in, hit Copy template, and save it as a file in your project folder (e.g. SPEC.md). That file becomes the ground truth for everything you ask next.

Also decide what not to put in the folder: passwords, customer data you shouldn’t share with a tool, anything your policy forbids. If you wouldn’t paste it into an approved chat tool, don’t drop it into Cursor.

How to get started (the part that feels hard)

Cursor is not “open a website and type.” You install an app, open a folder on your computer, then talk to AI about what’s in that folder. Here is a first-session path that works for a non-developer.

1. Confirm you’re allowed

   Check approved tools and data rules at your company. If Cursor isn’t approved, stop here and use what is — the craft still applies. Don’t invent a workaround with sensitive work.

2. Install Cursor

   Go to the official Cursor site, download for your computer (Windows or Mac), install, and sign in. You may need a work or personal account depending on how your org licenses it. If IT has a managed install path, use that.

3. Make a project folder first

   On your Desktop or in Documents, create a folder with a clear name — e.g. status-one-pager or meeting-actions-pilot. Put your sources in it before you open Cursor:

   • Your filled-in spec (SPEC.md or a Word/PDF you can paste from)
   • Meeting notes, old status, excerpts you’re allowed to use
   • Examples of the output format you want (a past one-pager is gold)

   Empty folder + vague ask = AI invents. Folder with real inputs = AI has something to work from.

4. Open the folder (this is the non-obvious step)

   Launch Cursor. Use File → Open Folder (or the welcome “Open project” path) and select the folder you just made — not a single file, the whole folder.

   You should see your files in a left-hand list. That list is how Cursor “sees” the project. If you only open one document, you lose the point of the tool.

5. Ignore the scary UI

   There will be panels, icons, and words aimed at developers. You do not need them yet. For session one, care about: file list on the left, chat / AI panel (usually on the right or via a chat icon), and the main area where files open when you click them.

   You are not learning to be an engineer this week. You are learning to open a folder and ask a clear question.

6. Start the AI chat with your spec

   Open the chat or agent panel. Paste your spec, or tell it to read SPEC.md in the folder. Use a starter from below — begin with outline / clarifying questions only, not “build the whole thing.”

   If the tool offers to edit files or run commands, pause. For a first build, prefer: it proposes a plan → you say yes → it drafts one file → you read it.

7. Read every change before you accept it

   When Cursor suggests edits, it will show what it wants to add or change. Treat that like a junior teammate’s pull request: skim the whole thing, cut what’s wrong out loud in the next message, then continue.

   Do not click Accept on a wall of text you haven’t read. Speed without review is how craft dies.

8. Save where you can find it

   Your work lives in that project folder on your computer. Copy the finished file wherever your team actually works (SharePoint, email, Confluence) only after you’d put your name on it.

Open a folder. Ask from the spec. Cut before you ship. That’s the whole game.

When you get stuck in the UI

• “It doesn’t see my files.” — You probably opened a file, not a folder. File → Open Folder again.
• “I can’t find chat.” — Look for a chat / AI icon in the side bar, or the keyboard shortcut shown under View / AI menus. Names move between versions; the idea stays: a panel where you type to the model.
• “It asked to run something.” — For a first PM project, decline unless you understand what it will do. Prefer file edits you can read.
• “The answer looks confident but wrong.” — That’s normal. Paste back: what’s wrong, why, and what to do instead. The cut is the work.
• “I don’t know what model / mode to pick.” — Use the default. Mode names change; your loop doesn’t: context → ask → review → cut.

The working loop (once you’re in)

1. Sources in a folder

   Notes, old decks, transcripts, your written spec. Context first — not “write my app from nothing.”

2. Ask

   Outline or draft only at first. Say audience, format, and what “good” looks like. Ask it to flag what it’s unsure about. Ask clarifying questions before a big build.

3. Cut what’s wrong out loud

   Wrong, fluffy, overconfident — delete it. Tell the AI why in the next message. That cut is the craft. Keep going until you’d put your name on it.

4. Ship small, review hard

   One useful artifact. Open the file yourself. Click through it. Don’t hand anyone a draft you haven’t read end to end.

The craft moment isn’t the prompt. It’s the edit.

First builds that fit a PM

Start smaller than you think. One finished artifact beats a half-built “platform.”

• Meeting notes → action table — Action | Owner | Due | Status. Lowest risk, highest reuse. Do this before you build anything flashy.
• Status one-pager — For leadership, from real sources in the folder. Outline first, then prose, then polish.
• Small internal page or tool — Something you’d use Monday (a simple HTML tracker, a checklist page), after a written spec. Not a multi-system integration. Not production automation on day one.

You are not “learning to code.” You are clearing a real blockage with a partner that moves faster — while you hold the structure, the story, and the standard.

Stop signs

• Unapproved tools or sensitive data in the wrong place
• Shipping without reading the output end to end
• Letting AI invent requirements you never wrote
• High-risk automation as your first build
• Accepting file changes or commands you don’t understand
• Anything you couldn’t explain in the room

Boundaries still apply — see What Stays With the PM. Treat first builds like experiments — see AI Experiment Playbook.

Copy-paste starters

Approved tools only. Point Cursor at the folder (or paste files). Cut before you share.

More PM prompts (meetings, risks, leadership): PM AI Prompt Library.

Accelerate the work. Don’t dilute the craft.

← All take-home resources