Product Demise/Sunsetting AI Prompts for PMs

Product managers are hired to build things. No one gets promoted for retiring something. Yet product retirement is one of the most important — and most poorly executed — responsibilities in product management. Products that should have died years ago consume resources, confuse customers, and拖慢 teams. Products that are killed badly damage customer relationships and tarnish brand reputation.

The difficulty is not technical. The difficulty is emotional and political. There are always reasons to keep a product running: existing customers, revenue, the sunk cost of past investment. The PM’s job is to see clearly when a product should die and have the courage to recommend it.

AI Unpacker provides prompts designed to help product managers navigate the sunsetting process with empathy, rigor, and strategic clarity.

TL;DR

• Products rarely die at the right time. They die either too early or too late.
• The right time to sunset is when the cost of maintenance exceeds the value of keeping it.
• Customer communication is more important than the technical decommission.
• A graceful exit preserves relationships and brand. A rushed exit burns bridges.
• The PM’s job is to make the recommendation. Leadership makes the decision.
• Post-mortems on sunset decisions improve future decision-making.

Introduction

Every product has a lifecycle. It launches, grows, matures, and eventually declines. At some point, the cost of maintaining it exceeds the value it provides. At that point, the rational decision is to retire it.

The problem is that products are not just line items in a portfolio. They have customers, employees who are proud of them, and relationships that extend beyond the product itself. When a PM recommends sunsetting, they are often fighting against organizational inertia, sunk cost bias, and the legitimate concerns of customers who have built workflows around the product.

1. Sunset Timing Assessment

The hardest part of sunsetting is knowing when to do it. Too early and you disrupt customers unnecessarily. Too late and you consume resources that could be better deployed elsewhere.

Prompt for Sunset Timing Evaluation

Evaluate the timing for retiring this product feature.

Feature: Legacy reporting module
Product context: Built 8 years ago, standalone reporting tool that predates current platform
Current metrics:
- Monthly active users: 45 (down from 800 at peak)
- Revenue: $120K ARR (2% of company total)
- Support tickets: 12 per month (highest per-user of any feature)
- Engineering maintenance: 1.5 FTE dedicated, 2 FTE shared
- Last significant update: 18 months ago

What I know about the situation:
- A new reporting module launched 6 months ago (replacement product)
- New module has 200+ MAU, growing 15% month-over-month
- Engineering says new module will match legacy functionality within 2 quarters
- 45 legacy users are enterprise customers with multi-year contracts
- Some legacy users have not logged in for 6+ months

Why sunset now:
- Maintenance cost ($350K annually in engineering) exceeds revenue
- 15 of 45 users have migrated to new module
- Continued maintenance slows new product development

Why not sunset:
- Enterprise contracts mean some customers cannot migrate before contract ends
- 10 customers are on 2-year contracts
- Losing these customers could affect renewal negotiations
- Some customers have custom configurations that do not map to new module

Tasks:
1. Assess whether timing is right based on metrics
2. Identify who owns the decision and what factors they will weight
3. Determine what data would change the recommendation
4. Identify the minimum viable sunset period for affected customers

Generate sunset timing recommendation with supporting analysis.

2. Stakeholder Communication Strategy

Sunsetting requires communicating with multiple stakeholder groups, each with different concerns. The communication must be honest, empathetic, and clear about timelines.

Prompt for Sunset Communication Planning

Develop a communication strategy for this product sunset.

Product: Legacy reporting module
Decision: Sunsetting in 12 months
Affected stakeholders:
1. Current customers (45 accounts, mixed enterprise and SMB)
2. Sales team (they sold these contracts, some within last 6 months)
3. Support team (they handle escalations from these customers)
4. Marketing team (they manage customer communications)
5. Executives (they need narrative for board/investors)

Customer segments:
- Enterprise customers (10): 2-year contracts, dedicated CSMs, high-touch
- Mid-market customers (20): Annual contracts, self-serve, moderate-touch
- SMB customers (15): Monthly contracts, no CSM, low-touch

What customers are likely to feel:
- Anger (they trusted us and we are discontinuing)
- Anxiety (what happens to their data/reports?)
- Betrayal (especially recent purchasers)

What sales is likely to feel:
- Embarrassment (they sold something that is dying)
- Concern (will this affect renewals on healthy products?)
- Frustration (why was this decision made without consulting them?)

What leadership needs to communicate:
- Strategic rationale (why now?)
- Customer impact (what happens to affected customers?)
- Timeline (what are the milestones?)
- Resources (what are we investing in migration support?)

Communication requirements:
1. Message framework for each stakeholder group
2. Timeline for when each group learns about the decision
3. Channels (email, call, in-app notification, etc.)
4. FAQ preparation (what questions will each group ask?)

Generate complete communication strategy with message frameworks.

3. Migration Path Development

A sunset without a migration path is an abandonment. Customers need a clear way to move to something else. The better the migration path, the less damage to customer relationships.

Prompt for Migration Path Design

Design a migration path for legacy reporting customers.

Legacy product: Legacy reporting module (see previous context)
Replacement product: New reporting module (launched 6 months ago)

Migration challenges:
- New module does not yet have all legacy functionality
- 10 enterprise customers have custom report configurations
- Data export is possible but needs customer effort
- Some historical reports depend on data that will not transfer

Current new module capabilities:
- Standard report builder: Fully featured, considered upgrade by most users
- Custom report configurations: Migration tools available but require manual setup
- Scheduled reports: Available in new module
- Data exports: Available in both formats
- Missing: Some advanced filtering options used by 8 enterprise customers

What I need to decide:
1. How long to give customers to migrate (minimum viable migration window)?
2. What migration support to offer (free migration services? dedicated support?)
3. What happens to data after sunset (export? access period? deletion?)
4. Whether to offer refunds, credits, or discounts on new product?

Migration support options:
- Self-serve migration (documented, free, customer does the work)
- Assisted migration (we help, limited capacity)
- White-glove migration (dedicated support for enterprise, premium support)
- Exit option (refund unused portion, no migration support)

Enterprise customer concerns:
- Contract A: 18 months remaining, $60K contract, custom configs
- Contract B: 6 months remaining, $25K contract, standard configs
- Contract C: 12 months remaining, $35K contract, custom configs

Tasks:
1. Design tiered migration paths by customer segment
2. Determine what support resources are needed
3. Create timeline that balances customer needs with business needs
4. Develop migration incentives/discounts if applicable

Generate migration path with tiered approach and resource requirements.

4. Post-Sunset Review Framework

Sunsetting a product teaches you things about your business. The lessons are valuable only if you capture them. A post-mortem turns a painful experience into organizational learning.

Prompt for Sunset Retrospective Design

Design a retrospective framework for this product sunset.

Product: Legacy reporting module
Sunset completed: 6 months ago
Timeline: 12-month sunset period, now complete

What happened:
- 40 of 45 customers successfully migrated
- 5 customers churned (2 enterprise, 3 mid-market)
- Migration took average of 4 weeks per customer
- Engineering spent 600 hours on migration support
- NPS for affected customers dropped 15 points during transition
- NPS has recovered to pre-announcement levels now

What I want to learn:
1. Did we sunset at the right time?
2. Was our migration support adequate?
3. What could we have done differently?
4. What did we learn that applies to future sunset decisions?

Retrospective structure:
1. Outcome analysis (what happened vs. what we planned?)
2. Process review (what worked in the sunset process vs. what did not?)
3. Stakeholder impact (how did different groups experience the sunset?)
4. Future application (what would we do differently next time?)

Tasks:
1. Design questions for each retrospective section
2. Identify data sources for each question
3. Determine who should participate in retrospective
4. Create actionable output format

Generate complete retrospective framework.

FAQ

How do I handle customers who refuse to migrate?

First, understand why. Is it technical (they cannot migrate without significant effort)? Financial (they feel they should not pay twice)? Emotional (they are attached to the product)? Address the specific objection. If none of that works, consider whether an exception to the sunset timeline is warranted for specific customers. One or two exceptions will not hurt you. Allowing all customers to indefinitely delay will.

What if leadership disagrees with my sunset recommendation?

Make sure your recommendation is based on data and clear reasoning, not just frustration with maintaining the product. Present the case: the cost of maintenance, the trajectory of usage, the opportunity cost of resources. If leadership still disagrees, ask them to specify what evidence would change their mind and set a date to revisit. Sometimes you need more time to build the case. Sometimes you are wrong.

How do I prevent this from happening again?

The lessons from sunset retrospectives should inform product planning processes. Build sunset criteria into your product strategy framework. When a product is launched, define the conditions under which it will be evaluated for retirement. This makes future sunset decisions less political and more systematic.

Conclusion

Product sunsetting is an act of discipline. It requires seeing clearly when something is past its useful life and having the organizational courage to act on that insight. It is also an act of respect — for your customers, your team, and your company’s resources.

AI Unpacker gives you prompts to navigate the sunset process systematically. But the judgment about when a product has reached its end, and the courage to recommend what others may not want to hear — those come from you.

The goal is not to avoid difficult decisions. The goal is to make them well.