Skip to lesson
Exit
Positioning & Messaging for a Developer ICP1 / 2

2 min lesson

Knowing the developer ICP

Use "Knowing the developer ICP" to tell the cases apart, then choose a response for each one.

Step 1 of 2

“Developers” is not an ICP. A solo engineer trying Cursor on a side project and a VP of Engineering rolling it out to 800 people share a tool and almost nothing else about how they decide.

Cursor's motion runs bottom-up and then pushes into the enterprise, so the PMM serves two people in the same account: the IC who adopts because the product is good and the buyer who needs a reason the org should standardize and pay. Their proof requirements diverge sharply.

Individual developer

Adopts in minutes, judges in the first session, churns silently.

Cares about: does it save me time today, does it feel fast, does it respect my flow.

Proof: the product itself, a credible demo, a workflow they recognize.

Engineering team / lead

Champions a tool the team already likes; needs to justify spend and consistency.

Cares about: team throughput, onboarding speed, fitting existing workflows.

Proof: usage data, case studies from similar teams, an honest comparison.

Enterprise eng org

Buyer is removed from daily use; many stakeholders, real risk tolerance.

Cares about: security, privacy, lock-in, governance, ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. Press Enter for the full definition. at scale.

Proof: security posture, admin controls, references, predictable rollout.

Across all three, one rule holds: developers buy on credibility and time saved, not on adjectives. Anchor every claim in a job-to-be-done and a workflow the reader recognizes from their own week.

Say it like this

“Instead of re-explaining your repo to a chat window every time, Agent reads the relevant files, proposes a diff across them and you review it like a pull request.” That sentence names the job, the mechanism and the moment of relief - no superlatives required.

Learn more

Advanced table

Map the objection per segment

Map the objection per segmentthe same product, different fears

Objection
“The AI gets it wrong / I can't trust the output”
Who raises it
ICs and leads
Honest counter to have ready
It's a reviewable diff, not blind apply; you stay in the loop and accept changes deliberately
Objection
“What happens to our code and privacy?”
Who raises it
Enterprise buyers
Honest counter to have ready
Point to the actual data handling and privacy controls; never hand-wave this one
Objection
“We'll get locked in”
Who raises it
Leads and buyers
Honest counter to have ready
It's an editor over standard files and git; the switching cost is the workflow value, not a cage
Objection
“I can already do this with my current setup”
Who raises it
Experienced ICs
Honest counter to have ready
Acknowledge it works, then show the specific friction Cursor removes in a multi-file change

Objection handling is positioning under pressure - pre-write the honest answer for each segment.

The “I can already do this” objection is the one to respect most. The engineer is often right that their setup works. Winning means showing a concrete task where the friction is real, not arguing they're wrong.

Interview move

If the panel asks how you'd market Cursor to developers, refuse the monolith. “There isn't one developer audience - I'd separate the IC who validates the product in one session from the enterprise buyer who needs security and ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. Press Enter for the full definition. and write different proof for each.” That distinction is the whole job in one sentence.

Learn more

Optional practice

Practice: Knowing the developer ICP

QAn experienced engineer says, “I can already do all this with my editor and a chatbot.” What's the strongest PMM response?