1 min lesson
Scoping a program from ambiguity
Say what this means in practice. "The first move is to refuse the activity framing."
Step 1 of 3
The execution round usually opens with a deliberately fuzzy ask, because that is how the work actually arrives at Cursor. A founder says "our inference bill is scaring me" in a Slack thread and three weeks later there needs to be a program. The interviewer is watching whether you convert that into something a flat, fast org can act on without a planning committee.
The first move is to refuse the activity framing. "Optimize inference" is not a goal, it is a vibe. A goal is a number with a direction and a date attached to it, owned by someone whose name you can say out loud.
Learn more
Advanced table
Every good scope is a metric movement plus a guardrail
- Vague mandate
- "Optimize inference"
- Scoped goal
- "Cut inference COGS per active user 15% by end of Q3 without regressing tab-completion p95 latency"
- Why the rewrite wins
- Names the metric, the bound, the guardrail and the date, so now it is testable
- Vague mandate
- "Get capacity under control"
- Scoped goal
- "Hit 55% sustained GPU utilization on the reserved fleet while keeping burst headroom for a 2x DAU spike"
- Why the rewrite wins
- Turns a feeling into a target and an explicit constraint you can plan against
- Vague mandate
- "Make migrations safer"
- Scoped goal
- "Zero customer-visible incidents across the serving-stack migration, with rollback under 10 minutes at every step"
- Why the rewrite wins
- Defines success as an outcome plus a recovery SLO you can check at every step
| Vague mandate | Scoped goal | Why the rewrite wins |
|---|---|---|
| "Optimize inference" | "Cut inference COGS per active user 15% by end of Q3 without regressing tab-completion p95 latency" | Names the metric, the bound, the guardrail and the date, so now it is testable |
| "Get capacity under control" | "Hit 55% sustained GPU utilization on the reserved fleet while keeping burst headroom for a 2x DAU spike" | Turns a feeling into a target and an explicit constraint you can plan against |
| "Make migrations safer" | "Zero customer-visible incidents across the serving-stack migration, with rollback under 10 minutes at every step" | Defines success as an outcome plus a recovery SLO you can check at every step |
Every good scope is a metric movement plus a guardrail. COGS in the first row is the cost of serving the product, and the guardrail is what stops you from cutting it by tanking latency.
Cost programs are dangerous precisely because cost is easy to cut if you ignore everything else. Quantize the model, batch more aggressively, route to a smaller model and you can save real money while quietly making tab-prediction feel sluggish. Stating the latency or quality guardrail in the goal itself is what separates a TPM who has run a cost program from one who has read about one.