Using Cursor as a Product Manager: faster answers, fewer pings

Most digital products are built from a thousand tiny decisions that live in the codebase: which users can see a button, what happens when a form fails validation, what we do when an API returns a 403, or why a flow behaves one way on desktop and another on mobile.

And yet, in many teams, the questions we ask about those decisions are still answered the slow way. A PM pings an engineer: “Where is this implemented?” QA opens a ticket that says “it breaks sometimes.” Someone client-facing asks in a hurry: “Can we change this?” The person with context answers, but at the cost of interrupting focus time, and often without leaving a trail that makes the next question easier.

This gets even harder in two very common situations: when you join a project that already exists (and you’re still building a mental map of the product), or when you’ve been on the same product for a long time and it’s grown into something big enough that no single person can keep the whole thing in their head. In both cases, the cost of “just figuring out where things are” quietly increases, and so does the number of pings.

Lately, I’ve been using Cursor to change that dynamic.

Not because it writes our product for us, but because it helps us navigate and understand the product we already have. Cursor can read the repository and explain, in plain language, how things are wired together, which makes it a surprisingly practical tool for building context fast, or refreshing it when the codebase has outgrown your memory.

This post is about how I’m using Cursor specifically as a Project and Product Manager: to get faster answers, reduce back-and-forth, and show up to conversations with better context.

Cursor in one sentence

If I had to describe Cursor in PM terms, it’s this: Cursor is an editor that lets you ask questions about your codebase and get guided, contextual answers with references to where things live.

That “with references” part matters. The value isn’t just an AI opinion; it’s that Cursor can point you to the routes, components, controllers, policies, and validations involved. You can then verify it quickly, and you can link those files in tickets or discussions so everyone is looking at the same reality.

The first use case: “Where is this in the UI?”

This was the problem that got me to open Cursor in the first place, and it usually starts the same way: a bug report arrives with a screenshot that shows only a fragment of the interface.

No URL. No route. No “go to Settings → …”. Just a cropped modal, a toast message, or half a form field with a confusing label. If you don’t already know that area of the product by heart, the usual next step is asking around in Slack: “Where is this happening?”, and waiting for someone who recognizes it. Cursor has become my shortcut for that moment.

Instead of guessing, I can give Cursor a clue and ask it to triangulate the location in the UI. Sometimes the clue is a string I can read in the screenshot (“Invite teammates”, “Something went wrong”, “VAT number”) or the screenshot per se. Other times it’s a component name we suspect, or even just a description of the interaction (“a modal to add a new payment method”). Cursor can search across the repo and bring back the most likely entry points: the components where that text appears, the route that renders them, and often the parent layout or page that ties it together.

The end result is that a “mystery screenshot” stops being a Slack scavenger hunt. I can quickly respond with something concrete: where it lives, what file(s) are involved, and what context might be relevant (permissions, feature flags, different variants of the same component). That alone makes bug triage faster, and it also sets up the next, more valuable question: now that we know where it is, what exactly should happen there?

From “where is it?” to “what happens when…?”

Once you’ve found the entry point, the next product question is almost always about behavior.

What happens when the user submits the form? Where is validation enforced? What does the UI do if the API returns an error? Does it retry? Does it show a field-level message or a generic one? Does the backend apply different rules depending on role or plan?

Cursor is good at turning those questions into a narrated flow, which is exactly what PMs need. A helpful way to ask is to frame the question around the user action and request the whole path, end to end:

“Explain what happens when the user clicks ‘Save’ on this form. Trace the UI state, the API request, the Rails controller/action, and how success and error are handled in the UI.”

These answers often reveal things that aren’t obvious from the UI alone: backend validations that the frontend doesn’t mirror, special cases for certain roles, or error handling that was implemented quickly and never revisited.

Even if you don’t plan to change anything, having the flow clearly described helps you document the current behavior and avoid assumptions in specs.

Impact analysis: scoping changes without surprises

Another powerful way to use Cursor is for impact analysis, the unglamorous work of figuring out what else might be affected when you change something.

Maybe you want to rename a field in an API response. Maybe you want to remove an option from a dropdown. Maybe you want to tweak a plan limit. The scary part is rarely the change itself; it’s what the change touches.

Cursor can help answer questions like: where else is this component used, which screens call this endpoint, where is this constant referenced, and what breaks if we change it.

This isn’t just useful for writing scope. It also helps you communicate risk and effort more accurately, because you can ground the conversation in the real places where the behavior exists today.

The “hidden rules” category: permissions, plans, and feature flags

If you’ve worked on a product for long enough, you know that a lot of product behavior lives in conditions.

A button is visible only if the user is an admin. A route is blocked unless your subscription tier includes it. A feature exists but is behind a flag. A flow is slightly different for legacy accounts. These decisions are often spread across frontend and backend.

Cursor is particularly helpful for uncovering these “hidden rules” because you can ask it to explain the conditions and point to where they live. When you do that, you sometimes find inconsistencies: the UI hides a button, but the backend would actually allow the action; or the backend blocks something, but the UI doesn’t explain why.

Surfacing these gaps early prevents the kind of issues that only show up in production when a particular role, plan, or flag combination hits the wrong path.

QA support: faster reproductions and better bug reports

In my day-to-day as a PM, I’m also the one driving triage and, quite often, doing QA as well. That means I’m usually the first person trying to make sense of a bug report: confirming what the “expected behavior” should be, figuring out whether it’s a regression or a misunderstanding, asking for the missing details, and turning a vague description into something the team can actually act on.

Cursor helps because you can go from a vague symptom to a specific place to look. If you have an error message, a toast notification, or an HTTP status, you can ask Cursor where it’s generated and what conditions trigger it. Then you can write a bug report that includes not just steps, but context.

“It breaks sometimes” becomes “Here’s the likely code path, the component, and the backend action involved.” Even when the hypothesis isn’t perfect, it narrows the search and reduces the number of follow-up questions engineers need to ask.

A simple way to ask better questions in Cursor

As most of you know, the quality of what you get out of Cursor depends a lot on how you ask. A pattern that works well is:

Start from the user action, ask for entry points, then ask for the full flow and edge cases.

For example:

“When a user submits the billing update form, what happens? Show me the React component involved, the API call it triggers, the validations that apply, and how errors are displayed in the UI.”

When you ask like this, you’re not just getting an answer, you’re building a shared understanding you can paste into a ticket, a spec, or a client explanation.

What Cursor won’t replace (and why that’s fine)

Cursor won’t replace engineering judgment or product judgment. It can misunderstand intent if your question is vague, and it can miss nuance when business rules are complex.

But as a tool for reducing friction: fewer interruptions, faster discovery, clearer tickets, and fewer interruptions, faster discovery, clearer tickets, and better alignment, it’s already paying off.

The biggest shift is this: instead of asking your team to translate the codebase into English for you, you can do a first pass yourself. Then, when you do ask for help, you’re asking higher-quality questions.

“I found the component and the controller involved, and it looks like the error handling is generic. If we want field-level messages, what’s the best approach?”

That’s a conversation about product and quality, not a scavenger hunt.

Prompt cheat sheet (copy/paste)

If you want a quick starting point, here are a few prompts that work well:

• “Where is the UI for ___ implemented? Give me the route and component files.”
• “Explain what happens when the user ___. Trace UI → API → Rails → UI.”
• “Where are validations for ___ defined (frontend and backend)?”
• “List all usages of this endpoint/component/event.”
• “What conditions control whether ___ is visible/enabled?”
• “Where are roles/permissions enforced (policies/guards)?”
• “Where is this analytics event fired, and when?”

Closing

From the PM point of view, Cursor has become one of those tools that doesn’t change what we build, but changes how efficiently we build it. It reduces the “time to understanding”, which is often the hidden cost behind slow delivery and messy communication.

If you want to try it, start small: pick one feature you don’t know well, find where it lives, and ask Cursor to explain the flow end to end. The first time you avoid a long Slack thread, and still end up with a better ticket, you’ll feel the compounding effect.

If you’re using Cursor in your own workflow (product, engineering, QA, leadership, client-facing), I’d love to hear what prompts and patterns have worked for you.