Cursor for Product Managers

Rohan Varma Dec 4, 2025 45:00 109 transcript lines 21 terms defined Watch on YouTube Source page

Learn how product managers can move from planning into research, prototyping, and even shipping product changes.

Terms in this video

Transcript

Awesome. Well, I know we'll still have folks trickling in, but in the interest of time, we have a ton of things to cover. So, why don't we go ahead and get started? >> Happy to introduce myself. My name is Emily. I kind of run our workshop series and I'm on the growth team and really excited to see you all here today. >> Zoe, we'll kick it off to you.

>> Sure. Hi everyone. My name is Zoe. I am on our go to market team here in New York. Uh, I work with engineering leaders across the board to help them learn more about cursor, empower their developers, um, and totally transform the way they're thinking about engineering.

>> Sweet. And hi everybody. I'm Rohan. I'm one of the product managers here at Cursor. Um, and yeah, I work on some of our more like async agent products like Bugbot and Cloud Agents um, and lots of other random stuff. So yeah, excited to see what's good here. I'll pass it to Patrick.

>> Yeah, I can round us out here. Uh great to meet you all. U I'm Pat Coyle. I'm a part of the go to market org here at curser uh based in New York City and working with a lot of our enterprise customers uh throughout the northeast and uh the broader uh world.

>> Cool. So I guess yeah, maybe I'll just like kick it off and then Zoe, I'll pass it to you. Um so yeah I mean we're excited to share I think in general uh you know cursor obviously like we've always talked about our ICP for cursor is soft professional software engineers. Um I think what's interesting is we kind of expanded that to really just be about professional software engineering teams which obviously includes uh more than just engineers product managers designers. And what's interesting is if you look at

some of our largest customers actually like 15 to 20% of the cursor users are not uh engineers. they're, you know, designers, product managers, sales engineers, uh, a ton of different people can get a lot of leverage from using cursor. Um, and I think that, you know, we think in general, like a lot of the way that we operate at cursor is that we kind of build for ourselves and we build these products that help us build better and often those products end up being

super useful for other people. Um, and I think that that's pretty reflected in the way that we organize our team. you know before I joined the company so I joined the company as an engineer um like about like 6 or 7 months ago now um which I guess was relatively early uh relative to the company's life and so uh we didn't have any product managers and basically every engineer was just you know running like doing the N10 product development life cycle um I think one of

the superpowers that we have is that we uh build for ourselves you know like we basically are just we can immediately ship something onto Main and then there's like 50 engineers in the company that are trying So that's like we can we don't necessarily need a product manager to say hey like this is what's useful or this is good. But I think when I joined one of the things that was pretty clear especially as we started like building new products is you know there's a lot

of complexity that comes with that. How do we actually take it to market? How do we coales all of these things? Um which is I guess what kind of led me to like shift into this role. I think since then we've like hired some awesome other PMs like Jacob and Kevin. Um, and generally like what's been cool is that we've just been plugging into everything. You know, it's not like we just come up with I mean to be honest like until maybe a month or two ago there was nothing that

you would define or there's nothing titled PRD at the company. It was very much just conversations in Slack and people building stuff. But um I think now it's like you know just a lot of building prototypes like or and honestly like our prototyping just happens on main like we're just someone has an idea they just like we'll put up a PR. Um I think you know especially for the less like people that are not full-time engineering like myself now it's like

cursor is really just this like Oracle engineer that can answer any question or like help me figure out what's going on with some analytics event or like kind of like it's like using chatbt but it has like the full context of your codebase and essentially like a mini senior engineer baked into it. So um I think that you know that's what we've been doing. We've then, you know, as we talk to a lot of our customers, they're just getting it's the similar but like

even more value because they, you know, have all of these different processes that they've been doing product development with that cursor kind of just like cuts through all of that and now suddenly like a product manager can also be like shipping or can be like part of the like debugging process using things like MCPs to like like you plug into production logs and things like that. So um yeah, anyway, we're super excited. I think like in general we

imagine like you know the way that we talk about our mission as cursor is to create this AI powered engineering organization and I think product manager is evolving into like some new form of thing is definitely a part of that. Um so anyway yeah I'll pass it to Zoe but yeah >> thanks Rowan. Okay uh I'm going to share my screen. I won't be able to see the chat quite as well once I've done that. Um so please drop any questions in Q&A.

Pat and Rohan and Emily are all here to help answer questions. Um and then we'll also have some time for like open Q&A as well later on. Okay. So to get started today we're talking about cursor for product managers. Um I think Rohan highlighted this very very well when we're thinking about how can you sort of expand your footprint as a PM. Um so to get started all of you are probably pretty familiar with the software development life cycle. I think uh as Rohan mentioned, PM can look very

different depending on your company and even within your organization, right? Um some of you guys may be more focused on data and analysis. Some of you guys might be more focused on design. Um but typically what we see is that your your primary point of impact um where you're really creating those artifacts, doing the most uh decision- making is in the beginning of that life cycle. So thinking kind of in the plan phase. Um, a lot of the time that's where you'll write your PRDs, you'll come up with ideas, um, but

then you pass it on to maybe your engineering team or QA or someone else for for execution. Now that we're seeing AI come into the mix, we actually see that your footprint is expanded into all aspects of the SDLC. So, some examples may include across this uh, large timeline um, is thinking about codebased learning and research. So with cursor at your fingertips, we've made it a lot easier for non-technical users and technical users to get a really good understanding of the codebase from the beginning. Um

rather than having to wait for an engineer to explain certain concepts, they can dive in themselves, ask the agent questions, and really become informed on the products that they're working on. uh moving forward into creating a spec or plan. Now that you have that deep understanding of the technical context, you can bring that understanding into the work that you guys are already doing. So writing those PRDs um and that deeper understanding of, you know, how functionality works, how you expect

certain features to behave um in certain edge cases, that's going to really enhance the way that you're writing these plans so that you can deliver something with greater impact. Moving forward, we're actually seeing some of our PMs uh move into some of the developer space as well. So maybe not delivering full endto-end features, but if they want to do things like add a button or change the UI, they're able to commit PRs themselves and then have

engineers review them and push it into production. Updating documentation. Uh I think this is an important one as well. thinking about typically as you're developing you have to go back at the end to tweak the documentation and ensure that it's aligning with the changes you've made.

Cursor helps to simplify that as well. As you're working, you can ask the agent, hey, can you write some documentation for this? Can you upload it to notion or confluence or maybe one of your other tools or resources using MCP? And rather than having documentation become an afterthought, it can be something you're maintaining throughout the entire process.

Okay. Uh, actually jumping a little bit back to the beginning of the life cycle. Um, user research and analysis. I know I mentioned that before as well. Um, cursor really makes it easy to do some of that statistical analysis and work that you might be doing by hand. Now, so uh I've seen really great use cases of PMs maybe pulling in interview transcripts or pro or customer feedback and then having cursor help them with the analysis to pull key insights, uh

top pain points to be addressed rather than having to sort of sift through all of that manually. And then I think this is our second to last one, rapid prototyping. This is definitely a very common use case we see here at Cursor. Um, one phrase I love to hear is deliver demos, not memos. So, thinking about how can you play to your strengths as as product leaders. You guys have very strong product vision and know what you're looking for out of um

an idea. How can you take bring that idea to life, build your own prototypes um to share with your engineers and designers to help them understand what you're you're looking to build. And then our last one, thinking a little bit about uh webinar training and content. Uh cursor is really really great for helping to build out any sort of content where you're trying to make technical concepts uh easier to understand or more digestible. So think about using cursor

for creating training content for creating collateral for your marketing uh or sales teams so that they can use it um to better understand the product and also to share out with maybe external customers as well. Um so quick survey I'd love to see in the chat maybe with a Y for yes or an N for no. How many of you guys already have access to the code bases that you support? Oh, I'm actually seeing quite a lot of yeses. Uh, it's a good mix. Yes. No. Um, so typically when we ask this question,

we see about a 50-50 response. I think, uh, some people are very comfortable jumping into the codebase, looking around, uh, and getting us a feel for what the code actually is. Uh, while others can find it to be a little bit more intimidating. So, we want to encourage you guys to actually get access to your codebase. Um, with cursor, it doesn't have to feel as intimidating. uh you really can uh start to explore and answer some of the questions you might have on your own. Um and there's there's two standard

workflows we typically see our PMs use when working with cursor. So the first would be to build from scratch. So that would be similar to what I was talking about in terms of like reviewing transcripts, uh doing some of that data and analysis. I've seen people do some market research as well, um all within Curser. So, how can you build tools to help support some of the workflows you already have? Um, and then the second use case would be what we call engaging

with an existing repository. So, this is what some of you might already be familiar with. Uh, having your dev environment set up, learning more technical concepts, and then using access to that code to actually create different planning artifacts like PRDs, Jurro tickets, shipping small changes, etc. Um, so we're going to actually jump into some demos now. Now, I know it's a lot more fun to see cursor at work than to just hear about uh what it can do.

Um, but here's just a few ideas that you guys can take away from today's session on what you can do with cursor. Uh, I think I've found that the limitation isn't really around the creation side of like what can cursor do. The limitation is more around your imagination. So, thinking about what do you want to build? um and like how are you thinking about going about solving some of these interesting questions that you're dealing with. So I encourage you guys to

mess around and if you have ideas just bring it to cursor and see what you can produce. Um so yeah the different demos we'll talk about today uh building from scratch might be building some of those internal tools I discussed. Uh thinking about working in an existing repository. You can do different project planning, generate different product artifacts. That's what we'll look at in our demo.

Um or we can think about building from scratch or building from an existing repository and that would be things like your rapid prototyping uh making PRDS and then using uh cursor to help bring your hypothesis to life. Okay, so I'm going to switch over now into our IDE.

Okay, so this is the cursor IDE. Uh right now I am in what's called our agent layout. Um, some of you guys might be familiar with this. Uh, I think agent is a really great place to start. Uh, especially if you're a non-technical user. We're seeing both on sort of the technical and nontechnical side. Agent layout is really the direction where a lot of people are are starting from. Um, and so this should feel pretty familiar if you're used to using things like chat

GPT uh, Claude where you have your agent chat front and center. um you can see your chat history on the lefth hand side and then still if you're interested in looking at the codebase as well uh you have that on the right hand side of your screen as well. Uh so as I mentioned before I think a great place to start when you're working with a new codebase is always to just get a lay of the land like what is it that we're looking at? What are we working with? So I'm

actually going to change from agent mode into ask mode. Uh and what ask mode does is it blocks the agent's ability to write code or change any files. So what we're focused on here is just exploring the repository, getting an understanding of the codebase. Um so the very first question I'll ask is what is the application in uh PM demo?

What are the key components? And here I'm using Sonnet 45. Um you saw I was able to pull in specifically this PM demo folder into the context. uh it just happens to be a larger codebase and I wanted to focus specifically on this application. Um and you'll see that it's doing a little bit of thinking uh reading through all the files and it will pop out an answer to us to help explain what this demo is. Okay, great. So you can see it's given us a short

summary. It's highlighted the three different components and it's going in to describe even some of those technical specs as well. So right now we're looking at a recruiting operations demo that we've built here. Um, and essentially what this tool is is it helps evaluate different vendors um, and do some of the recruiting that a company might have to do. So, we're actually going to focus specifically on this second component today, which is the waterfall, which helps us evaluate different vendors for different

decisions. Um, but you see that we also have a sourcing tool as well as like some PM research, which might be something that you're interested in looking at as well. Um, it gave us a quick summary of the different tech stack. what's the front end versus the back end built with uh our database some of the key features and then it tells us where the different components are running. Um so as I said we wanted to focus a little bit more on the second

component the vendor waterfall. So I'm going to ask the agent how does the waterfall system work? Very simple question. Um hopefully it can kind of provide us with some more details as we're diving in to understand how this piece of functionality works.

Okay. So it explains to us it's a vendor prioritization and orchestration uh tool for recruiting data procurement. It's going to break down uh the concept why we would want to use it. Um and honestly this is all very helpful. Um, but you know, maybe you're a visual learner, maybe you don't necessarily want to read through all of this. Uh, it's starting to reference some of the code that might feel a little bit confusing. Um, so as a follow-up question, hopefully this

finishes running soon. I'll actually ask uh cursor to generate a visualization of the waterfall system using mermaid. Um, mermaid is just a a tool that's used to uh derive mermaid diagrams. Um, so we'll see if we can get some nice visualizations for this this tool as well.

Okay, so it's generating the tool. Let's see if we can get some. Okay, it's not bad. Yeah, I' I've run this demo a couple times and sometimes you get more colorful diagrams than others. We'll see. Okay, we got some good ones. Uh, so this is the first flow that we're seeing here. Um, so essentially what we're doing is we're evaluating one vendor at a time. If we find a success, we're going to exit this loop. Otherwise, we're going to continue working down the flow until we find somebody that works. Uh we have some

other diagrams showing standard versus optimized configurations. Uh a visualization to understand that quality score, some of the system architecture, before and afters, a lot of different visualizations here. So I think overall with cursor what I'm I'm trying to demonstrate here is you can really create a lot of different tools to help you understand what you're working with um and then use that understanding to move forward. So we've seen that in this

system uh we have a quality score but let's say we were more curious about geography right so maybe depending on our use case a vendor is better in a certain region let's say in AMIA than they are in the Americas. So, let's quickly ask, does the current waterfall system include Mina Hack and the Americas in the analysis?

Uh, and you'll see I had a couple of typos in that prompt, but cursor is very good at understanding what you mean, so you don't have to worry about always typing things 100% perfectly. Okay. So, as it as it's running, um I can actually tell you the answer to this question. It's no. It we have the data available for some of this, but it's not actually included in the analysis. Um oh, I guess my prompt was not specific enough. Uh I said here maybe it doesn't include it in the analysis. Let's see.

Uh it's recognizing that the data is there, but it's not actually included in the um Okay, so here it is. It it recognized it down here. uh the data is included but it's not actually uh incorporated into the actual logic already. Um so maybe that's the change that we want to make. Um so we're still in ask mode here. We still haven't even generated any code. Let's just ask cursor if it can help us create a plan to do that. So outline the simplest way to incorporate geography into the

waterfall system logic. Okay. So cursor will kick it off. Um and once again in this whole process I've been using the same uh model this whole time. I've been using sonet 45 tends to give me pretty good results. But you have the option within cursor to Oh, might be a little hard to see. Let me see if I Okay, it's it's getting cut off a little bit. But you have the opportunity to actually switch and use some different models within cursor as well. Um, so if

you wanted to use Opus if you're a big fan of that, uh, we also have our own built-in model, Composer 1, which was it's a Frontier model that's built specifically for coding. Um, and we highly recommend. It's very intelligent and very, very fast. um you can switch and use whatever uh model you think is best for the task at hand. Um so yeah, as we can see it going, it's coming up with a an approach. It's explaining why this approach is simple, what the expected impact is um and more. So I know we're

getting uh closer to the end of our time of our demo. So I'll just kick it off uh close out with one kind of final thing. I'm actually going to switch back into agent mode um to show you how you can use all of this to create some artifacts. So let's say uh please create a project text for this update in let's say geol location update.md.

Great. Uh so I'll kick that off. What this is doing now is it's actually going to write that uh create that artifact for us and save it into the repository uh in this markdown file that I've asked it to. Um, and one thing I want to note here is I've just asked it to create a markdown file and to save it on my uh in my local working space, but as I mentioned in before, you can actually go into your cursor settings and under MCP, you can connect with some of those external tools that you may

already be using within uh your different companies. So, Notion, Figma, etc. Um, and ask Cursor to save those documents there. So rather than just having this markdown file where I would need to maybe push it to the codebase and someone else view it, I can say, "Hey, can you actually just send this into Notion?" And then anyone in my organization with access to Notion can see the work that I've been doing here um in Cursor. Um this works great as

well with things like Figma. Let's say you have a design uh where you already know what you want the UI to look like. You can ask Cursor to pull that in. Uh maybe even start to create that mockup for UI as well. Um but yeah, we'll see. We see it's still working a little bit but it is creating the text spec. Uh it will go forward create that file and then we have that artifact that we can share with our team. We can even maybe go a step further ask a uh an agent to

take a look at this plan and to start building some of the things we've asked. Um but just wanted to give you guys a little bit of a sense of what you can really accomplish with cursor. I think we have a little bit of time now for Rohan to talk more about what they're doing in product cursor and also for us to answer some more of your questions. Uh, so I'll stop sharing my screen and pass it back to Roan. Now, >> Zoe, before you do that, I see a lot of

people asking about this new agent layout. Could you maybe share a bit more how you got here? Maybe the difference between the new layout and like the old one and how folks can switch between the two. >> Sure. So, uh, sorry for not seeing your questions, guys. Uh, so you should have a toggle up in the top that allows you to switch between uh, agent mode and editor layout. So, up in this top right hand side, you see this little arrow.

Um, so I just clicked it and it actually switched us back into our editor layout. So this is what uh engineers are probably pretty familiar with where you have your code uh editor front and center. You have your files on the lefth hand side and then you have your terminal here at the bottom. Um, so let's say I wanted to uh open up this other um file. I I still am able to to see it here to do my regular code editing. Um, but within agent mode, agent layout, which I just switched back to, you can see it's still working. Um,

we're really trying to create agent as sort of the center of the engineering experience, right? Um, as I said before, we're seeing a lot of engineers uh and and users of all kinds center their workflows around this agent experience. um and really only switch into the editor layout when they have more targeted changes they want to make to uh code files or if they wanted to like edit the markdown file for example that the agent had created. Um so yeah, this

was one of our our our new changes in our 2.0 release that happened I think just over a month ago. Um I I hope that answers everyone's questions. I don't know if there's anything else you would add Emily. Yeah, I think the way I really love switches lay out when I do prompting so I have like a full screen view. I add in all the context, give it um kind of review the code, but if I actually want to go back in and start editing and get it the last mile, then

I'll typically switch back to like the actual coding layout. >> But yeah, thanks Zoe. Just wanted to in while you had the demo up. >> No problem. I think it was like perfect timing because right as we finished uh the agent finished creating that file I mentioned. So you can see it's it's saying it created the file uh almost 1300 new lines. It explains kind of like an executive summary background and context uh including all of the information that we we went through. Um so yeah, pause here and I'll pass it

back to Rohan. >> Sweet. Um cool. Yeah. So I think like that was you know I think just on the topic of agent layout like one of the things that we've observed over the last like nine months is that the majority of people that are using cursor engineers or otherwise are typically like using agent the most and I think we actually see that product managers and like the kind of folks on the less technical side are obviously like you know diving into

agent because it can do just like larger chunks of work. So, uh, anything you can do in the editor, you can do in agent layout and but it also just like allows you to manage multiple agents and kind of do a lot more advanced workflows. So, that's kind of some of the the motivation. But, um, I think yeah, like I'll just like and also Emily or Zoe or Patrick, if there's questions that come up live like or that you think it would be worth chatting about, definitely just

like toss them out. But um I think in terms of some of the things that I thought it would be interesting to chat about is um just like more like advanced kind of like things that we are doing that I feel like get us a lot of leverage um at cursor and that I think that like most mostly in the past have been pretty hard for someone who's like in more an engineering role to do that now is like super doable with cursor. Um I think the the first thing I would say

is that if you haven't already within your company like I think getting cloud agents set up to some degree is going to be like a huge leverage point. Um we basically you know so just highle cloud agents is a way for you to have like think about it like as an engineer with a with a laptop in the cloud is kind of like what a cloud agent is. Um and all of the products that we've built have enabled uh are basically ways to orchestrate that developer through like

Slack, through linear uh through the ID itself. Um and so that's been like basically it's a way for you to be able to just like kick off tasks into the background and of and it's very useful especially for asking questions. Um, I think that like the the way that we've started or the way that I've started to operate is basically if there's ever a point where I need if I ever think that I need to like talk to an engineer about something like I'll usually just go and

ask cursor as the first step. Um, I think that in general like and you know cursor is extremely strong for like onboarding new people to your codebase whether it's an engineer or otherwise and because basically answering questions is probably one of the strongest uh use cases slash things that the agent's going to be really good at. Um, so I think that like that's probably an immediate win is just like every time you have a question like probably just

go to cursor and ask. Uh, and I think that like the types of questions at least that I found extremely useful. Uh, often are like, you know, how does how does this thing work? Like let's say like I'm trying to make a change to like something I'm working on right now is for Bugbot. We're trying to think through like the way that the funnel of like people get onboarded to the product and when do they activate and so I'm actually just like brainstorming with

cursor on that because it can basically just tell me what is the status quo very exhaustively much more than I could and kind of like what are all the nuances around maybe feature flags that we have and like data states that people could get into um and you know or is like this analytic event instrumented in this way or like I see this thing in our data what does that mean um or you know there's this inconsistency why is that this way so there's basically you know

all of these like pretty nuance questions that maybe you would need to talk to a data scientist for talk to an engineer or like go and stare at some code for like a couple hours that I think you can get like pretty much instant answers to. Um so I think that's extremely useful. The other thing is and we kind of touched on this a little bit but I would also invest and just spend some time thinking about MCPS um in general like cursor. So an MCP basically

just a way for cursor agents to communicate with external third party systems. Um, and for example, let's say the linear MCP, uh, it enables cursor agents to be able to read tickets, to be able to write to tickets, create new tickets, projects, things like that. Um, so I've like met some, uh, PMs or engineers where they'll actually just use cursor as the front end to linear.

Um, for example, let's say that you want to do like, uh, you want to prune your backlog, like you have like hundreds of tickets that are in your backlog um, or that are just maybe stale. You can actually just have cursor agent go one by one and determine has this has the problem in this ticket actually been solved and it'll go and it'll pull the context from the ticket or and you can actually don't say a specific ticket just say go to this project and look at

all the tickets and mark all the ones that are solved as done. Um, and what it'll do is it'll go to the ticket, then it can go back to the code. It'll actually look at the git history. It'll see, were there any, you know, commits that were pushed that are relevant to this? Does the problem still exist in the code? It'll go and updates the comments on the ticket. Then maybe it'll like surface to you a question about it. Um, it's just like extremely leveraged

and like or you know that's like maybe backlog focused. Another thing which I think we do which I think is also like probably a level up is being able to like every time someone starts actually building something they can essentially start with like a 90% of the PR complete or an entire plan or architecture diagram like basically leveraging cursor to go to each ticket that you've created or a PRD or whatever it might be and basically actually define a plan. Um and

often I mean it can go for more than the plan it can even have a PR. Uh but I think that in general there's no need to like like with cursor I think there's like no like cold start necessarily when picking up work um because you generally are just starting um with some type of like agent evaluation or investigation and then you can kind of take it from there. Um the other thing is I would say like and on the MCP topic is so we also use data dog for observability. Um and

so I use the data dog MCP extremely heavily. they actually have a cursor or a VS Code extension that you can install that should also install their MCP. Um, and so like let's say that there's like a user that has some issue. Um, maybe you have like a user ID or there's like some data that's wrong. Basically like you can just tell cursor with the data dog MTP um plugged in to go investigate this and it'll go and you know sift through all the logs like look at

different timestamps like resolve things against what's going on in the code and then come back with like a really thorough analysis. um much more thorough than you know like at least I would be able to do uh if I was to do it actually and I'll just share because I have a little example here um so this is yeah this is like my instance of cursor um you can see here I basically had this question where there was some sort of issue with a payment for a specific user with bugbot I actually kicked off what we call like a

multi- aent experience where I had five or four different models you know go and investigate so composer one took a look cloud 45 opus Sonnet GBT51 um I guess GBT51 stopped for some reason but basically they all like went and you can see that it's like running you know tons of searches searches against the logs using the data dogmcp it came back and kind of like was able and I mean this I did this a while ago so like but it came back and I was able to actually

like fully debug the issue um and kind of have multiple different models take a look at it and so uh this is like something which is like you know in my opinion like pretty incredible and like because I like hate using you know the UI for data dog. So it just like makes it super easy for me to like get access to that data in a much more ergonomic way. Um so yeah, I think like MCPs is probably especially as a product manager going to be like something that makes it

really easy for you to just like manage things across multiple tools, different data living in different places. Um and all of that. Uh, and then I would say like the last thing that is probably like another way to just get a ton of leverage is like basically getting into a mode where you can actually just take off and like like all the small things that your team is never going to get to like the P2s and the P3s. Um, you know, maybe like small UI stuff like basically

like getting to a point where you can like actually just push code for all of those things I think is like extremely uh like is a very like like a very doable place to get to. um you know at cursor basically like product managers but also like product designers like I would say like own a lot of like the front end and a lot of the user experience and are mostly like iterating on that without any sort of like you know like very autonomously. Um and so I

think you know obviously this might require like things like getting your dev environment set up but also using things like background agents you can uh kind of do this extremely quickly and like you know integrate with we have like integrations into things like linear so uh small tickets can basically just be completed by background agents you can use bugbot to review the output so then it actually you know generally seems like like basically to make sure

that there's no big issues and then uh you know tested on a local dev environment whatever it might be so um I think a cursor at least like we're able to move extremely quickly because the people like product managers, product designers, like everybody that has opinions about what should be done is actually super empowered to just go and make the changes and so um there's a lot less like deliberation um and we can actually just you know look at the

output in like the product and say like this is good or we need to change it because we can then quick quickly iterate on it. Um, so yeah, that's like, you know, some of the things that I think I see us doing. And then actually the last thing I was going to say, um, is at Cursor, we've actually, so I mean, I don't know if you've seen some of the posts from Rio, who's our head of design. Um, but we've created like, and I've seen actually a bunch of different

teams, like one of our customers, Dualingo, they've also done this. um and a few other like especially consumerf facing uh customers. But basically like one thing that's really useful is like prototyping um and being able to just express ideas really quickly with prototypes. Uh with cursor you can basically very easily create pretty sophisticated prototypes. Um and one of the things that we've done is we've built like what we call baby cursor uh

which is essentially an instance of cursor that is like fully standalone that's not like as complicated from a backend perspective but very like featurerich in terms of the user experience. Um, and then our design team will just use that to essentially iterate on some prototypes or kind of build out different UX patterns that they might want to try out. Um, and I think that like basically getting into a place where you can easily build prototypes about your code like that are not necessarily needing to take on the

full complexity um, of making a full PR is like something that's worth investing in because then it's like super easy to just express ideas much more directly with a URL to a live product demo uh, that actually can be interacted with rather than um, you know, some type of PRD that's like a bunch of text or like something like that. Um, you know, obviously like expressing ideas through text is still good, but um I think that there's like, you know, a lot of

leverage from being able to share just like live like interactive products. And if anything, like it's a lot easier to build those than it would be to create like an interactive prototype with something like Figma um because the agent can just like you know build a fully functioning web app uh that you can maybe deploy onto like a local or some sort of internal system or something like forcell things like that. So, um, yeah. So, anyway, those are some

of the things that I think like we get a lot of leverage from in cursor. Um, yeah, curious if there's any questions, Emily, or if you want to jump into the Q&A stuff. >> Seeing a ton of questions, so apologies in advance, we won't be able to get to all of them. I'm curious. I think you probably high level touched on it, but seeing a lot of interest like where do we think the role of PM is evolving? How will they work with engineers and UX designers? Um, and how can we convince engineers? I think I'm seeing a lot of

folks in bigger companies say they have to go through five levels of approval to get access to cursor. Any tips there? [laughter] >> Uh, yeah, just keep banging on the door for cursor access. We will find our way to you eventually. Our GTM team will hopefully come and help spread the word.

But, um, I think like at least the way that I think about it is like with cursor like our goal is to essentially automate coding, like the coding part of product development. Uh, and really like one way to think about that is that when we want to make it as easy as possible, like basically like create no distance between you have an idea and it's built. And so I think what's interesting though is that if you remove that like build step as like a big part of the process,

you kind of like what's important now is like on either side of that which is deciding what to build and then making sure that it works, deploying it, you know, like taking it to market, all of that. And so I think that like the role of a PM uh, you know, has always like been focused on that. What should we do and why should we do it? And so I think that becomes even more important because if if you can build something super quickly that means like you can probably

build a lot of bad things really quickly or things that don't need to be done. Um and so I think that in general like in my mind the role of like one of those superpowers or like things that I would invest in is just like becoming like a super strong like expert on like what customers want, understanding users, like basically like just leaning into that even more. Like what you probably want to shy away from is managing engineers like doing task tracking like

all of that stuff is like more and more going to be automated or le like less necessary. Like a cursor every part of our product that you would have like a five person engineering team for is one engineer just managing their work doing great you know having a great time like they don't need a PM to like tell them what to do. Uh but what's helpful is like brainstorming with that person like bringing in user feedback from different types of users and like you know what I

spend most of my day doing is just like talking to people about cursor and uh you know getting feedback on our various products and you know different enterprise customers individual users teams and I so I think that like in general uh that will always be extremely important [laughter] and I think that you want to like do that as much as possible because the once you know what to build it's going to be really easy to do it hopefully with cursor. So, it's

like having that user empathy is probably more important than ever. >> And then I'm seeing a more tactical question. I think a lot of folks are interested on like model selection. There's a ton of models. Um are do we have specific models you'd recommend for different tasks such as planning and agent mode and kind of how do you think about model selection?

>> Yeah, totally. I think I mean one thing at least at cursor is like you know we're and most of our like frontier customers are like very cost insensitive. So like I would always recommend using for like a planning or like a kind of thinking task I would use like the most frontier model that you have available. Uh for us you know that's often something like GPT51 or opus 45 um or even like something if we need like something and if quicker answer it's like composer one is also kind of a frontier intelligence. So I

think that like generally it's like worth using something better to get the right answer. Uh, in fact, like I was demoing like I'll usually ask questions like in a best of four like I'll have four models go and try to like get the results. Um, because it's just so valuable to get like if it cost me a dollar that's worth it. Um, when it comes to actually executing so like that those would be the models I kind of think of for like planning and I think

internally like we usually use that to like come up with a really detailed plan um or answer a question. I think like for example most of the frontier models given a very detailed plan will always probably execute correctly on that plan. And so then at that point speed is often like very much like a lever. And so for execution at least internally a cursor like we mostly use composer one um you know kind of plan mode with maybe like a beefier model than composer one to

actually execute. Um and I think like we've seen pretty good results with that. But I mean in general I think we believe that different models are good at different things and that'll be true like more nuance depending on your code base depending on the types of problems you have. So I think like just playing around with different ones and building your own intuition is probably like a good approach. Yeah, if I had to add one quick thing to that, I think you you explained it perfectly, Rohan. How I like to frame it

when I'm uh talking with different engineers as well is or framework I use is think of like every model across three different criteria. One might be performance, one might be cost, and one might be speed. You're going to need different amounts of of those things for different tasks. So, it's up to you to kind of experiment and figure out like when it may make sense to use a model that's maybe has higher performance but is more expensive. Um, versus like when

it works to just like go with the fastest model and you and you know you'll still get a good uh output. >> Zoe, do you see any more questions in chat? I'm seeing a ton trying to figure out which ones um would be best. I know there's a lot of good >> I think there was like some questions around like context windows that view and like I think that so in general yeah like you know these models have a limited context window I mean it is quite large at this point like you're

not going to easily hit up against it but um at least with cursor so for our agents as you keep using you know so the idea of the context window is like for most of these frontier models it's about like 200,000 tokens uh which is uh you know you can think of like a single token as maybe like half like 75% of a word so like um I think What I find is, you know, we try to make it really easy for you not to have to think about that in cursor. Uh, as the context, we have a

little like icon that'll show you how much the context window is used. Uh, like if I go actually this is a good example. Um, so like this chat that I was showing like if you go down here, you know, it'll show you for like cloud 45 opus 160k tokens out of 176k. Um so like as you get filled up so like probably the next time I asked something in this chat it would actually auto summarize and kind of condense and compress the context window. So in general you don't have to think about it. Um you can also like automatically

do like slummarize. Uh but the one thing I will say is that as the context window gets filled up like as you get to maybe like more than like 50 to 60% of the context window there will be like a slight degradation uh potentially in like the way that the model performs obviously depending on the model. Um, and so one thing that people like one thing that people don't realize is like it's actually really good to create new chats and like or create a new agent uh

when you're doing a different task and you don't want to like kind of have that old context living in the agents history for something like completely unrelated like it might just throw it off off its tracks. And so uh you know we've I think like we were looking at the data and there was like someone that has had the same exact agent like from like I don't know like a couple hundred days and has just been using it and like that's definitely not the move. do not do that.

Um like I would like kind of try and like think about it as like yeah like this is another thing that I should like make sure is not um filling up like but we'll like take care of it in the default but you can also kind of proactively like remove context by creating new agents.

>> One thing I did also want to say is internally we have slack integrated with cursor and we've seen a lot of PMs really like jump in and make changes through that. For example, we have an AWS bedrock integration. We had no docs on it and I kind of dropped that into Slack. cursor kicked it off, looked through our code, created the docs, an engineer jumped in and flag like two issues that were wrong. We had cursor go in through the Slack thread, update the

docs, and then it was shipped. And that was kind of happened within 15 minutes all over Slack. Um, and so I think making those quick documentation updates where you work um is also kind of something we do internally a lot. Okay. Well, I know. Final question. I'm guess are there any best practices for thinking how we build projects and do prompts that are AI first? Should we be kind of writing PRDs with AI in mind? Um, curious your thoughts there, Johan.

>> Yeah, I mean, I think like yes, I guess like the optimal thing would be that like you could take the PRD and like kind of have an agent go and work on that. I mean what we do actually sometimes will we just make the PRD like as a file in the codebase and the PRD will include things like how to break it up into how to break up this project into PRs and like what are the stages and what's the architecture and then we'll actually do code review on

that uh as a way to iterate and so I think I mean if the PRD can exist in the codebase then the agent can actually use it as a source of truth uh like or an engineer can basically have multiple agents working off of it um so I mean it's something to experiment with I think like ideally the PRD is like ultimately a useful artifact for the execution phase and the more it can like be like descriptive of what needs to happen and exist with the codebase then

I think like the easier that'll be. So um definitely worth like playing around with. >> Awesome. Well I know we are at time we answered 88 questions and had 64 unanswered. So if you have any other ones feel free to reach out to me Emily at cursor and happy to answer there. And we are thinking about potentially creating like a community for PMs. Um, if that's interesting, could maybe folks raise their hands so we can gauge interest. Okay. Well, seeing 100 plus. So, sounds

like that's cool. I'll tell Kevin, our PM, he before this, if that sounded interesting. So, thanks again for joining. And the recording will be shared after. And I'll also kind of pull folks to see I saw a lot of questions about prompts and best practices and case studies. Um, if that's interesting too, we'll gather that for you guys. But, thanks everyone.

>> Thanks, guys.