GTM, Enterprise and the 1,000 Paper Cuts

At Cursor there is no launch team waiting downstream of you. The PM who built the feature is the one who ships it, writes the changelog and watches the first hour of telemetry.

The JD is blunt about this: you own launch execution end-to-end with Product Marketing. That word with is doing real work. PMM is a partner who sharpens the narrative and runs the channels, not a function you hand the feature to so you can move on. You still drive the date, the gating, the rollback call and the story.

For a tool developers open every morning, a launch is not an announcement. It's a change to a workflow people already trust, so the bar is whether the new thing earns its place without breaking the old one.

The GTM checklist you actually ownnot a handoff doc

A launch checklist for a developer tool is mostly about readiness, not promotion. The flashy post is the last 10%. The other 90% is making sure the thing works, is documented, is priced and won't generate a support fire you can't put out.

Rollout sequencing with kill criteriaearn the next ring of exposure

You don't flip a feature to every Cursor user at once and hope. You expand the blast radiusHow much breaks if a change goes wrong; the scope of potential damage. in rings and each ring has to earn the next one. The discipline that separates a builder-PM from a roadmap-PM is writing the kill criteria before you start, so the rollback decision is a number, not an argument.

1. 1Dogfood. Ship it to the team and to internal heavy users first. If your own engineers route around it, it isn't ready for anyone.
2. 2Closed beta. A self-selected slice of real users behind a flag. Watch acceptance and retention on the feature, not just clicks.
3. 3Staged GA. Roll to 5%, then 25%, then 100%, holding at each step long enough to read the data and the forums.
4. 4Define kill criteria up front. e.g. "if Tab acceptance drops more than X% or p95 latency regresses past the budget, we pull it." Written before launch, not negotiated mid-incident.
5. 5Keep the off-switch live. Until GA is stable, rolling back has to be one config change, not a hotfix and a deploy.

Close the loop in publicthe launch isn't done at GA

Developers notice when a vendor ships and disappears and they notice when one ships and listens. The feedback loop is part of the launch, not a cleanup phase after it. Capture signal fast, triage it and be visible about what you're changing.

The individual developer wants to stay in flow. The enterprise wants control over what that developer's tool can see and do. Same product, two jobs that pull in opposite directions.

The JD calls out setting direction across individual and enterprise audiences and deciding what to build, cut and in what order. That's the hardest framing in the role, because the two segments don't just want different features - they often want the absence of each other's features. An admin control that reassures a CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over. can feel like friction to the developer it constrains.

Different jobs, not different polishthe buyer and the user diverge

Enterprise table stakesthe checklist that gates the deal

A lot of enterprise work isn't glamorous product - it's the controls that let a security team say yes. These rarely show up for the individual user, but their absence ends an enterprise conversation before it starts. Know what's actually table stakes versus what's differentiating.

Gating without punishing either sidethe packaging decision

The classic mistake is gating something behind the enterprise tier that the individual experience genuinely needs or cluttering the individual product with controls only admins want. Good packaging puts each capability where it belongs: flow-state features stay ungated and frictionless, governance features live in the admin layer where developers never see them.

When an enterprise need should - and shouldn't - bend the roadmapsequencing under pressure

A large prospect will ask for things. Some of those requests are real signals about the next 50 customers; some are one logo's idiosyncrasy dressed up as a trend. Reading the difference is most of the judgment in this part of the job.

A builder-PM at Cursor doesn't get product signal filtered through three layers. You're in the room with the customer, sometimes driving the demo yourself, sometimes fielding the question sales can't.

The JD has you working directly with customers, sales and field engineering, including high-stakes accounts. The phrase that anchors the whole posture is in the role context: polished but gritty. You can sit in an enterprise sales conversation without losing the credibility of someone who actually builds and uses the product. That credibility is your edge in the room and it's why they want a technical PM there at all.

Discovery that turns into product, not notesyou're there to learn, then to ship

Sales runs discovery to close; you run discovery to find the next thing to build. The two overlap, but your job is to leave with a sharpened understanding of the customer's workflow and where the tool breaks for them - and to come back with a change, not a Notion doc nobody reads.

1. 1Watch the real workflow. Ask them to show you how they actually code today, where the tool helps and where they route around it. Observed behavior beats stated preference.
2. 2Find the breakpoint. Identify the one place the experience fails for this team - a stack, a repo size, a missing control - and get it concrete with an example.
3. 3Separate the symptom from the need. A request for feature X often hides a deeper job; restate the job in your own words and confirm it.
4. 4Close the loop. Tell them what you heard, what you'll do and when. Then actually ship something and come back. That's what turns a customer into a believer.

Brainstorm the funnel with the codebase as ground truththe code is the most honest source

Before you go ask a customer or a data scientist anything, ask the product. When you're reasoning about a funnel - say BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. onboarding and activation - Cursor can describe the status quo exhaustively: every feature-flag nuance, the data states a user can fall into, whether an analytics event is even instrumented the way you assumed and why an inconsistency exists in the numbers. That used to mean pulling an engineer or staring at code for hours. Now it's a near-instant, grounded answer you feed straight into the product decision.

Partner with the field on high-stakes accountsyou amplify them, you don't replace them

Sales owns the deal and the relationship; field engineering owns the technical depth on the ground. You bring product authority and the ability to commit (carefully) to direction. The failure mode is a PM who freelances in front of the customer and undercuts the account team, so coordinate before you walk in.

• Agree on roles before the meeting: who runs it, who handles objections, where you step in.
• Bring what only a PM can - the why behind the product and a credible read on what's coming, without over-promising a roadmap.
• Take the technical questions that stump the account team and be honest when the answer is "not yet, here's the workaround."
• Feed everything back to the field as synthesized signal, so the next account benefits without you in the room.

Run the demo when the stakes are higha tight value story, live, on their world

A high-stakes demo is not a feature tour. It's a story with one protagonist - the customer's own problem - solved in front of them. The most persuasive thing you can do with a developer audience is run Cursor live on a task that looks like their work and let the result speak.

A single wrong autocomplete at the wrong moment teaches a developer not to trust the next one. In a tool used thousands of times a day, the small stuff is the product.

The JD names this directly: kill the 1,000 paper cuts, the small quality issues that erode developer trust. It's listed as a responsibility because at Cursor's stage, the gap between "impressive" and "indispensable" is mostly a long tail of tiny frictions. A flashy new feature wins a headline; fixing the cursor jump that fires on every save wins the daily habit.

Why small bugs hit so hard herefrequency × trust

Trust in a developer tool is asymmetric. A great suggestion is expected; a wrong one that mangles your file is remembered. Because the tool sits in the inner loop of someone's work, the cost of a paper cut isn't one annoyance - it's multiplied by how often the developer hits it and how much it makes them doubt the tool.

Source the paper cutsmake the invisible visible

You can't fix what you can't see and most paper cuts never become a formal ticket - the developer just sighs and works around them. So you go find them across four channels and you treat your own daily usage as a first-class source because you are exactly the user.

Investigate the symptom yourself with an observability MCPyou don't have to wait for an engineer

A paper cut often shows up as a vague symptom: one user's data looks wrong, a state seems impossible. At Cursor the observability stack is Datadog, and the speaker leans on the Datadog MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. heavily - Datadog ships a Cursor/VS Code extension that installs the MCP for you. With it plugged in you hand Cursor a user ID or a wrong-data report and tell it to investigate. It sifts the logs, lines up timestamps, resolves what it finds against the actual code and comes back with a thorough analysis - often more thorough than you'd manage by hand, and a far more ergonomic interface than clicking around the Datadog UI.

Triage by trust impact, not by who's loudestseverity × frequency × trust

The trap is fixing the bug the loudest person filed instead of the one quietly hurting the most users. A simple scoring lens keeps you honest: how bad is it when it hits, how often does it hit and how much does it make people distrust the tool. The third factor is the one most teams forget and it's the one that matters most for a daily-use product.

Drive closure, not ticketsthe hard part is finishing

Filing the paper cut is the easy 20%. The reason these bugs persist is that they're individually small enough to always lose to the next big feature, so they rot in a backlog forever. The PM's real job here is to manufacture the conditions where they actually get fixed.

• Batch them into a recurring quality budget - a standing slice of eng time so paper cuts compete against each other, not against the headline feature.
• Make the long tail visible to leadership as a trust metric, so "polish" has a number behind it instead of being a vibe.
• Drive each one to closed and verified in production, not "merged" - for a daily-use tool, the fix only counts when users stop hitting it.
• Celebrate the closes the way launches get celebrated, so the team feels the quality work is valued, not invisible.

Own the small fixes yourselfPMs and designers push the P2s and P3s

The most reliable way to make sure paper cuts get fixed is to stop waiting for someone else to fix them. At Cursor, PMs and product designers own a lot of the frontend and UX and iterate on it very autonomously - they push code for the small things the team is never going to get to, the P2s, the P3s, the one-line UI tweaks. It's not a fantasy reserved for engineers. With a dev environment set up, it's a very doable place to get to.

There's also no blank-page tax on the way in. Because you start from the ticket or PRDProduct Requirements Document. The spec describing what to build and why. and point Cursor at it to define a plan - and often the PR itself - you're rarely cold-starting. You pick up work from an agent's investigation or a near-complete draft and take it from there.

The setup that makes this safe is a short loop: background agents pick up the small Linear tickets, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. reviews their output, and you test it in a local dev environment before it ships. That review gate is what lets a non-engineer push code without lowering the quality bar. The payoff is less deliberation - anyone with an opinion can just make the change and judge it in the running product instead of arguing about it in a meeting.