Launches & Go-To-Market Execution

At Cursor there is no launch team standing behind you to take the feature once eng finishes it. The PMM who owns the GTM is the one who validates it lands, writes the story, picks the channels and reads the first day of numbers.

The job description is explicit: you own go-to-market end-to-end for features and major releases, including pre-launch product-market-fit validation with product and eng. That phrase rules out the brief-passing version of the role. You don't hand a feature to a downstream function and move on. You drive the whole arc and you're accountable for whether the launch actually moved developers, not just whether it shipped.

A launch for a developer tool is a change to a workflow people already trust every morning. So the lifecycle starts well before any announcement and doesn't end when the blog post goes live.

The phases you runone continuous loop, not a relay

1. 1Validate. With product and eng, confirm the feature solves a real job before you build a narrative around it. Dogfood it, watch a few developers use it raw and find the one use case where it obviously wins.
2. 2Position. Pin down who it's for, what it replaces and why it's different from Copilot or Windsurf. Positioning is the input to every asset, so it comes before you write a word of copy.
3. 3Build assets. Write the blog post, landing page, demo and video yourself. These are the deliverables the JD names and at Cursor a PMM ships them directly.
4. 4Sequence channels. Decide the order and timing across X, GitHub, YouTube, Hacker News, the changelog and docs. A launch is a sequence, not a single drop.
5. 5Launch. Hit the moment with everything aligned to one story, coordinated with DevRel and community so it reads as authentic.
6. 6Measure. Read the scorecard against targets you set before launch - reach, activation, conversion, not just impressions.
7. 7Iterate. Feed what you learned back into positioning and the next launch. The loop the JD calls for closes here.

Launch tiers - scale effort to stakesnot every ship is a moment

Treating every change as a tentpole burns the audience and the team. Treating a major release as a changelog line wastes the moment. A tiered system lets you spend effort where it pays off and ship the rest fast.

Cursor's PMM is a builder-writer. You don't brief an agency on the landing page - you open the doc and write it, then you record the demo and cut the video. The JD names these four deliverables by hand.

Before any of them, you write the narrative. One sharp story that every asset serves. A feature dump is what you get when there's no narrative: a list of capabilities a developer skims and forgets. A narrative gives the reader a single reason to care and a single thing to remember.

The four assets you ownnamed explicitly in the JD

Anchor everything to one narrativestory first, assets second

Write the one-sentence story before you write anything else. If the blog, the landing page, the demo and the video each tell a slightly different story, the launch reads as noise. When they all serve the same spine, the repetition compounds across channels into something a developer remembers.

Developers don't live on the channels most B2B marketing optimizes for. They live on X, in GitHub, on YouTube, on Hacker News, in subreddits and in the changelog they actually read. Reach them where they already are, in the register they already trust.

The JD asks you to test and improve distribution channels to reach developers and run experiments. So distribution isn't a fixed playbook you inherit. It's a set of bets you place, measure and adjust until you find what actually moves this audience for this kind of launch.

The developer channel mapwhat each one is good for

Sequence the launchteaser to sustained proof

A launch is a sequence with a shape, not a single drop. You build a little anticipation, hit the moment hard with everything aligned, then keep proving the claim for the weeks after when most of the actual adoption happens.

1. 1Teaser. A glimpse that builds anticipation without spoiling the moment - a cryptic clip, a "shipping this week," a beta crack in the door.
2. 2Launch moment. Everything lands together - blog, landing page, video, X thread, HN post, changelog - all telling the one story on the same day.
3. 3Sustained proof. The weeks after: use cases, comparisons, community workflows, follow-up clips. This is where adoption compounds and the claim gets proven in public.
4. 4Read and reallocate. Watch which channel and format actually reached developers, then double down on the winners and cut the dead weight for next time.

Run it as experimentsbets, not broadcasts

Each channel is a test: a message, a format, a time. You're not proving you can post everywhere. You're learning which combination actually drives activated developers, then concentrating effort there.

Cursor grew bottoms-up: developers adopted it without a salesperson in the room. As it pushes into enterprise, a sales motion appears on top of that - and PMM is the bridge that turns product capability into something a GTM team can actually sell.

The JD says it directly: translate capabilities into messaging that sales and GTM teams can use effectively. That's not the same as your launch narrative. A blog post persuades a developer reading alone; enablement arms a human having a live conversation with a skeptical buyer who's also evaluating Copilot.

The core enablement kitwhat GTM actually needs in hand

Serve both motionsself-serve and sales-led at once

Close the loop with the fieldmessaging is a hypothesis until the field tests it

The first version of a battlecard is a guess. The field tells you which lines actually land in a deal and which objections you didn't anticipate. Sit in on calls, read win/loss and revise - your enablement gets sharper with every deal it survives.

• Join real sales calls so you hear objections in the wild, not as you imagined them.
• Run win/loss reviews and trace losses back to a messaging or positioning gap you can fix.
• Track which battlecard lines reps actually use and quietly retire the ones they don't.
• Feed recurring objections back to product - sometimes the fix is a feature, not a talking point.

A launch that gets a developer to install Cursor and then loses them in week one was a failure with good press. GTM doesn't end at the click - it follows the developer into the product until they're getting real value.

The JD asks you to improve activation, onboarding and retention messaging and run conversion experiments. That puts the funnel inside PMM's scope, not just the announcement. The copy a developer reads after they sign up is as much your surface area as the landing page that got them there.

Message toward the activation momentthe first time it clicks

Activation isn't "signed up." It's the first moment the product proves itself - and for Cursor that's a specific, observable event. Find it, then orient onboarding to get the developer there as fast as possible.

Onboarding copy is PMM surface areanot just lifecycle's job

The empty state, the first-run tooltip, the nudge that says "try Agent on this file" - that copy decides whether a developer reaches the activation moment or bounces. Treat it as launch-quality writing, because it carries the narrative into the exact instant a developer decides if Cursor is for them.

• Write the onboarding flow toward the activation moment, not a tour of every feature.
• Keep in-product copy concrete and short - a developer in flow won't read a paragraph.
• Carry the launch narrative inward so the promise that got them here matches what they meet.
• Reduce time-to-value: every step between sign-up and the first win is a place to lose them.

Run conversion experiments properlyhypothesis, metric, iterate

1. 1State a hypothesis. "Surfacing Agent on the first opened file will raise first-week activation" - specific and falsifiable.
2. 2Pick one metric. The activation or conversion rate you're trying to move, decided before you ship the change.
3. 3Change one thing. Isolate the variable so the result is attributable, not a guess about which of five changes worked.
4. 4Read and iterate. Keep what moved the metric, kill what didn't and write down the learning for the next experiment.

If you can't say what a successful launch looks like before you ship it, you'll declare victory on whatever number happened to be big. A scorecard set in advance is what separates a measured launch from a press release.

PMM success at Cursor isn't impressions. It's developers who activated, converted and stuck - plus, for the enterprise side, pipeline the launch influenced. A balanced scorecard forces you to look past the metric that's easiest to inflate at the ones that actually mean the launch worked.

A balanced launch scorecardset targets before launch

Separate vanity from outcomethe number that's easy to inflate vs. the one that matters

Run the post-mortem and close the loopthe launch isn't done until you've learned from it

1. 1Grade against pre-set targets. Compare actuals to the numbers you committed to before launch - no moving the goalposts after the fact.
2. 2Diagnose the gaps. A high-reach, low-activation launch points at onboarding; high activation, low reach points at distribution. The shape of the miss tells you where to fix.
3. 3Write the learnings down. Specific, reusable conclusions about message, channel and timing - not "it went well."
4. 4Feed it forward. Push the learnings into positioning and the next launch. This is the iteration loop the JD explicitly calls for.