Discovery & Deal Execution
Run high-velocity, multi-threaded commercial cycles
Discovery that quantifies pain
After this you can run discovery that uncovers and sizes business pain, not features.
At Cursor the buyer is often a room full of engineers who already use the product and a CTO who wants to know what it costs. Bad discovery demos features into that room. Good discovery finds the bottleneck in how their team ships code, then puts a number on it.
Cursor's motion is usually bottom-up. Devs adopted it on their own, so the pain isn't "we have no AI tooling" - it's something further upstream that the engineering leader feels in their roadmap. Your job on the first call is to get past "the team likes it" and reach "here is the cost we carry every week, in hours."
A founder-led loop screens hard for whether you actually understand engineering work. An AE who opens with a Tab-completion demo reads as a vendor. The one who asks "where does a typical change wait the longest before it ships?" reads as someone who could sell to a skeptical staff engineer. Discovery is the round where that distinction shows.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Each step is a gate: skip one and the deal you forecast isn't real yet.
Open with curiosity about the workflowdiscovery toolkit
Lead with open questions about how the team actually builds and ships. Vague answers hide the constraint, so you trade abstractions for last-week examples and numbers.
- What you ask
- Walk me through the last feature you shipped - where did it sit and wait?
- What it really probes
- Locates the real queue: review, testing, context-switching. Time spent waiting is the bottleneck.
- What you ask
- How much of an engineer's week goes to net-new code versus glue, tests and boilerplate?
- What it really probes
- Surfaces the toil Cursor's Agent and Tab actually remove, in hours you can later price.
- What you ask
- How are devs already using Cursor today and which teams haven't tried it?
- What it really probes
- Converts organic love into a named expansion path and a baseline to measure against.
- What you ask
- If onboarding a new hire took half as long, what would that be worth to you?
- What it really probes
- Turns "faster" into a number the engineering leader will own and defend internally.
- What you ask
- What happens to the roadmap if velocity stays flat for two more quarters?
- What it really probes
- Tests whether this is a funded problem or a nice-to-have you shouldn't forecast.
| What you ask | What it really probes |
|---|---|
| Walk me through the last feature you shipped - where did it sit and wait? | Locates the real queue: review, testing, context-switching. Time spent waiting is the bottleneck. |
| How much of an engineer's week goes to net-new code versus glue, tests and boilerplate? | Surfaces the toil Cursor's Agent and Tab actually remove, in hours you can later price. |
| How are devs already using Cursor today and which teams haven't tried it? | Converts organic love into a named expansion path and a baseline to measure against. |
| If onboarding a new hire took half as long, what would that be worth to you? | Turns "faster" into a number the engineering leader will own and defend internally. |
| What happens to the roadmap if velocity stays flat for two more quarters? | Tests whether this is a funded problem or a nice-to-have you shouldn't forecast. |
Each question trades a comfortable abstraction for a concrete fact you can build a business case on.
Turn "we're slow" into a number
"We're slow" is not a deal. The same sentence, quantified, is a business case the champion can carry to finance. Pick a metric the team already tracks and anchor the conversation there.
- 1Find the unit. Hours per engineer per week on toil, PR cycle time, ramp time for new hires or PRs merged per sprint - use whatever they already measure.
- 2Get a current baseline. "Roughly how many hours a week does a dev lose to boilerplate and context-gathering?" Make them say a number out loud.
- 3Size the team. Multiply by the headcount in scope. Forty engineers times three reclaimed hours a week is a number worth a procurement cycle.
- 4Translate to money or roadmap. Convert to fully-loaded cost or to features shipped. Leaders fund headcount-equivalent savings and faster roadmaps, not abstract productivity.
"So if I'm hearing you right: forty engineers, each losing about three hours a week to boilerplate and hunting through the codebase. That's roughly 120 hours a week - three full engineers' worth of capacity - going to work the tool already does. Is that the number we should be trying to move?"
Find the compelling event and the timeline
A deal without a reason to act now drifts. Early in discovery, surface what makes this quarter different and when a decision has to land.
- Compelling events for an eng org: a hiring freeze forcing more output per head, a big launch with a hard date, a budget cycle closing or a competing tool's renewal coming due.
- Ask the timeline directly: "If the evaluation goes well, when would you want the team fully onboarded?" Work backward from that date.
- No compelling event means the deal is real but slow. Forecast it honestly as later-stage pipeline, not this quarter's commit.
Map the org while you're in there
Discovery is also reconnaissance. By the end of the first real call you should know who feels the pain, who pays and who can quietly kill the deal in a Slack thread you'll never see.
- Champion
- The dev or EM who loves Cursor and will sell internally when you're not there
- Economic buyer
- Who actually controls the budget - often a VP Eng or CTO, not your champion
- Blockers
- Security and Legal reviewers who can stall on data/IP handling for weeks
- Procurement path
- Whether this goes through a vendor review and how long that usually takes
- Decision criteria
- What they'd have to see in an eval to say yes - write it in their words
An org you haven't mapped is a deal you can't forecast.
Never end a discovery call without a concrete next step on the calendar. "I'll follow up" is how velocity dies. Book the eval kickoff, the security intro or the exec readout before you hang up - discovery without a scheduled next step is a wasted call.
Takeaway. Discovery's job is to convert "we're slow" into hours times headcount times cost, find the compelling event and leave with a scheduled next step. A call without a quantified pain and a calendar invite was a chat, not discovery.
Self-check
QWhich is the strongest discovery question for sizing developer-productivity pain?
Qualification frameworks applied
After this you can use a qualification framework to grade and progress deals.
A sales leader interview will hand you a deal and watch how you reason about it. The candidates who say "strong champion, good vibes" lose to the ones who can name exactly what they know, what they don't and what that missing piece means for the forecast.
A qualification framework is the discipline that turns gut feel into a defensible forecast. The point isn't to recite an acronym. It's to use the letters as a checklist for risk: each gap is a reason a deal might slip or die and naming the gap is how you decide where to spend the week.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Not every MEDDICC letter carries the same risk - these are the gaps that move the forecast most.
MEDDICC, decodedthe workhorse framework
MEDDICC is the standard for complex, multi-stakeholder cycles - exactly the mid-market motion at Cursor. MEDDPICC adds the Paper process, which matters once Procurement and Legal enter the room.
- Letter
- M - Metrics
- What it is
- The quantified value the buyer expects
- What it looks like in a Cursor deal
- "Reclaim 3 hrs/dev/week across 40 engineers" - the number from discovery
- Letter
- E - Economic buyer
- What it is
- The person who controls the budget
- What it looks like in a Cursor deal
- VP Eng or CTO who signs, often not the dev who championed adoption
- Letter
- D - Decision criteria
- What it is
- What they'll judge the purchase on
- What it looks like in a Cursor deal
- Security posture, eval results, per-seat ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in., fit with existing stack
- Letter
- D - Decision process
- What it is
- The actual steps to a signature
- What it looks like in a Cursor deal
- Eval, security review, procurement, legal redlines, exec sign-off
- Letter
- I - Identify pain
- What it is
- The compelling, quantified problem
- What it looks like in a Cursor deal
- Velocity flat into a launch; toil eating real headcount
- Letter
- C - Champion
- What it is
- The insider who sells for you
- What it looks like in a Cursor deal
- The staff eng or EM who'll defend the line item in the budget meeting
- Letter
- C - Competition
- What it is
- Alternatives, including doing nothing
- What it looks like in a Cursor deal
- Copilot incumbency, Windsurf or "just keep the free tier"
| Letter | What it is | What it looks like in a Cursor deal |
|---|---|---|
| M - Metrics | The quantified value the buyer expects | "Reclaim 3 hrs/dev/week across 40 engineers" - the number from discovery |
| E - Economic buyer | The person who controls the budget | VP Eng or CTO who signs, often not the dev who championed adoption |
| D - Decision criteria | What they'll judge the purchase on | Security posture, eval results, per-seat ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in., fit with existing stack |
| D - Decision process | The actual steps to a signature | Eval, security review, procurement, legal redlines, exec sign-off |
| I - Identify pain | The compelling, quantified problem | Velocity flat into a launch; toil eating real headcount |
| C - Champion | The insider who sells for you | The staff eng or EM who'll defend the line item in the budget meeting |
| C - Competition | Alternatives, including doing nothing | Copilot incumbency, Windsurf or "just keep the free tier" |
MEDDPICC inserts P - Paper process - between Champion and Competition: NDAs, MSAs, security questionnaires and DPAs.
SPICED as an alternative
SPICED is a discovery-to-close framework built around the customer's situation rather than your internal checklist. Either works. Pick one and use it on every deal so your forecast is comparable across the book.
- S - Situation
- Their current state: stack, team size, how they ship today
- P - Pain
- The quantified bottleneck and its business cost
- I - Impact
- What changes for them if the pain is solved, in their metrics
- C - Critical event
- The deadline forcing a decision now
- D - Decision
- Who decides, how and against what criteria
MEDDICC grades deal health; SPICED structures the conversation. Many AEs run SPICED on calls and score MEDDICC in the CRM.
Use it to find the deal that isn't real
The highest-value use of a framework is killing your own pipeline early. Two gaps are fatal: no economic buyer (you've never met who controls the budget) and no champion (no one who'll fight for the line item when you're not in the room). Either one means downgrade the stage and fix the gap before you forecast - naming it saves you a quarter of wasted hope.
When the hiring manager asks you to walk through a deal, narrate it through the framework without saying "M-E-D-D-I-C-C." Say: "My champion is the platform lead, but my economic buyer is the VP Eng I've met once. My metric is locked, my biggest risk is the security review I haven't started and my real competition is the free tier. So this week I'm de-risking the security path and getting back in front of the VP." That answer shows judgment, forecast accuracy and a plan - the three things the round tests.
Takeaway. A framework isn't an acronym to recite - it's a risk checklist. No economic buyer and no champion both mean the deal isn't real and naming the gap is how you forecast honestly and decide where to spend the week.
Self-check
QWhat does the extra P in MEDDPICC add that plain MEDDICC leaves implicit?
Multi-threading and champion-building
After this you can build and protect access across all deal stakeholders.
Single-threaded deals die when one person goes on leave, changes jobs or stops returning your emails. At Cursor the entry point is often a single enthusiastic dev, which is the most fragile thread of all. Your job is to turn that one relationship into a web that holds when any single strand snaps.
There's a real difference between a fan and a champion. A fan likes the product. A champion has internal credibility, wants you to win and will spend their own political capital to make it happen. The first call's enthusiast is rarely the second thing yet.
Turn a dev fan into an internal sellerchampion-building
- 1Confirm they have influence. A junior dev who loves Cursor is a great signal, not a champion. Ask who they'd take a budget request to and whether that person listens to them.
- 2Give them the win. Tie the deal to something they care about - looking sharp in front of their VP, finally fixing the velocity problem they complain about.
- 3Arm them for the room you're not in. Hand them a one-page business case with the quantified ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. so they can make the argument without you.
- 4Test the champion. Ask them to set up the intro to the economic buyer. A real champion does it; a fan goes quiet and now you know.
"You've clearly got the team bought in. To get this funded, your VP is going to ask what it returns. I'll put together a one-pager with the hours we'd reclaim and the dollar value - would you be willing to walk them through it and could you introduce me so I can handle the harder questions?"
Multi-thread in parallel, not in sequence
A Cursor mid-market deal touches Engineering, Product, Security, Procurement and Legal. Run those threads at the same time. Sequencing them is how a two-month deal becomes a six-month deal.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Every layer has to hold for the deal to close - and you open all of them in week one, not in sequence.
Security and Legal are not late-stage formalities for an AI coding tool - they're where deals stall. Engineers worry about their proprietary code leaving the building and Legal will scrutinize data-handling terms hard. Surfacing "how does Cursor handle our code and data?" yourself in week one, with a real answer, beats getting ambushed by it in week eight.
Answer the RFP with Cursor itselfAsk mode for security questions
A long security questionnaire or RFP often arrives mid-deal and it's the thing that quietly eats a week of your timeline. You can turn it on the product. Point Cursor at your own connected codebase or docs in Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. and have it draft the answers, then you verify and send. Ask mode is the safe surface for this: it can read and reason, but it can't change anything.
Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. reads and reasons against the codebase you point it at, but it can't write, generate or run anything - so it's safe to hand a security questionnaire or an architecture question to. Every user has both Ask and Agent; there's no admin toggle that locks someone into Ask-only, so the discipline is yours. The normal commit/merge gate still applies, and you can simply not commit anything the agent writes.
The same trick onboards you onto a stack you don't know. Before a bespoke demo into an unfamiliar architecture - or a legacy shop running something like COBOL - ask Cursor to walk you through how that codebase or pattern actually works so you can speak to it with a straight face in front of any audience, in any industry.
Hold the threads together with a mutual action plan
A mutual action plan is a shared document with every step from today to signature, each with an owner and a date. It keeps five stakeholders moving toward one date and makes slippage visible the moment it happens.
- Milestone
- Eval kickoff with platform team
- Owner
- Champion + AE
- Target date
- Week 1
- Milestone
- Security questionnaire submitted
- Owner
- AE → Security
- Target date
- Week 1
- Milestone
- Mid-eval check-in + usage review
- Owner
- AE + champion
- Target date
- Week 3
- Milestone
- ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. readout to VP Eng (economic buyer)
- Owner
- Champion + AE
- Target date
- Week 4
- Milestone
- Procurement + legal redlines started
- Owner
- Procurement
- Target date
- Week 4
- Milestone
- Signature
- Owner
- Economic buyer
- Target date
- Week 6
| Milestone | Owner | Target date |
|---|---|---|
| Eval kickoff with platform team | Champion + AE | Week 1 |
| Security questionnaire submitted | AE → Security | Week 1 |
| Mid-eval check-in + usage review | AE + champion | Week 3 |
| ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. readout to VP Eng (economic buyer) | Champion + AE | Week 4 |
| Procurement + legal redlines started | Procurement | Week 4 |
| Signature | Economic buyer | Week 6 |
Built with the buyer, not handed to them. A plan they co-authored is one they feel accountable to.
Takeaway. A fan likes the product; a champion spends political capital and gets you the intro. Multi-thread Engineering, Security, Procurement and Legal in parallel from week one and hold it together with a mutual action plan the buyer co-owns.
Self-check
Running an evaluation / POC
After this you can drive a trial that proves value and de-risks the buy.
Engineering leaders don't buy on a demo. They buy on data from their own team using the tool on their own code. A POC is your strongest proof point and your biggest risk - an unmanaged trial drifts into "the team played with it, nothing changed," and the deal evaporates.
Treat the eval as a managed project with a defined finish line, not a free trial you check on later. The difference between a POC that closes and one that fizzles is almost always how tightly you ran it.
Define success before the trial startsset the finish line
Agree on what "it worked" means with the buyer up front, in writing. Vague success criteria let a skeptic declare failure no matter what the data shows.
- Measurable
- A number, not a feeling: PR cycle time, hours saved, adoption rate, ramp time
- Time-boxed
- Two to four weeks, with a defined start and a readout date on the calendar
- Scoped
- A named team and a real workload, not "whoever wants to try it"
- Owned
- The buyer agrees these criteria mean yes - so a passing eval is a commitment
Criteria the buyer co-signed turn a successful eval into "we agreed this is a yes," not "let me think about it."
Run it actively
- 1Kick off with the criteria locked. Restate the success metric, the dates and who's in the trial cohort so everyone starts aligned.
- 2Check in weekly. Don't wait for the end. Surface usage data early, catch low adoption fast and remove blockers before they calcify into a "didn't work" story.
- 3Use adoption data as the proof. Real usage - daily active devs, accepted suggestions, Agent runs - is what engineering leaders trust over any vendor benchmark.
- 4Expand the base mid-trial. If one team loves it, get a second team in before the readout. You're building the expansion case while you prove the first one.
When you tie results to usage the team can see in their own dashboard, you stop being a salesperson making claims and become a partner reporting facts. "Your cohort accepted 11,000 suggestions and shipped two days faster on average" is an argument the champion can repeat verbatim to the VP.
Close the loop back to the pain
A POC that proves "the tool is nice" doesn't close. A POC that proves it moved the exact number from discovery does. At the readout, you're connecting two dots you set up weeks earlier.
- Discovery said
- 40 devs losing ~3 hrs/week to toil
- POC proved
- Cohort reclaimed ~2.6 hrs/dev/week
- Therefore
- ~104 hrs/week back - roughly 2.5 engineers of capacity
- Discovery said
- New-hire ramp takes 6 weeks
- POC proved
- Trial hire productive in ~4 weeks
- Therefore
- Faster ramp on every future hire, not a one-time win
- Discovery said
- Velocity flat into a Q3 launch
- POC proved
- Cohort PR cycle time down ~20%
- Therefore
- Launch risk lowered - the compelling event, addressed
| Discovery said | POC proved | Therefore |
|---|---|---|
| 40 devs losing ~3 hrs/week to toil | Cohort reclaimed ~2.6 hrs/dev/week | ~104 hrs/week back - roughly 2.5 engineers of capacity |
| New-hire ramp takes 6 weeks | Trial hire productive in ~4 weeks | Faster ramp on every future hire, not a one-time win |
| Velocity flat into a Q3 launch | Cohort PR cycle time down ~20% | Launch risk lowered - the compelling event, addressed |
The readout isn't a demo recap. It's a proof that the quantified pain from week one actually moved.
Convert the win into expansion, not one team
The mistake is closing the team that ran the POC and stopping. Cursor's whole model rewards seat expansion. The successful eval is your evidence and your proof for a broader rollout.
"The platform team hit the criteria we set - 2.6 hours back per dev, PR cycle time down a fifth. That's the proof. The same math across all 120 engineers is where the real return is. I'd propose we roll out org-wide with a phased onboarding and I'll bring the plan to the readout."
An unmanaged "let them try it for a month" is the most common way a hot deal goes cold. No criteria, no check-ins and at the end nobody can say whether it worked - so the safe answer is no. If a buyer wants a trial, that's your cue to define success and dates on the spot, not to relax.
Takeaway. An eval is a managed project: measurable, time-boxed criteria the buyer co-signs, active weekly check-ins, real adoption data as proof and a readout that ties results to the discovery number - then converts one team into org-wide expansion.
Self-check
QWhat proof point do engineering leaders trust most in a Cursor evaluation?
High-velocity pipeline and forecasting
After this you can manage many deals at once with rigor and honest forecasting.
Cursor's commercial AE runs a high-velocity book that spans fast startups and chunkier mid-market deals at the same time. That only works if your pipeline math is honest and your forecast is something a sales leader can actually trust.
Forecasting discipline is one of the things the hiring manager round tests directly. They'll probe whether you know your numbers cold and whether you call deals the way they really are.
Know your pipeline maththe numbers behind quota
- Coverage ratio
- Open pipeline ÷ quota. 3–4x is typical; below it, you're already behind for next quarter
- Win rate
- Closed-won ÷ all closed. Tells you how much pipeline a number actually requires
- Average cycle time
- Days from first meeting to signature. Sets how early you must source to land in-quarter
- Average deal size
- Drives how many deals you need - and which ones are worth the multi-month gauntlet
Quota ÷ win rate ÷ average deal size = the number of qualified opportunities you must create. Work that backward into weekly outbound.
Cursor expects proactive outbound - you don't wait on inbound. The trap in a high-velocity book is letting prospecting drop while you're heads-down closing, then staring at an empty pipeline the day those deals land. Block time for outbound every week, including your best weeks. Pipeline you didn't build in March is the quota you'll miss in June.
Forecast honestly by stage
Two failure modes both destroy trust with a sales leader and they pull in opposite directions.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Opposite errors, same casualty: a number leadership can't plan the business on.
The fix for both is stage definitions tied to evidence, not optimism. A deal is in a stage because something happened, not because it feels close.
- Stage
- Qualified
- Entry evidence (not a feeling)
- Pain quantified, champion identified, next step booked
- Stage
- Eval / POC
- Entry evidence (not a feeling)
- Success criteria agreed in writing, cohort and dates set
- Stage
- Commit
- Entry evidence (not a feeling)
- Economic buyer confirmed, POC passed, MAP to a signature date
- Stage
- Closed-won
- Entry evidence (not a feeling)
- Signed paper, seats provisioned
| Stage | Entry evidence (not a feeling) |
|---|---|
| Qualified | Pain quantified, champion identified, next step booked |
| Eval / POC | Success criteria agreed in writing, cohort and dates set |
| Commit | Economic buyer confirmed, POC passed, MAP to a signature date |
| Closed-won | Signed paper, seats provisioned |
Evidence-based stages are what make a forecast defensible - and what let you trust your own coverage number.
Keep the book sane
- CRM hygiene isn't busywork - it's how a high-velocity book stays forecastable. Next step and close date on every open deal, updated weekly.
- Prioritize ruthlessly. The deals that deserve your hours have all three: a real champion, quantified pain and a date. Everything else gets a holding pattern, not your best time.
- Be willing to disqualify fast. A clean "not now" is worth more than a zombie deal you nurse for two quarters.
If asked "how do you forecast?", don't describe a tool - describe your discipline. "I only commit deals with a confirmed economic buyer, a passed eval and a mutual action plan to a date. Everything else is best-case or pipeline. I'd rather under-commit and beat it than give you a number you can't plan on." That answer signals exactly the integrity and rigor a flat, fast GTM team has to be able to trust.
Takeaway. High-velocity selling runs on honest math: know your coverage, win rate and cycle time cold, source outbound every week and forecast by evidence-based stages. Happy ears and sandbagging both burn the trust a flat team depends on.