/feature-sunset

name: feature-sunset
description: Plan and communicate a feature or product end-of-life. Use when deprecating features, sunsetting products, or managing migration off legacy systems.

Feature Sunset & EOL

Shutting things down is harder than launching them. This skill walks you through the full lifecycle: impact analysis, migration planning, communication strategy, and stakeholder management. Claude handles the artifact generation; you handle the relationship sensitivity and timing judgment.

When to Use

• Deprecating a feature that has active users
• Sunsetting a product or product tier
• Migrating users off a legacy system
• Removing an integration or API that external partners depend on
• Consolidating overlapping features after an acquisition

When NOT to Use

• You're deciding whether to build something — use Discovery Process
• You're evaluating tech debt (not removing features) — use Tech Debt Communication
• You're communicating a scope reduction in an upcoming release — that's release planning, not EOL

The AI-Native Approach

| Step | Time | Claude Does | You Do | |---|---|---|---| | Impact analysis | 1 hr | Quantify usage, identify affected users, model revenue risk | Validate data, add relationship context | | Migration planning | 1-2 hrs | Design migration path, generate guides and timelines | Confirm with engineering, set deadlines | | Communication strategy | 1-2 hrs | Draft multi-audience communications at each stage | Add empathy, timing, and relationship awareness | | Stakeholder alignment | 1 hr | Prepare decision document and FAQ | Navigate the politics and get sign-off |

Process

Step 1: Impact Analysis (1 hour)

We're considering sunsetting [feature/product]. Here's what we know:

Usage data:
- [Active users/accounts using this feature]
- [Usage frequency and trend — growing, stable, declining]
- [Revenue attributed to or dependent on this feature]

Help me assess the full impact:
- How many users are affected and in which segments?
- What's the revenue at risk (direct and indirect)?
- Are any contractual obligations tied to this feature?
- What do these users do with this feature — what job does it serve?
- What alternatives exist (in our product or elsewhere)?
- What's the cost of maintaining it vs. the cost of removing it?

Step 2: Design Migration Path (1-2 hours)

For users affected by this sunset, design a migration plan:

For each user segment:
- Where do they go? (alternative feature, competitor, workaround)
- What do they need to do? (export data, change workflow, update integrations)
- What do we provide to help? (migration tool, guide, support, credits)
- Timeline: how much notice and what's the grace period?

Migration timeline:
1. Announcement: [date] — feature continues working, users notified
2. Deprecation warning: [date] — in-app warnings, feature flagged
3. Migration support window: [date range] — active help for transitioning users
4. Read-only / reduced functionality: [date] — can access data but not create new
5. Full removal: [date] — feature removed, data archived or exported

For each phase: what changes for the user, what we communicate, what support we offer.

Step 3: Communication Strategy (1-2 hours)

EOL communication happens in waves, not a single announcement.

Draft communications for each phase of the sunset:

Phase 1 — Early notice (8-12 weeks before removal):
- Email to affected users: what's happening, why, what they should do, timeline
- In-app notification: brief, links to details
- Internal announcement: what the team needs to know
- Tone: transparent, empathetic, solution-oriented

Phase 2 — Migration support (4-8 weeks before):
- Follow-up email to users who haven't migrated
- Help center article: step-by-step migration guide
- FAQ: anticipated questions with honest answers
- For high-value accounts: personal outreach talking points

Phase 3 — Final warning (1-2 weeks before):
- Last-chance email with clear deadline
- In-app banner: urgent but not alarmist
- Support team briefing: expected ticket volume and escalation path

Phase 4 — Post-removal:
- Confirmation email: what happened, where to find their data, who to contact
- Updated help docs: remove references to sunset feature

For each communication: draft the copy, specify the audience, and note the delivery channel.

Step 4: Stakeholder Alignment (1 hour)

Draft a decision document for the sunset:

1. What we're sunsetting and why (business rationale)
2. Impact: users affected, revenue at risk, migration cost
3. Migration plan summary
4. Communication timeline
5. Risk: what could go wrong and how we mitigate
6. Ask: approval to proceed with [date] for announcement

Also draft a FAQ for internal stakeholders:
- "Why are we doing this?" — [business rationale]
- "What about customer X who depends on this?" — [migration plan for key accounts]
- "What if churn spikes?" — [monitoring plan and rollback criteria]
- "Can we just leave it?" — [cost of maintenance vs. benefit of removal]

Output

• Impact analysis with user segments, revenue risk, and maintenance cost
• Migration plan with timeline, user guides, and support resources
• Multi-phase communication package (emails, in-app, help docs, FAQs)
• Stakeholder decision document
• Internal FAQ for customer-facing teams

Common Pitfalls

1. **Not enough notice.** Minimum 8 weeks for a minor feature, 6+ months for a product or API that external systems depend on. Rushed sunsets destroy trust. 2. **No migration path.** "We're removing this" without "here's what to do instead" is abandonment. Always provide an alternative, even if it's an export. 3. **Burying the news.** Don't hide a sunset in a changelog. Proactive, direct communication shows respect for the users who relied on this feature. 4. **Ignoring high-value accounts.** If enterprise customers depend on this, they need personal outreach, not a mass email. Coordinate with their account team. 5.