1 min lesson
A reproducible explore-to-spec sequence
Take "A reproducible explore-to-spec sequence" step by step, then finish with the result that proves it worked.
Step 1 of 2
A reproducible explore-to-spec sequenceAsk mode, then Agent - no code written by you
Here's a full PM flow you can run on any unfamiliar repo, demonstrated live and copyable end to end. None of it requires you to write code.
- 1Orient (Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition.). Pull the target folder into context and ask “what is this app, and what are its key components?” Ask mode is read-only, so it can't change anything while you learn.
- 2Understand the mechanism. Ask “how does this system work?” for the part you care about, then ask Cursor to render a Mermaid diagram of it so you can see the flow.
- 3Probe a gap. Ask a pointed question - “does the system include EMEA, APAC and Americas in the analysis?” In one run this surfaced that the data existed but the logic never used it.
- 4Outline the fix, still read-only. Stay in Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition. and ask it to “outline the simplest way to incorporate geography into the logic.” You're scoping, not building.
- 5Generate the spec (Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition.). Switch to Agent and say “create a project doc for this update in a Markdown file.” In the demo this produced a long, structured spec - executive summary, background, context - that becomes the artifact you hand to engineering.
Learn more
Full explanation
Orchestrate agents, don't just chat with one
Orchestrate agents, don't just chat with oneLinear, Slack, cloud agents, P2/P3 ownership
Once you can read a codebase, the next useful step is running work through it instead of asking it questions. An MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. lets a Cursor agent talk to external systems. With the Linear MCP connected, the agent can read tickets, comment on them, and create tickets and projects - so you use Cursor as a front-end to your tracker.
Point the agent at a project: “look at all the tickets and mark the ones that are solved as done.” For each ticket it pulls the context, jumps to the code, checks git history for relevant commits, decides whether the problem still exists, updates the comments, and surfaces open questions back to you. That's hours of manual triage turned into a review pass.
You can have Cursor go one by one and determine whether the problem in a ticket has actually been solved.
The same orchestration runs in the background - you kick off a task and a cloud agent works while you don't watch. Cursor's surfaces (Slack, Linear, the IDE) are all ways to orchestrate that cloud developer. For a PM, setting up cloud agents early is one of the most useful steps you can take.
Think about it like an engineer with a laptop in the cloud - that's what a cloud agent is.
Put those together and a real shift opens up: PMs and designers can own and ship the small things the team never gets to - the P2s, the P3s, the minor UI tweaks. At Cursor, product and design own a lot of the frontend and UX and iterate on it autonomously. The setup is a dev environment plus background agents wired to Linear: small tickets get completed by background agents, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. reviews the output, and you test locally. The payoff is less deliberation - anyone with an opinion can just make the change and judge it in the product.
Because you point the agent at a ticket or PRDProduct Requirements Document. The spec describing what to build, for whom and why, before implementation starts. Increasingly the artifact you hand an AI agent as the source of truth for a feature. Press Enter for the full definition. first, you rarely begin from a blank page. You start from an agent's investigation - often a plan, an architecture diagram, or a PR that's roughly 90% complete - and take it from there.
Every time someone starts building, they can essentially start with 90% of the PR complete, or an entire plan or architecture diagram.
Two practices make this run cleanly. Write the PRDProduct Requirements Document. The spec describing what to build, for whom and why, before implementation starts. Increasingly the artifact you hand an AI agent as the source of truth for a feature. Press Enter for the full definition. as a file in the codebase - include how to break the project into PRs, the stages, the architecture - so the agent can use it as a source of truth and an engineer can have multiple agents working off it. You can even run code review on the PRD itself to iterate on it. And keep a standalone prototype instance for UX work: Cursor's design team built “baby Cursor,” a fully standalone, backend-simple but feature-rich instance used purely to try new UX patterns. Duolingo and other consumer companies have done the same. It's a clean way to express an idea with a prototype instead of a PRD.
Speak the AI-product stackthe vocabulary engineers expect
An AI code editor lives or dies on a handful of technical levers. Know what each one is and the product tradeoff it forces, so you can debate it concretely.
Learn more
Full explanation
The AI-Product Stack
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The levers a Cursor PM trades off - eval sits on top because it is what tells you the layers below are actually working.
Make tradeoffs, do not just relay thembuild vs buy, scope, sequencing
- Data flow
- Can you draw where the request goes and where it can stall or fail?
- Failure modes
- What happens on a bad suggestion, a timeout, a wrong edit - and what does the user see?
- Build vs buy
- Use a model API versus self-host; reuse an existing index versus build retrieval - defend the call.
- Scope order
- Which slice ships first, which is cut and what that costs the user.
Be ready to take a position on each, then defend it under push.
Reasoning with engineers includes knowing when to pull one in. The skill is asking the right question - “what breaks if retrieval times out and what does the user see then?” - not pretending to have every answer. Engineers trust a PM who is precise about what they do not know far more than one who bluffs.
Buzzword fluency without mechanism is the tell. Saying “we will use RAG” means nothing; saying “we retrieve the open file plus its imports because that is the context the user is actually editing” shows you understand the why. Always ground a term in a concrete product reason.
Learn more
Optional practice