Internal Stakeholder Deprecation Briefing Prompt

This prompt is designed for product managers and technical program managers who need to brief internal stakeholders—support, sales, engineering leadership, and customer success—on an upcoming API, SDK, or feature deprecation. The job-to-be-done is converting raw deprecation plans, usage analytics, and customer impact data into a structured executive summary that drives alignment and operational readiness. The ideal user has access to concrete inputs: a deprecation timeline, a list of affected endpoints or methods, usage telemetry showing active consumers, a migration or replacement path, and known customer contracts or SLAs that may be affected. Without these inputs, the prompt will produce a vague summary that fails the core goal of preparing internal teams for customer conversations.

Use this prompt when you have a confirmed deprecation decision with a defined timeline and you need a single source of truth for internal stakeholders. It is appropriate for briefings that will be read by directors and VPs who need business rationale and risk assessment, as well as frontline managers who need a support playbook and escalation procedures. The prompt is not a replacement for the customer-facing deprecation notice, the engineering migration guide, or the legal compliance review. It is also not suitable for speculative deprecation discussions where no decision has been made—using it in that context risks creating false certainty and premature alarm. If the deprecation affects regulated data or has material revenue impact, the output must be reviewed by legal and compliance before circulation.

Before using this prompt, gather the required inputs: a clear deprecation date and enforcement stages, a list of deprecated surfaces, usage data segmented by customer tier or contract, the replacement API or feature with a migration link, known customer impacts with counts or percentages, and the escalation contact for critical accounts. The prompt will structure these into a briefing that covers business rationale, customer impact estimates, a support playbook, and escalation procedures. After generating the briefing, validate that every date, contact, and impact figure matches your source data. Do not circulate the output without human review, especially if it contains revenue-impact estimates or customer-specific details. For high-risk deprecations, pair this prompt with the Deprecation Communication Compliance Check Prompt to ensure regulatory obligations are met before internal distribution.

This prompt template generates an executive-ready briefing for internal stakeholders—support, sales, engineering leadership, and customer success—about an upcoming API, SDK, or feature deprecation. It is designed to be wired into a product management workflow where usage analytics, customer impact data, and escalation procedures are already gathered. The template forces the model to produce a structured document with business rationale, impact estimates, a support playbook, and escalation paths, rather than a generic announcement.

textCopy
You are an internal product communication specialist drafting a deprecation briefing for cross-functional stakeholders.

Generate an internal stakeholder deprecation briefing using the inputs below. Follow the output schema exactly. Do not invent dates, customer counts, or revenue figures not present in the inputs.

[INPUT]
- Deprecated surface: [DEPRECATED_API_OR_FEATURE_NAME]
- Replacement surface: [REPLACEMENT_NAME_OR_NONE]
- Announcement date: [ANNOUNCEMENT_DATE]
- End-of-life date: [END_OF_LIFE_DATE]
- Brownout dates (if any): [BROWNOUT_DATES]
- Usage data summary: [USAGE_TELEMETRY_SUMMARY]
- Known affected customers/teams: [AFFECTED_CUSTOMERS_LIST]
- Migration effort estimate: [MIGRATION_EFFORT_ESTIMATE]
- Business rationale: [BUSINESS_RATIONALE]
- Support playbook notes: [SUPPORT_PLAYBOOK_NOTES]
- Escalation contacts: [ESCALATION_CONTACTS]
- Risk classification: [RISK_CLASSIFICATION]

[OUTPUT_SCHEMA]
{
  "briefing_title": "string",
  "executive_summary": {
    "decision": "string (one sentence on what is being deprecated and why)",
    "business_rationale": "string (2-3 sentences)",
    "risk_level": "low | medium | high | critical",
    "risk_rationale": "string (1-2 sentences explaining the risk classification)"
  },
  "timeline": {
    "announcement_date": "ISO date",
    "brownout_dates": ["ISO date or null"],
    "end_of_life_date": "ISO date",
    "enforcement_stage": "announced | warning | brownout | shutdown"
  },
  "customer_impact": {
    "estimated_affected_accounts": "number or range",
    "top_affected_segments": ["string"],
    "migration_effort": "low | medium | high | critical",
    "migration_effort_detail": "string (1-2 sentences)",
    "replacement_available": true,
    "replacement_name": "string or null"
  },
  "support_playbook": {
    "customer_facing_message_summary": "string (2-3 sentences support can use)",
    "common_questions_and_answers": [
      {"question": "string", "answer": "string"}
    ],
    "escalation_path": {
      "tier_1_contact": "string",
      "tier_2_contact": "string",
      "executive_sponsor": "string"
    },
    "do_not_say": ["string (phrases support should avoid)"]
  },
  "internal_actions_required": [
    {
      "team": "string",
      "action": "string",
      "deadline": "ISO date or null",
      "owner": "string"
    }
  ],
  "communication_plan": {
    "internal_briefing_complete": true,
    "customer_notification_date": "ISO date or null",
    "status_page_update_date": "ISO date or null",
    "follow_up_briefing_date": "ISO date or null"
  }
}

[CONSTRAINTS]
- Use only information provided in [INPUT]. Mark missing data as null.
- Do not speculate on customer reactions or revenue impact.
- If no replacement exists, set replacement_available to false and replacement_name to null.
- Risk classification must match [RISK_CLASSIFICATION] if provided; otherwise derive it from affected account count and migration effort.
- The support playbook must include at least 3 common questions and 2 "do not say" phrases.
- All dates must be valid ISO 8601 format or null.

[EXAMPLES]
Input: Deprecated surface "v1/charges", replacement "v2/payments", 500 affected accounts, high migration effort.
Output snippet:
"customer_impact": {
  "estimated_affected_accounts": 500,
  "migration_effort": "high",
  "migration_effort_detail": "Requires auth flow changes and new idempotency key handling."
}

To adapt this template, replace each square-bracket placeholder with data from your API analytics dashboard, customer success CRM, and product roadmap. The [USAGE_TELEMETRY_SUMMARY] should include call volumes, unique consumers, and error rate trends if available. The [SUPPORT_PLAYBOOK_NOTES] should capture phrases your support leadership wants the team to use or avoid. If you lack brownout dates, set [BROWNOUT_DATES] to an empty array. The output schema is designed to be machine-readable—ingest it into a briefing distribution system or render it into a slide deck. Always run the output through a schema validator before distribution; a malformed date or missing escalation contact can delay an entire deprecation timeline.

This prompt is designed to be called from an internal tool or workflow—typically a product operations dashboard, a release management system, or a scheduled job that triggers when a deprecation decision reaches 'committed' status. The caller must assemble the required inputs: usage analytics (endpoint call volumes, unique consumer counts, error rate trends), customer success data (affected accounts, support ticket history, contractual commitments), and the deprecation decision record (rationale, timeline, replacement mapping). Because the output will be read by support, sales, and engineering leadership, the implementation must treat this as a high-stakes document generation task with mandatory human review before distribution.

Wire the prompt into an application with a pre-generation validation layer that checks all input placeholders are populated and non-stale. For example, usage data older than 7 days should trigger a refresh warning. After the model returns the executive summary, run a post-generation schema validator that confirms the output contains all required sections: business rationale, customer impact estimate (with cohort breakdown), support playbook, escalation procedures, and timeline. If any section is missing or below a minimum length threshold, retry once with a more explicit instruction appended to the prompt. Log every generation attempt—including the full prompt, model response, validator results, and retry count—to an audit table keyed by deprecation ID. This audit trail is essential for governance reviews and for debugging prompt drift over time.

Choose a model with strong instruction-following and structured output capabilities. For this workflow, a model that supports JSON mode or structured output constraints is preferred so you can enforce the output schema programmatically. Do not use a chat-optimized model that tends to add conversational filler. Set temperature low (0.0–0.2) to maximize factual consistency across runs. If your deprecation involves regulated data or contractual SLAs, route the final output through a human approval queue that requires sign-off from the product manager and a legal or compliance reviewer before the briefing is distributed. Never auto-publish this briefing to stakeholders without review. The next step after validation is to store the approved briefing in your document repository and trigger notifications to the distribution list specified in the escalation procedures.