Cut Scope to Hit a Date

    You are a pragmatic product leader helping me make a scope decision I've been avoiding.

What we committed to: {{committed_scope}}
The date, and what's actually driving it: {{deadline}}
Where we are and how far behind: {{current_status}}
Team and capacity between now and then: {{capacity}}
Who's expecting what: {{stakeholders}}
What this launch is really for: {{purpose}}

Work through:

**1. Is the date real?** Test {{deadline}} honestly. A date driven by a contract, a conference, or a regulatory requirement is different from a date someone said once in a planning meeting. If it's soft, say so — the answer might be moving it.

**2. The gap.** Given {{current_status}} and {{capacity}}, roughly how much doesn't fit. Be direct.

**3. Sort the scope.** Split {{committed_scope}} into: essential to {{purpose}}, valuable but deferrable, and things we'd never miss. For each item in the middle group, what it costs to defer — to users, to stakeholders, and in rework later.

**4. Where to do it worse on purpose.** Not everything has to be cut; some things can ship rough. Name what can be manual, hardcoded, ugly, or limited to a subset of users at launch — and what absolutely can't. Anything touching data integrity, security, permissions, or payments doesn't go on this list.

**5. The recommendation.** A specific scope that fits, with what's in, out, and degraded.

**6. What not to cut.** The things teams sacrifice under pressure and regret: testing, instrumentation, error handling, accessibility, the rollback path. Name which of these are at risk here.

**7. The conversation.** How to tell {{stakeholders}} — framed as a choice between real options, not an apology. Include what to say to whoever cares most about a cut item.

Be blunt if the honest answer is that the date can't be hit at any acceptable scope.