The Scope Creep Pushback Writer: Turn a “Just One More Thing” Request Into a Professional Boundary-Setting Message
Why this prompt matters
Teams that respond to scope-creep requests with silent compliance train stakeholders that deadlines and committed scope are always negotiable after the fact. That pattern compounds: unplanned overtime becomes routine, engineers burn out from repeated late nights nobody budgeted for, and the team's forecasts stop being something stakeholders can actually plan around, because everyone has learned the real deadline is whatever gets asked for last.
What we use it for
A product manager emails an engineering lead mid-sprint, two days before a Friday release, asking the team to “just quickly add” a new feature with no change to the deadline — right after the team already absorbed two unplanned scope additions in the past month without renegotiating anything.
Prompt
Act as a senior delivery/project lead who is skilled at protecting team capacity while keeping stakeholder relationships intact. You have been asked to respond, in writing, to a mid-cycle request to expand scope without a corresponding change to the deadline or resources.
Context:
- The request: [DESCRIBE WHAT WAS ASKED FOR]
- Current commitment: [CURRENT DEADLINE AND SCOPE ALREADY COMMITTED]
- Who is asking: [REQUESTER'S ROLE AND HOW MUCH THIS RELATIONSHIP MATTERS]
- Team capacity right now: [HOW STRETCHED THE TEAM ALREADY IS, E.G. CURRENT WORKLOAD OR RECENT OVERTIME]
- History with this requester: [FIRST-TIME ASK OR A REPEAT PATTERN, AND HOW PREVIOUS ASKS WERE HANDLED]
Task: Write a message that:
1. Acknowledges the request specifically, without vague throat-clearing.
2. States plainly which of the three levers must move to accommodate it: scope, timeline, or resources (name which ones, concretely).
3. Offers [NUMBER, E.G. 2-3] distinct paths forward, each naming its exact trade-off (what gets delayed, cut, or added) in one sentence.
4. Ends with a specific, dated ask for a decision, not an open-ended "let me know what you think."
Constraints:
- Do not apologize for raising the trade-off; apologizing undermines the boundary.
- Do not use passive-aggressive hedges ("just wanted to flag," "not a big deal, but").
- Do not propose silently absorbing the work as one of the options, even as a throwaway line.
- Keep the total message under 180 words.
- Match the tone to [FORMALITY LEVEL, E.G. CASUAL SLACK MESSAGE VS. FORMAL EMAIL TO AN EXECUTIVE].
Output Format:
- First line: one sentence naming the ask and the trade-off in plain terms.
- Body: the acknowledgment, the named trade-off, and the numbered options.
- Closing line: the specific, dated decision request.Result
Subject: CSV export request — this needs one of three trade-offs
Hi Priya,
Adding CSV export to this sprint is doable, but it's not free. Taking it on means one of three things has to move: the Friday ship date, the current release scope, or the engineering hours we have this week. With Dana out sick since Monday, we're already running at full capacity against what's already committed for Friday — adding net-new work on top of that without changing anything else isn't realistic.
Here are three ways to make this happen:
1. Ship CSV export Friday as planned, and move the saved-filters feature to next sprint to make room for it. 2. Keep all currently committed scope for Friday, and ship CSV export as a fast-follow the following Wednesday instead. 3. Bring James in from the platform team for two days this week to add capacity. This keeps both Friday's date and the current scope intact, but needs his manager's sign-off today, not tomorrow, or it won't land in time.
I'd rather pick one of these now than try to absorb it quietly — that's exactly what led to the two unplanned late nights last sprint, and I don't want to repeat that pattern for the team.
Can you tell me which option works by end of day tomorrow so I can plan the week with the team accordingly?
Thanks, Marcus
Scope creep rarely arrives as an obvious crisis. It shows up as a casual “can you just add” request slipped into a Slack message or a meeting aside, with no mention of what has to move to make room for it. The person asking usually isn't trying to be unreasonable — they genuinely don't see the trade-off, because nobody has named it for them. This prompt is built around that gap: it forces the response to make the trade-off explicit (scope, timeline, or resources — pick one) before offering any paths forward, so the requester is choosing between real options instead of being told “no” or getting a silent yes that quietly costs the team a weekend.
The structure matters more than the wording. Naming the specific levers first stops the conversation from turning into a vague negotiation about whether the request is “reasonable.” It isn't about reasonableness — it's about arithmetic: something has to give. The constraint against silently absorbing the work as an option is there because that's the default failure mode; without it, even a well-intentioned response can end with an implicit fourth option of “I guess we'll just squeeze it in,” which defeats the entire purpose.