product_sunset_planning v1.0.0

name: product_sunset_planning description: "Sunset a product without burning its users: make the extend, replace, or retire call from lifecycle signals, then run six phases from decide to close, with customer segmentation, migration and data export paths, announcement timing and copy, billing and refund rules, a support tail, and a post-close review. Use when a product, feature, service, or API version may need to end, when a shutdown date has been picked and needs a plan, or when a deprecation notice needs dates, headers, and a migration path that hold up."

Product Sunset Planning

Purpose

End a product in a way users can plan around and the team can defend later. A sunset has two failure modes. The first is deciding too late and announcing with no migration path, no export, and a date picked from a calendar instead of from customer dependency. The second is announcing well and then going quiet, so the last users, who usually need the most help, get the least.

This skill covers the whole job in one system: the call, the six phases, the dates, the copy, the money, and the review. Neighbouring work is different. Product roadmapping plans what lives. A launch checklist ships what starts. This skill closes what ends.

Workflow

1. Make the call from signals, not from mood. Score the seven signals in references/decision-signals.md: active use trended over four quarters, dependency depth, revenue against full cost, replacement coverage per top use case, risk of staying, contract and legal floor, and strategic fit stated in one concrete sentence. Each score needs an evidence line. The call is one of three: extend with a named review date and a maintenance budget, replace with a successor running in parallel until migration evidence sets the date, or retire through the full six phases. If the contract floor or the export check has not been run, there is no call yet and no date.

1. Phase 1, decide. Lock the call, the owner, and the close date in a written decision record before any external wording exists. Pick the close date from two floors, whichever is later: the notice benchmark for the segment and the longest promise already made to customers. Benchmarks from published vendor policies: Google Cloud promises at least 12 months notice before discontinuing a service unless it is replaced with a materially similar one. Microsoft Modern Lifecycle promises a minimum of 12 months notification before ending support when no successor is offered. Salesforce supports each API version for a minimum of three years and gives at least one year notice before support ends. Run python3 scripts/sunset_timeline.py --announce YYYY-MM-DD --close YYYY-MM-DD --segment enterprise (or api or consumer) to check the window against the benchmark and generate the milestone dates. Exit code 1 means the window sits below the benchmark. That needs a written reason, not a quiet override.

1. Phase 2, prepare, still private. Build everything the announcement will point at, and test it on a real account. Segment customers by dependency depth and contract value. Name the high dependency accounts and give each one an owner for direct outreach. Build the migration path and the data export, run a full export, open it somewhere clean, and match the record counts. Where GDPR or a similar law applies, export must cover the data a person provided, in a structured, commonly used, machine readable format, per Article 20. Brief support with a sunset FAQ and an escalation route. Brief sales and partners under embargo, with the stop date for new sales in writing. Set the billing plan: when charging stops, how prepaid time past the close date is handled, and the refund rule. Work through references/phase-checklists.md phase by phase.

1. Phase 3, announce. Announce on one day, on every channel at once: direct email to account owners from a named product lead, in-product notice, public post, and a dated entry on a lifecycle page customers can check later. Use templates/announcement-templates.md. The first announcement must name the close date in its first lines, give the real reason in one sentence, state what stops today and what keeps working, link the migration guide and the export, state the last export date and what happens to data after it, state the money rule, and name when the next update will arrive. Stop new signups and new sales the same day. Selling into a closing product after the decision is the one move users never forgive. For an API, add machine readable signals the same day: a Deprecation header, a Sunset header per RFC 8594 with the close date, and a Link header pointing at the migration guide, so client code can surface the deadline without a human reading a blog post.

1. Phase 4, migrate. Track migration per segment in account counts, reviewed weekly. Send reminders on the timeline script cadence: a progress check early, a halfway checkpoint where every unmigrated account is named with a reason and a next step, direct outreach at 90 days out, a final push at 30 days, and daily reminders in the last week. Run clinics or office hours for high dependency accounts. At the freeze date set in the plan, ship security and availability fixes only, and say so publicly before the freeze starts. AWS FinSpace is the clean model here: announced October 7, 2025, closed to new customers that same day, existing use continued as normal with critical security and availability updates, and support ended October 7, 2026. The worked read of that case and of the Stadia close is in references/worked-sunsets.md.

1. Phase 5, close. Close at the announced time, in the announced timezone, not early and not quietly late. If the date must move, move it later, announce the change with the reason, and reset the reminder cadence. On close day the service should return a clear closed notice with links to export help, refund status, and support, not an error page. Process refunds on the announced schedule. Stadia set the consumer bar: announced September 29, 2022, access through January 18, 2023, the store disabled at announcement, and full refunds for hardware and for game and add-on purchases through its stores, with most refunds expected done by mid-January 2023. A short consumer window can be fair when refunds or migration help carry real weight. A short window with neither is just abrupt.

1. Phase 6, support the tail, then review. Keep support staffed for the tail period named in the announcement, with people who can still reach the data. Keep honouring export requests until the export deadline stated at announcement. Execute data deletion or retention on the date stated at announcement and log it. Close out contracts, vendor agreements, and licences tied to the product. Within 30 days, write the post-close review: timeline against plan, accounts migrated and accounts closed unmigrated, exports run, refunds paid, support load by week, what surprised the team, and what the next sunset should change. File it where the next product team will find it and link it from the lifecycle page.

Output Contract

• The decision record: the call (extend, replace, or retire), the scored signals with evidence lines, the contract floor, the owner, and the review date if the call is extend.
• The sunset plan, filled from templates/sunset-plan-template.md, with the timeline script output pasted in and its benchmark verdict shown, not hidden.
• The announcement set: first announcement, short public form, the 30 day reminder, and the close day notice, each carrying every required element from the templates file.
• The migration tracker shape: segments, account counts, migrated counts, and the named list process for unmigrated accounts at the halfway checkpoint.
• The money sheet: charging stop date, prepaid handling, and the refund rule with dates.
• The close and tail record: close confirmation, export deadline, deletion or retention log entry, and the post-close review with the numbers listed in the plan template.

Operating Rules

• No date before the call, and no call before the contract floor and export checks. A date announced and then moved earlier destroys trust faster than a late date announced once.
• Never shorten a published timeline. Extending is allowed with a reason. Shortening is allowed only where a critical security or legal problem forces it, and that reason goes in the announcement itself.
• The announcement is not ready until everything it links to is ready and tested: migration guide, export, FAQ, and refund process. Announcing a path that does not exist yet is the most common sunset failure.
• Stop new sales at announcement, always. No exceptions for a good quarter, a big prospect, or a partner request.
• Segment the work. High dependency accounts get a person and a conversation. Broadcast email alone is a plan for low dependency accounts only.
• Keep the product safe for the whole window. Security and availability fixes continue until close. A decaying service during migration punishes the users who stayed longest.
• State the data story in full at announcement: what can be exported, in what format, until when, and what happens after that date. Users should never have to ask what happens to their data.
• Write the reason plainly in one sentence. Vague reasons read as hidden reasons, and hidden reasons get filled in by rumour.
• Style for any copy this skill produces: no em dashes, no hype words, no press release tone. Dates early, facts first, plain words.