Retirement Risk Assessor

Product managers often know a feature is deprecated in documentation or roadmap notes, yet still lack a clear picture of who would feel the removal. Support volume, revenue attribution, and segment mix live in different systems. Without a joined view, retirement decisions swing between gut feel and endless spreadsheet work.

The Retirement Risk Assessor uses an LLM to cross-reference a named deprecated feature with support tickets, revenue data, and user segments, then produce a structured risk score and rationale. The score is decision support, not an automatic kill switch. The PM still chooses whether to retire, delay, migrate, or keep the surface alive under tighter constraints.

The assessor is most useful when a feature is already marked for sunset, or when engineering has flagged it as costly to maintain, and someone needs an evidence-backed risk profile before committing to a date. It does not replace product judgment, customer communication plans, or engineering estimates. It compresses the first pass of evidence gathering so the human debate starts from shared facts.

Three input classes are required. If any class is missing, the assessor returns empty output rather than a partial score that looks authoritative.

Support tickets. Ticket text, titles, tags, product areas, and timestamps tied to the feature (or to workflows that depend on it). The model looks for volume trends, severity language, workarounds, and whether complaints come from power users or one-off reports. Ticket IDs and links should be preserved so a PM can spot-check the evidence.

Revenue data. Attribution that connects the feature to paid usage, plan tiers, expansion, churn risk, or contract commitments. Exact schema varies by company. What matters is a traceable link from the feature to money or retention signals the business already trusts. Without that link, a low support volume can hide a high-stakes customer.

User segments. Cohorts that matter for the retirement call: enterprise vs. self-serve, geography, industry, usage intensity, or account tier. Segment labels should match how the PM already talks about customers. The model uses segments to show concentration risk (for example, most remaining usage in a small set of strategic accounts) rather than a single blended average.

The feature identifier itself must be unambiguous: a stable name, ID, or flag that appears consistently across tickets, analytics, and billing. Ambiguous aliases produce noisy joins. When aliases exist, resolve them upstream or pass an explicit alias list with the request.

Optional context helps quality without replacing the three required classes: deprecation notes, prior migration offers, dependency maps, and known contractual SLAs. Those enrich the rationale. They do not unlock scoring if tickets, revenue, or segments are absent.

The model joins the three required inputs around the feature identifier, then summarizes risk along dimensions a PM can review:

• Usage and attachment: How many accounts or users still touch the feature, and how concentrated that usage is.
• Support burden and sentiment: Ticket rate, unresolved themes, and whether users treat the feature as broken, confusing, or business-critical.
• Revenue exposure: Share of revenue, pipeline, or retention risk tied to remaining users.
• Segment sensitivity: Whether exposed users sit in high-touch, high-ARR, or regulated cohorts where a surprise removal is costly.
• Migration readiness signals: Mentions of alternatives, workarounds, or prior communication in tickets (when present). Absence of migration language is itself a risk flag, not proof that no path exists.

Scores should be ordinal and explainable (for example, low / medium / high, or a bounded numeric band) with a short rationale that cites concrete evidence: ticket themes, revenue share by segment, and which cohorts dominate residual usage. Prefer citations the PM can open over abstract confidence language.

The assessor should separate evidence from inference. Evidence is what appears in the inputs. Inference is the model’s interpretation (for example, inferring churn risk from ticket tone). Label inferences clearly so a PM can accept or discard them.

Do not invent metrics that were not in the inputs. If revenue arrives as plan-tier counts without dollar amounts, report plan-tier exposure, not fabricated ARR. If tickets lack severity fields, describe themes from text without pretending severity was structured.

Human-in-the-loop is mandatory. The model scores risk; the PM decides the retirement action.

Typical decisions after a score:

1. Proceed to retire with a date, communication plan, and migration path when risk is acceptable and alternatives are ready.
2. Delay when strategic segments remain exposed or contracts block removal.
3. Narrow the retirement (limit to new accounts, hide from UI, keep API for a grace period) when risk is uneven across segments.
4. Invest to keep when revenue or segment exposure outweighs maintenance cost, and update the deprecation status accordingly.

The assessor should make those options easier to discuss by attaching the same evidence pack to every meeting: who is affected, how much money or retention risk is in play, and what support themes will amplify backlash. It should not auto-schedule sunsets, email customers, or flip feature flags.

Review practice that works well: the PM (or a small product + support + CS triad) reads the rationale, opens a sample of cited tickets, validates revenue joins against the source system, then records the decision and owners outside the model. Treat the score as a briefing memo, not a verdict.

Return empty output when any of the three required inputs is missing or unusable:

• No support tickets (or an empty ticket set after filtering to the feature).
• No revenue data linked to the feature.
• No user segment data for remaining users.

Empty means no score, no partial band, and no “low confidence” placeholder that still looks like a recommendation. A short machine-readable reason is fine (for example, missing_revenue_data) so callers can fix the pipeline. Do not fill gaps with industry averages or prior features’ patterns.

Also prefer empty or an explicit incomplete status when joins fail: tickets exist but none map to the feature ID; revenue exists for the product but not the surface under review; segments exist for the account base but not for users of this feature. A wrong join is worse than no score.

Partial enrichment is allowed only after all three classes are present. Extra context can be sparse. Core inputs cannot.

Retirement risk scoring sits next to technical cleanup, not instead of it. After a PM accepts retirement (or while preparing for it), engineering still needs to remove dead paths and unused dependencies safely.

See also:

• Codebase Cleanup Agent for coordinated removal work once the product decision is set.
• Dead Code Detector for finding unreachable or unused implementation after the feature is off for new use.
• Dependency Usage Analyzer for checking whether libraries or services exist only for the retiring surface.

Use the assessor first when the open question is “can we retire this without unacceptable customer or revenue damage?” Use the cleanup tools when the open question is “what code and dependencies can we safely remove after that decision?” Keeping those jobs separate prevents a high risk score from being ignored because the codebase looks tidy, and prevents aggressive deletion when product risk is still unresolved.