Written Communication Pack -- Launch Slip + Scope Cut Request

Step 1: Intake + Artifact Selection

Message Brief

• Artifact type + channel: Email (sent to exec stakeholders via email)
• Audience (roles/seniority): Executive stakeholders (VP/C-level); they care about launch timing, revenue impact, customer commitments, and team capacity
• Goal (inform/align/decide): Decide -- get approval for a specific scope cut
• Ask (what should they do, by when): Approve dropping Feature B from the launch scope by end of day Friday
• Why now (1 sentence): A dependency delay has pushed the launch 2 weeks; cutting Feature B is the fastest path to hold the revised date without further risk.
• Key facts: Launch slipping 2 weeks; root cause is dependency delays (not team performance); Feature B is the proposed cut; Features A and C remain on track
• Sensitivities / what to avoid: Do not assign blame to specific teams or individuals for the dependency delay; do not frame as a failure -- frame as a trade-off decision
• Links: [Placeholder: project tracker], [Placeholder: canonical project doc]
• Tone + length constraints: Direct, calm, factual. Under 250 words for the email body.

Artifact selection rationale

Email is the lightest artifact that achieves the outcome. Exec stakeholders need a clear ask with enough context to decide -- not a memo or doc. A short email with TL;DR, options, and next steps is appropriate.

Step 2: Outcome + Ask (One Sentence)

After reading, exec stakeholders will approve (or propose an alternative to) dropping Feature B from the launch scope so the team can lock the revised timeline by Friday.

• Ask type: Decision -- approve recommended scope cut
• Deadline: End of day Friday
• Response path: Reply to this email with approval or reply with concerns/alternative by Thursday EOD so we can discuss before the Friday deadline

Step 3: "How" -- Actionable Next Steps

What changes vs. what stays the same

Changing:

• Feature B is removed from launch scope and moved to a fast-follow release (target: 3 weeks post-launch)
• Launch date shifts from original date to 2 weeks later (revised date)

Not changing:

• Features A and C ship as planned on the revised launch date
• Go-to-market plan, marketing assets, and customer communications proceed on the revised date
• Team staffing and resourcing remain the same

Next steps (owner + date)

1. Exec stakeholders: Approve scope cut (drop Feature B) -- by Friday EOD
2. [PM name]: Update the project tracker and communicate revised scope to eng + design -- Monday (following approval)
3. [Eng lead]: Re-plan Feature B as fast-follow; share updated estimate -- by next Wednesday
4. [PM name]: Notify external partners/customers of revised launch date -- Monday (following approval)
5. [PM name]: Send status update confirming locked plan -- next Friday

Dependencies and risks

• If approval is delayed past Friday, the 2-week slip may extend further as the team loses planning time over the weekend.
• Feature B fast-follow depends on the same dependency resolving; [Eng lead] will confirm feasibility by next Wednesday.

Step 4: Outline (Structured for Skim)

Subject: Decision needed by Friday: Drop Feature B to hold revised launch date

TL;DR (3 bullets)

• Launch is slipping 2 weeks due to an external dependency delay.
• Recommendation: drop Feature B from launch (move to fast-follow) to lock the revised date with confidence.
• Ask: approve this scope change by Friday EOD; reply with concerns by Thursday if you see issues.

What's happening (short context)

• One sentence on the dependency delay and its impact.

What's changing (and what's not)

• Changing: Feature B out of launch, moved to fast-follow.
• Not changing: Features A + C, GTM plan, team resourcing.

What I need from you

• Approve or raise concerns by Friday.

Next steps (owned, dated)

• Numbered list with owners and dates.

Risks / Open questions

• Delay cost, fast-follow feasibility.

Step 5: Draft Email

Subject: Decision needed by Friday: Drop Feature B to hold revised launch date

Hi team,

TL;DR

• Our launch is slipping 2 weeks due to an external dependency delay outside our control.
• To hold the revised launch date with high confidence, I recommend we drop Feature B from the initial launch and ship it as a fast-follow (targeting 3 weeks post-launch).
• I need your approval on this scope change by Friday EOD. If you have concerns, please reply by Thursday so we can discuss before the deadline.

What's happening

A key upstream dependency missed its delivery date, which blocks Feature B. Features A and C are unaffected and on track. Waiting for the dependency to resolve would add 4+ weeks of uncertainty to the timeline. Cutting Feature B now lets us lock a firm revised launch date.

What's changing -- and what's not

What I need from you (by Friday EOD)

• Approve dropping Feature B from launch scope (recommended), OR
• Reply with concerns by Thursday EOD so we can align before the deadline

If I do not hear back by Friday, I will proceed with the scope cut to protect the revised timeline.

Next steps

1. Exec stakeholders: Approve scope cut -- Friday EOD
2. [PM name]: Update tracker and communicate revised scope to eng + design -- Monday
3. [Eng lead]: Re-plan Feature B as fast-follow; share updated estimate -- next Wednesday
4. [PM name]: Notify external partners of revised launch date -- Monday
5. [PM name]: Send status update confirming locked plan -- next Friday

Links

• Project tracker: [link]
• Canonical project doc: [link]

Thanks, [Your name]

Step 6: Clarity Pass ("Letter to Yourself")

Internal version (what am I actually saying?)

"We hit a dependency delay. Feature B is blocked. If we wait, the timeline gets worse. The cleanest move is to cut Feature B now and ship it 3 weeks later. I need exec sign-off by Friday so we can lock the plan and stop burning planning cycles on uncertainty."

Rewrite check

The draft already leads with this logic: problem (delay) -> recommendation (cut Feature B) -> ask (approve by Friday) -> what happens next (owned steps). The through-line is clean. No buried lede. No contradictions. The "if I do not hear back" line ensures a default action path, which reduces ambiguity.

No significant rewrite needed. The draft stands.

Step 7: Canonical Doc Check

This email is a point-in-time decision request, not an ongoing reference. However, it references an existing project that likely needs a single source of truth.

Recommendation: Ensure the project tracker and canonical project doc links in the email are live and current. After the decision is made, log the decision (scope cut approved / alternative chosen) in the canonical project doc with the date and rationale.

Canonical doc update (post-decision):

This is not a case where a new canonical doc is needed -- the existing project doc should be updated.

Step 8: Quality Gate + Finalize

Universal Checklist

• Audience is clear; the first screen answers "why am I reading this?"
• The ask is explicit (decision) and includes a deadline (Friday EOD)
• The "how" is concrete: steps, owners, and dependencies are specified
• TL;DR exists and matches the body (no surprises)
• Scanability: headings, bullets, short paragraphs; no wall-of-text sections
• Terms, acronyms, and dates are unambiguous; key numbers are written down
• Single source of truth is linked for ongoing work
• Tone is direct and respectful; avoids blame; assumes good intent
• Safety: no secrets, credentials, or unnecessary sensitive/PII details

Decision Request Checklist

• Options are stated (approve scope cut OR raise concerns) with recommendation (approve)
• Tradeoffs are explicit (drop Feature B now vs. 4+ weeks of additional uncertainty)
• The cost of delay is stated (timeline extends further; planning cycles wasted)
• "If you disagree" path is clear (reply with concerns by Thursday EOD)

Rubric Scoring

Risks / Open Questions / Next Steps

Risks

• Fast-follow feasibility: Feature B's fast-follow timeline (3 weeks post-launch) depends on the same upstream dependency resolving. If it does not, the fast-follow date will also slip. [Eng lead] will confirm feasibility by next Wednesday.
• Customer impact: If any customers were specifically promised Feature B at launch, the PM should identify them and prepare targeted messaging before the Monday notification.
• Silence = approval: The "if I do not hear back" default could cause friction if a stakeholder misses the email. Consider a Slack ping on Thursday as a nudge.

Open Questions

• Are there any customer commitments tied specifically to Feature B at launch that would change the calculus?
• Does the GTM team need to adjust any launch messaging given the Feature B removal, or is it low-visibility enough to handle post-launch?
• Should the fast-follow be communicated externally now, or only after the dependency is confirmed resolved?

Next Steps

1. Send email to exec stakeholders (today)
2. Slack-ping key stakeholders Thursday if no reply received
3. Log decision in canonical project doc (Friday, after approval)
4. [PM name]: Execute post-approval communication plan (Monday)
5. [Eng lead]: Confirm Feature B fast-follow feasibility (next Wednesday)
6. [PM name]: Send locked-plan status update (next Friday)