Product, ICP & Competitive Fluency
Know Cursor the way an engineer would - and the market around it
What Cursor actually is
After this you can explain Cursor's product to both an engineer and a non-technical buyer.
The fastest way to fail a Cursor SDR interview is to pitch the product to someone who builds it. Your job in the room is to prove you have actually used Cursor, can describe it in plain language and can translate it into something an engineering team feels on a Tuesday afternoon.
Cursor is an AI-native code editor built by Anysphere on the VS Code foundation. It keeps the editor developers already know, the file tree, terminal, extensions, keybindings and rebuilds the writing loop around AI that can see the whole codebase. The stated mission is to automate coding, which is the line the founder cares about and the line you should be able to say like you mean it.
You are not being hired to write production code. You are being hired to name what each surface does, why a working engineer reaches for it and where the value lands in a buyer's budget.
The four surfaces to know by namecore product
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Four capabilities resting on one foundation - name them, then say what an engineer feels.
Predictive multi-line completion that suggests the next edit, not just the next token.
This is the surface developers fall for first. It feels like the editor is reading their mind.
Give it a task in plain language and it plans, edits across files, runs commands and iterates.
The editor doing work rather than only suggesting the next line.
Select code, describe the change, get a targeted diff in place.
The everyday move for quick refactors without leaving the file.
Answers and edits grounded in the actual repo, your conventions and imports, not a generic guess.
Where a new hire ramps on an unfamiliar codebase in hours instead of weeks.
Two pitches for two rooms
The interviewer may ask you to explain Cursor to an engineer, then to a CFO. Have both ready and switch cleanly.
- To an engineer
- An editor that sees your whole repo, autocompletes whole edits and runs an agent that can change code across files and check its own work.
- To a non-technical buyer
- Software that helps your engineers ship faster and onboard new hires quicker, so the same team gets more done.
- The bridge
- Speed and consistency for ICs becomes velocity and retention for the org. That is the line both rooms accept.
Pick the register before the first sentence; do not start technical with a CFO.
You have to actually use it
Cursor's screens probe genuine usage, not memorized talking points. The CEO has said publicly that candidates who view this as just a job won't pass. Install it, build or modify something real and form an opinion.
“I rebuilt a side project's API layer in Cursor last month. Tab was fine, but the moment it clicked was the agent refactoring three files at once and running the tests itself. I stopped context-switching to a browser. That is the thing I'd want a skeptical engineer to feel in their first ten minutes.”
A vague story is worse than a short one. “It's really powerful and saves time” reads as the marketing page. Name a specific thing you built, one moment that surprised you and one place it did not help. The honest limitation is what makes the rest believable.
Takeaway. Name the four surfaces (Tab, agent, inline edit, codebase context), carry a one-line pitch for an engineer and one for a non-technical buyer and back it with a specific personal usage story.
Self-check
QIn a screen, the recruiter asks: "What's your own experience with Cursor?" What's the strongest way to answer?
ICP, personas and use cases
After this you can target the right teams and tailor value by persona.
Pipeline starts with picking the right accounts and the right people inside them. A Cursor SDR who can't describe the ICP and tailor a message by persona is just dialing at random.
The core profile is startup and mid-market engineering organizations that ship code daily. These teams feel developer-productivity pain directly and can adopt a tool without a year of procurement. Enterprise exists, but the heat is in teams moving fast enough to care about speed today.
Three personas, three value storiestailor or get ignored
- Persona
- IC engineer
- What they care about
- Flow, speed, fewer context switches, a tool that doesn't get in the way
- Your angle
- Personal productivity; the editing loop they'll feel in ten minutes
- Persona
- Eng manager / team lead
- What they care about
- Team velocity, consistent practices, smoother onboarding
- Your angle
- Whole-team output and faster ramp for new hires
- Persona
- VP Eng / CTO
- What they care about
- Standardization, security, ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. across the org
- Your angle
- One paid, governed standard instead of scattered individual tools
| Persona | What they care about | Your angle |
|---|---|---|
| IC engineer | Flow, speed, fewer context switches, a tool that doesn't get in the way | Personal productivity; the editing loop they'll feel in ten minutes |
| Eng manager / team lead | Team velocity, consistent practices, smoother onboarding | Whole-team output and faster ramp for new hires |
| VP Eng / CTO | Standardization, security, ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. across the org | One paid, governed standard instead of scattered individual tools |
The same product; the value you lead with changes by altitude.
Triggers worth prospecting on
A good outbound reason beats a generic intro every time. Watch for events that make the pain acute.
New eng hires posted or recent funding to fund them.
More people to onboard means onboarding speed becomes a budget line.
Leadership publicly pushing AI across the org.
Someone now owns "get our engineers on AI tools" and needs a standard.
Fast-growing team, large or unfamiliar codebase.
Codebase context is the ramp-time story for exactly this.
Renewal coming up on Copilot or a contract under review.
A timing window where switching is already on the table.
The wedge: bottom-up usage you can find
Many teams already have engineers using Cursor individually before you ever call. That is the wedge, not a problem. The motion is to find that organic usage and pitch making it the team standard.
- 1Find the love. Look for individuals at the account already on Cursor, public mentions or champions who'll say it's spreading.
- 2Quantify it. "Several of your engineers already use this" is a far stronger opener than a cold feature pitch.
- 3Name the gap. Individual usage has no admin, no shared billing, no security review. That gap is the team-plan conversation.
- 4Hand the AE a reason. The meeting you book is "standardize what your team already chose," which an AE can run with.
Engineers adopting Cursor on their own is the start, not the finish. Turning that into a company deal means clearing concerns the IC never thinks about: data privacy and security, admin controls, central billing and a budget owner. Knowing these gates exist and who owns each, is what separates an SDR who books real meetings from one who books enthusiastic dead ends.
Takeaway. Lead value by altitude (IC = flow, manager = velocity, VP/CTO = standardization, security, ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in.), prospect on real triggers and use existing bottom-up usage as the wedge to a team standard.
Self-check
The competitive landscape
After this you can position Cursor honestly against the main alternatives.
Engineers know this market. Bluffing a competitor comparison is how you lose a technical room. Your edge is honesty and curiosity, paired with one or two differentiators you can actually defend.
You'll meet three alternatives over and over. Know them well enough to discuss, not to trash.
- Alternative
- GitHub Copilot
- What it is
- The incumbent AI assistant, deeply tied to the GitHub and VS Code world
- Honest framing
- Strong autocomplete; Cursor's bet is the editor and agent built around AI from the ground up, not a pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance.
- Alternative
- Windsurf
- What it is
- Another AI-native editor competing on the same ground
- Honest framing
- Real competitor; differentiate on product feel and let the engineer try both rather than claim a winner
- Alternative
- Raw ChatGPT / "we built our own"
- What it is
- Copy-pasting into a chatbot or homegrown scripts
- Honest framing
- Works for snippets; falls down on whole-codebase context and the in-editor loop
| Alternative | What it is | Honest framing |
|---|---|---|
| GitHub Copilot | The incumbent AI assistant, deeply tied to the GitHub and VS Code world | Strong autocomplete; Cursor's bet is the editor and agent built around AI from the ground up, not a pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. |
| Windsurf | Another AI-native editor competing on the same ground | Real competitor; differentiate on product feel and let the engineer try both rather than claim a winner |
| Raw ChatGPT / "we built our own" | Copy-pasting into a chatbot or homegrown scripts | Works for snippets; falls down on whole-codebase context and the in-editor loop |
Frame strengths without overclaiming. The market moves monthly.
"We already use Copilot" is an opener, not a wall
When a prospect names a competitor, that is information, not rejection. The worst move is to argue. The best is to get curious about what's working and where it isn't.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Same line, two reactions - one closes the door, one opens discovery.
- 1Acknowledge. "Makes sense, Copilot's a solid tool and a lot of teams start there."
- 2Ask. "What's it doing well for your team and where does it leave you wanting more?"
- 3Advance. Map a real gap they name to a Cursor surface, then ask for the meeting where an AE can go deeper.
“Totally fair, plenty of teams run Copilot. I'm curious what it's nailing for you and where it falls short, because the thing folks usually feel switching to Cursor is the whole-codebase context and the agent doing multi-file work. Worth twenty minutes with one of our AEs to see if that gap is real for your team?”
Differentiators you can actually defend
The editor and agent are designed around AI, rather than AI added to an existing editor as a pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance..
Defensible because it's an architecture claim, not a benchmark you'll be asked to prove on the spot.
Reasons over the whole repo, your conventions and types, not just a pasted snippet.
This is the trust differentiator engineers feel directly.
Don't get pulled into model benchmarks or a feature-by-feature war you can't win live. Models change monthly and an engineer may know more than you. If they push on specifics, say you'd bring an AE or sales engineer for the deep comparison and pivot to the editing loop and context, which the buyer can feel. Confident honesty beats a bluffed spec sheet.
Takeaway. Know Copilot, Windsurf and raw-ChatGPT well enough to discuss honestly; treat "we already use X" with Acknowledge–Ask–Advance; defend AI-native architecture and codebase context and never bluff a benchmark.
Self-check
QA prospect says "We already use Copilot and we're happy with it." What's the best next move?
The buying conversation for a dev tool
After this you can connect product knowledge to a real sales motion.
Knowing the product isn't enough. You have to see how it turns into revenue, so you know which signals justify an AE conversation and which don't.
Cursor sells along an expansion path and your outbound feeds the early part of it.
- 1Free / individual. Engineers adopt Cursor on their own; no contract, no admin, no budget owner.
- 2Team plan. A group standardizes, gets shared billing and basic admin; this is the conversion you most often feed.
- 3Enterprise. Org-wide rollout with security review, SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool., central admin and procurement; the AE and a sales engineer own this.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Your outbound moves a prospect from organic usage into a meeting - the gate is where it stops being yours.
The value drivers a buyer signs off onwhat gets budget
- Developer productivity
- Engineers ship more in the same hours; the headline value and the easiest to feel.
- Faster onboarding
- New hires ramp on the codebase in hours instead of weeks via codebase context.
- Retention and satisfaction
- Engineers want modern tools; good tooling is a real reason people stay.
Lead with productivity, but onboarding is the cleanest ROI story to quantify.
Light ROI framing, never fabricated
You don't price or close, but you can frame value directionally to justify a meeting. The shape is simple: time saved per engineer against seat cost.
If a tool saves ~2 hrs/week per engineer and a team has 30 engineers -> ~60 engineer-hours/week recovered Weigh that against per-seat cost. Use this to justify the AE conversation, not to quote a final price.
Never invent a specific ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. number to a technical buyer. "This saves 40% of dev time" with no source gets you laughed out of the room. Use the buyer's own figures, keep it directional and say plainly that the AE will build the real business case. Honesty about what you can and can't claim is itself the credibility.
Gatekeepers at the enterprise tier
When IC love tries to become a company deal, these concerns decide it. You don't resolve them; you know they exist and who owns them so you can flag them in a clean handoff.
- Gate
- Privacy / security
- The concern
- Where does our code go; is it used to train models
- Who owns it
- Security / CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over.
- Gate
- Admin & access
- The concern
- SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool., provisioning, central management of seats
- Who owns it
- IT / Eng leadership
- Gate
- Billing & procurement
- The concern
- One contract, budget approval, vendor review
- Who owns it
- Procurement / Finance
| Gate | The concern | Who owns it |
|---|---|---|
| Privacy / security | Where does our code go; is it used to train models | Security / CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over. |
| Admin & access | SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool., provisioning, central management of seats | IT / Eng leadership |
| Billing & procurement | One contract, budget approval, vendor review | Procurement / Finance |
Surface these as facts in your handoff notes; the AE drives the resolution.
If asked "what's your job at the end of a good cold call?", be precise: surface enough fit to justify an AE conversation, not to price or close. Then show you know the next gates. That answer proves handoff discipline, which is exactly what the AE round is testing.
Takeaway. Map free → team → enterprise as the path you feed, sell productivity and faster onboarding, frame ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. directionally with the buyer's numbers and know the security/admin/billing gates exist without trying to solve them.
Self-check
Curiosity about how software gets built
After this you can hold a credible conversation with engineers about their workflow.
Genuine curiosity about how engineers work is the JD's explicit ask and it's your differentiator against every other SDR who only knows the pitch. You don't need to code. You need to ask good questions and understand the answers.
Learn the shape of an engineer's day well enough to know where an AI tool plugs in.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
An engineer-led company hiring its first SDRs weights these traits over pitch polish.
- IDE / editor - where code is written; this is the surface Cursor replaces.
- Code review / pull requests - how changes get checked before merging.
- CI/CDContinuous Integration / Continuous Delivery. The automated pipeline that builds, tests and ships code so changes reach production safely and often. - the automated pipeline that tests and ships code.
- The codebase itself - the repo a new hire has to learn before they're useful.
Enough vocabulary to ask, not to pretendthe line that matters
The goal is fluent questions, not fake expertise. Pretending to be an engineer fails fast; an honest, curious non-engineer who asks sharp questions earns respect.
"What's your stack and roughly how big is the team?"
"Where does onboarding a new engineer slow down today?"
"Which AI tools, if any, is the team already using?"
Don't fake depth on a framework you don't know.
Don't argue architecture with a staff engineer.
If you're out of your depth, say so and bring an AE.
Stay current to stay credible
The AI-coding conversation moves weekly. Following it is how you keep credibility with a buyer who lives in it.
Most SDRs selling to engineers sound like they're reading a script and engineers can smell it in one sentence. Your advantage is technical empathy: you actually use the product, you're genuinely curious how their team works and you don't pretend to know things you don't. That posture is rare in outbound and it's exactly what a bottom-up, engineer-led company like Cursor screens for.
Bring one genuine question about how software gets built that you're actually curious about and ask it in the loop. Curiosity you can't fake is the trait Cursor is hiring for here and showing it live beats any rehearsed line about being "passionate about AI."
Takeaway. Learn the engineer's workflow (IDE, code review, CI/CDContinuous Integration / Continuous Delivery. The automated pipeline that builds, tests and ships code so changes reach production safely and often., the codebase) well enough to ask sharp questions, never fake expertise, stay current on AI coding and lean on technical empathy as your edge over every other SDR.