1 min lesson
Talking ROI without overclaiming
Choose two examples from the table in "Talking ROI without overclaiming" and explain what each teaches you to do.
Step 1 of 2
Tell a room of senior engineers that Cursor makes them "55% faster" and you've lost them. They've read the same studies you have and they know that number doesn't survive contact with a real codebase.
You need the productivity vocabulary and its limits in equal measure. Know what each term means, where it's measured and where it breaks, because a skeptical VP of Engineering will test exactly that.
- Concept
- Cycle time
- What it measures
- Time from first commit to merge
- Where it breaks
- Confounded by review queues, on-call, scope changes - not a clean AI signal
- Concept
- PR throughput
- What it measures
- PRs merged per engineer per period
- Where it breaks
- Easy to game; more small PRs isn't more value
- Concept
- DORADORA metrics. Four widely-used delivery measures: deployment frequency, lead time for changes, change failure rate and time to restore service. Press Enter for the full definition. metrics
- What it measures
- Deploy frequency, lead time, change-fail rate, MTTRMean Time to Restore. How long it takes to recover service after a failed change or incident. Press Enter for the full definition.
- Where it breaks
- Org-level health, not a tool-attribution instrument
- Concept
- "X% faster"
- What it measures
- Headline from a controlled study
- Where it breaks
- Doesn't generalize to a specific team or codebase; senior engineers distrust it
| Concept | What it measures | Where it breaks |
|---|---|---|
| Cycle time | Time from first commit to merge | Confounded by review queues, on-call, scope changes - not a clean AI signal |
| PR throughput | PRs merged per engineer per period | Easy to game; more small PRs isn't more value |
| DORADORA metrics. Four widely-used delivery measures: deployment frequency, lead time for changes, change failure rate and time to restore service. Press Enter for the full definition. metrics | Deploy frequency, lead time, change-fail rate, MTTRMean Time to Restore. How long it takes to recover service after a failed change or incident. Press Enter for the full definition. | Org-level health, not a tool-attribution instrument |
| "X% faster" | Headline from a controlled study | Doesn't generalize to a specific team or codebase; senior engineers distrust it |
Use these to frame a conversation, never to claim a number you can't defend in that account.
Learn more
Full explanation
Credible ROI Answer Vs. the Overclaim
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Two ways to answer "how much faster?" - one earns trust, one forfeits it.
The trap is attribution. AI-assisted coding lives inside a system with reviews, meetings, flaky tests and scope churn, so isolating Cursor's contribution to a clean percentage is something an honest engineer knows you can't do. Reach for an unprovable figure and you forfeit the credibility the whole renewal rests on.
Learn more
Optional practice
Practice: Talking ROI without overclaiming
QA CTO asks, "How much faster will Cursor make my engineers?" What's the credible way to answer?