Question and Applicable Scenarios
You manage a B2B analytics SaaS. A legacy scheduled PDF email feature is used monthly by only 3% of active workspaces, but its users include 14 enterprise customers representing 18% of company ARR. Nine of those customers renew within the next six months. The feature depends on an old renderer, costs about three engineer-months per quarter to maintain, and generates 22% of reporting-related support tickets.
The company has launched dashboard subscriptions that cover roughly 80% of the legacy workflows, but they do not yet support custom branding or attachment delivery. Decide whether to maintain, reinvest in, stop expanding, or ultimately sunset the legacy feature. Explain the data you would validate, the migration plan, communication cadence, success measures, and pause conditions.
All numbers are interview assumptions, not industry benchmarks. A 3% usage rate does not prove that the feature should be removed, and 18% of ARR does not prove that it should be kept forever. The candidate must uncover the dependency hidden behind low adoption, compare the full cost of retention and migration, and turn an irreversible deletion into a sequence of decisions that can be tested and paused.
Product manager question banks in 2026 still ask candidates which product they would improve and which they would cancel. A separate PM interview rubric explicitly asks how a candidate used data to sunset a feature, distinguished low use from value to a small segment, handled resistance, and minimized disruption. This is a product question because it tests portfolio trade-offs, customer segmentation, lifecycle decisions, and cross-functional execution.
What Interviewers Evaluate
First, does the candidate validate the data definition? A strong answer asks whether the 3% denominator includes all active workspaces, only workspaces entitled to the feature, or only those that completed setup. It also checks whether API calls, administrator-triggered sends, or scheduled jobs bypass the measured UI path. A bad denominator or missing telemetry invalidates the conclusion.
Second, can the candidate separate adoption from dependency value? A compliance report sent once a month may have low frequency but remain essential to an audit or board process. Segmentation should account for workflow criticality, switching difficulty, account value, contractual commitments, and renewal timing rather than average event counts alone.
Third, does the candidate compare real options? The answer should include more than keep or delete:
- maintain the current feature;
- repair or rebuild it;
- place it in maintenance mode, stopping new adoption while supporting existing dependents;
- bridge replacement gaps during migration;
- retire it in stages, with time-limited exceptions for a small set of customers.
Fourth, does the candidate treat migration as a product delivery? Publishing a date does not complete a migration. A strong answer defines replacement gaps, account owners, data export, migration tooling, acknowledgment of notices, support paths, cohort shutdowns, and rollback gates.
Fifth, can the candidate resolve tension between revenue and product integrity? Fourteen customers represent 18% of ARR, so an immediate hard shutdown is risky. The feature also consumes about 12 engineer-months each year and prevents the reporting stack from converging. The candidate needs a present recommendation and evidence that would change it, rather than ending with “the customers matter” or “the technical debt is too high.”
Clarifying Questions Before Answering
- Is the 3% denominator and telemetry trustworthy? If it measures only UI clicks and misses schedules, APIs,
or administrator configuration, fix the data before deciding.
- What job do customers complete with the feature? Compliance archives, external client delivery, internal
weekly reports, and occasional trials have very different interruption costs.
- How deeply do the 14 enterprise customers depend on it? Separate sustained users, occasional users, and
customers who can migrate but have not acted.
- Is the 18% ARR correlated or attributable? Using a feature does not mean that the full contract value depends
on it. Validate cancellation intent, renewal risk, and contractual promises.
- What is inside the missing 20%? If branding and attachments are contractual blockers, 80% coverage does not
justify retirement. A narrow migration bridge could change the decision.
- What is the full cost of the legacy feature? Beyond 12 engineer-months per year, include incidents, support,
security, accessibility, infrastructure, and roadmap opportunity cost.
- Is there a security, compliance, or data-integrity risk? Severe risk may justify an accelerated shutdown.
Ordinary maintenance cost does not justify skipping reasonable notice and migration.
- What constraints exist in contracts and customer notices? Renewals, service terms, and procurement promises
determine announcement timing, exceptions, and the final shutdown sequence.
30-Second Answer Framework
“I would not remove the feature based on 3% usage alone because the user set includes enterprise accounts representing 18% of ARR, and the replacement has material gaps. I would validate telemetry and the eligible denominator, then segment the 14 customers by workflow criticality, switching effort, contracts, and renewal risk.
Given the current facts, I would immediately stop selling and enabling the legacy feature for new customers and put it into maintenance mode. In parallel, I would run roughly a four-week dependency audit and migration pilot to determine whether branding and attachment gaps can be closed. I would announce a final date only after the replacement passes critical workflows, export, reliability, and contract reviews, and high-dependency customers meet predefined migration gates.
The nine near-term renewals would receive individual plans, and migrations would proceed by cohort with pause conditions. If critical gaps cannot be closed economically, or expected churn and migration cost exceed the maintenance and opportunity cost we can release, I would retain a constrained version or revisit a rebuild instead of forcing the original date.”
Step-by-Step Deep Dive
Step 1: Turn “low usage” into a verified dependency map.
Build an account-level inventory instead of relying on one aggregate dashboard:
| Dimension | Question to answer | Decision impact |
|---|---|---|
| Eligible denominator | How many workspaces are entitled and configured | Corrects whether 3% is artificially diluted |
| Usage depth | Schedules, successful sends, recipients, and sustained months | Separates trials from real dependency |
| Workflow criticality | Does failure cause inconvenience, lost revenue, or compliance failure | Sets migration priority and notice |
| Replacement difficulty | Can subscriptions, manual work, or another tool complete the job | Estimates migration cost |
| Commercial exposure | ARR, renewals, contract terms, and cancellation intent | Estimates real revenue risk |
| Product cost | Maintenance, support, incidents, security, and roadmap blockage | Estimates the full cost of retention |
Interview non-adopters as well. Determine whether they lack the need, cannot discover the feature, fail during setup, or find the experience inadequate. If low adoption comes from fixable discoverability or reliability while the underlying need remains broad, reinvestment may be more rational than retirement.
Step 2: Define hard gates before comparing options.
The final shutdown should not proceed until:
- usage data covers every meaningful trigger path and has no known material gaps;
- contracts, legal obligations, compliance, and data-retention requirements have been reviewed;
- critical dependent workflows have an acceptable replacement or a customer-approved migration path;
- customers can export required historical data, and the team has rehearsed export and recovery;
- replacement reliability, permissions, accessibility, and support are production-ready;
- every affected enterprise account has an owner, status, and escalation route.
Security, critical reliability, or data-integrity problems can shorten the timeline, but the company still needs to explain the reason and provide a migration path. Some public API policies specify formal notice periods. For example, Atlassian's general rule for publicly accessible cloud REST APIs keeps the original form available for at least six months, with exceptions for critical security, reliability, and data-integrity issues. That is a specific policy example, not a universal deadline for every product feature.
Step 3: Compare maintenance, reinvestment, maintenance mode, and retirement.
| Option | Appropriate when | Main cost |
|---|---|---|
| Continue maintenance | The workflow is critical, alternatives fail, and revenue risk exceeds retention cost | Technical debt, support, and opportunity cost persist |
| Rebuild | The user problem matters broadly but the legacy implementation suppresses adoption | New work may duplicate the replacement reporting stack |
| Maintenance mode | Existing customers depend on it, but adoption should stop expanding | Requires an explicit support horizon to avoid permanent delay |
| Migrate then retire | The replacement is reliable, gaps are bridgeable, and long-term value is clear | Migration tools, communication, and temporary dual operation |
| Time-limited exception | A few valuable customers face contractual or critical blockers | Can create a lasting fork without an owner and end condition |
AWS's published lifecycle language is useful here: maintenance stops onboarding and enhancement while existing users remain supported; sunset asks existing users to migrate and has an end date; full shutdown removes service and support. Using stages prevents the interview answer from collapsing deprecation and immediate deletion into one action.
Under the current assumptions, the recommendation is maintenance mode followed by a migration-gated sunset. The 3% aggregate adoption and roughly 12 engineer-months of yearly maintenance support reducing long-term investment, while 18% ARR, nine near-term renewals, and a 20% capability gap make immediate shutdown unacceptable.
Step 4: Validate the recommendation with reversible actions.
Before announcing a final date:
- stop enabling the feature for new customers and remove it from sales promises;
- review workflows with all 14 enterprise customers, marking branding, attachment, retention, and permission gaps;
- pilot migration with customers at different dependency levels, including setup, historical export, delivery,
and support;
- write migration gates and pause conditions before execution so the deadline cannot override failure evidence.
The pilot must test the same end-to-end job: successful delivery, recipient experience, attachment and branding correctness, permissions, audit records, retry behavior, support volume, and completion time. A replacement proven only on simple customers does not validate the 80% coverage claim.
Step 5: Give each segment a different migration path.
Use four account groups:
- no meaningful current use: hide the feature while retaining notice and export access;
- low dependency with complete replacement: offer self-service migration and reminders;
- high dependency with bridgeable gaps: provide product and customer-success assistance;
- blocked by contracts or critical gaps: grant a time-limited exception with a gap, renewal, or exit decision date.
The notice should state what is changing, why, the last available date, alternatives, migration steps, data access, and support channels. High-value customers should not receive only a broadcast email. An owner confirms that each customer understands the impact and records acceptance of the migration plan. If the feature includes APIs or automation, responses, changelogs, and developer documentation should also make deprecation and sunset detectable.
Step 6: Use stage gates and pause conditions.
One workable sequence is:
| Stage | Action | Evidence required to advance |
|---|---|---|
| Maintenance mode | Stop new adoption, fix data, build account inventory | Dependents and contract scope are known |
| Migration preparation | Close critical gaps and rehearse export and support | Replacement passes critical workflows |
| Small cohorts | Migrate low-risk and willing customers | Tasks succeed and guardrails remain healthy |
| Enterprise migration | Handle high-dependency customers and renewals individually | Affected accounts meet team-defined gates |
| Final shutdown | Disable legacy entry points, jobs, and infrastructure | No unresolved contract or data blockers |
| Cleanup and review | Remove code, docs, sales material, alerts, and data copies | Product and operational boundaries converge |
Pause if a critical workflow fails, exports are incomplete, replacement reliability is inadequate, support load substantially exceeds plan, cancellation intent crosses the predefined risk boundary, or legal and compliance issues remain unresolved. A pause should trigger a new choice among closing gaps, extending one cohort, granting a time-limited exception, or changing the recommendation. It should not silently become permanent retention.
Step 7: Compare full economics.
Retention includes roughly 12 engineer-months per year, 22% of reporting-related support tickets, infrastructure and incident exposure from the legacy renderer, and the opportunity cost of not moving engineers to the new reporting stack. Retirement includes replacement development, migration tools, customer-success and support work, temporary dual operation, and possible discounts, churn, or contractual compensation.
Do not record all 18% of ARR as “retirement loss.” Estimate which customers would cancel because of unresolved gaps, which would migrate, and which need only assistance. Do not record all 12 engineer-months as “retirement savings,” because the replacement also needs maintenance. Compare scenario ranges:
- can critical gaps be closed at reasonable cost;
- how much associated revenue is genuinely at risk;
- how long dual operation will last;
- what higher-value work will use the released capacity;
- whether exceptions prevent the legacy cost from declining.
Step 8: Measure migration outcomes, not the shutdown date.
The primary measure should be completion of dependent workflows, not delivery of notices. Track:
- migration completion for genuinely dependent accounts and scheduled jobs;
- delivery success and critical task completion on the replacement;
- remaining active legacy use and unacknowledged accounts;
- reporting support tickets, migration requests, and escalations;
- renewal, cancellation intent, and contract risk for affected customers;
- historical export success and completion of data-retention work;
- legacy incidents, maintenance effort, and engineering capacity actually released.
After shutdown, remove background jobs, entry points, permissions, feature flags, documentation, sales promises, support playbooks, monitoring alerts, and unnecessary data copies. Handle historical data according to the agreed retention policy. Hiding a button while keeping every operational responsibility does not capture the main value of retirement.
High-Quality Example Answer
“I would first challenge the 3% number. The denominator should be workspaces that are entitled and have the relevant reporting need, and I would verify that scheduled jobs and API triggers outside the UI are included. I would then segment the 14 enterprise customers by workflow criticality, switching difficulty, contractual commitments, and renewal timing. A compliance report used once a month can be infrequent but essential.
I would not shut the feature down immediately. It consumes three engineer-months per quarter and generates 22% of reporting-related support tickets, so retaining it has a material long-term cost. Its users also represent 18% of ARR, nine renew soon, and the replacement lacks branding and attachment delivery. My recommendation is to put it into maintenance mode: stop new enablement and sales promises, fix only serious issues, and begin a dependency audit and migration pilot.
I would determine whether branding and attachments are contractual or critical workflow requirements, then migrate customers at different dependency levels. The pilot must verify delivery, permissions, auditability, failure recovery, historical export, and support operations rather than compare feature checklists. Each enterprise account receives an owner, with individual plans for near-term renewals.
I would announce a final date only after the replacement passes critical workflows, contract and compliance review is complete, data can be exported, and high-dependency customers meet predefined migration gates. I would migrate low-risk cohorts first and pause the next cohort if critical tasks fail, exports are incomplete, reliability is inadequate, or cancellation risk becomes unacceptable.
Economically, I would compare 12 engineer-months of annual maintenance, support, incidents, and roadmap opportunity cost with replacement gaps, migration, dual operation, and likely churn. All 18% of ARR will not necessarily disappear, and all 12 engineer-months will not become net savings, so I would update the recommendation using ranges and customer evidence.
If the critical gaps can be bridged economically, I would complete a staged sunset. If they are irreplaceable contractual requirements, or expected migration losses remain greater than the value released, I would retain a constrained version or revisit a rebuild. After shutdown, I would remove jobs, code, documentation, sales material, alerts, and data responsibilities so the team actually exits the legacy stack.”
Common Mistakes
- Remove it after seeing 3% usage → the denominator, frequency, or workflow criticality may be wrong →
validate data and segment by dependency first.
- Keep it forever after seeing 18% ARR → associated revenue is not attributable revenue, while technical and
opportunity costs continue → validate real cancellation risk and compare full economics.
- Treat 80% coverage as migration readiness → the missing 20% may contain contractual or compliance blockers →
validate workflows individually instead of counting features.
- Offer only keep or delete → maintenance mode, migration bridges, and time-limited exceptions disappear →
break an irreversible deletion into staged decisions.
- Announce the date before designing the replacement → the deadline can override evidence of failure →
define gates, pilots, and pause conditions first.
- Send every customer the same email → high-dependency enterprise accounts need confirmed impact, ownership,
and escalation → segment communication by dependency and commercial exposure.
- Measure success by notice delivery → customers may receive the message without completing migration →
measure workflow migration, task success, and guardrails.
- Stop after hiding the UI → jobs, code, data, docs, and sales promises still create responsibility →
complete lifecycle cleanup and review.
Follow-Up Questions and Responses
Follow-up 1: The largest customer says it will cancel if the feature is removed. What do you do?
Determine whether this is a confirmed cancellation condition, a negotiating position, or concern about migration risk. Isolate the irreplaceable workflow, contract language, and revenue exposure, then compare closing the gap, providing migration service, granting a time-limited exception, or retaining a constrained version. One large customer can change timing, but it should not automatically receive an indefinite exception. Any exception needs pricing, a support boundary, an owner, and an end condition.
Follow-up 2: The legacy renderer has a critical security vulnerability. Can you keep the original schedule?
Do not follow the original timeline mechanically. Security leadership should determine whether the risk can be isolated, patched, or exposure can be restricted. If it remains unacceptable, stop new jobs, narrow availability, or accelerate shutdown. Still provide export, an alternative workflow, and a clear explanation of why notice was shortened. Urgent risk changes the schedule; it does not eliminate the responsibility to migrate customers.
Follow-up 3: The replacement will never cover more than 80%. Should you abandon the sunset?
Map the gap to genuinely dependent workflows and ask whether the bridge would create another legacy system. If branding and attachments can be handled by a narrow migration layer, retirement can continue. If the gap contains irreplaceable compliance or core delivery requirements, shift toward a constrained legacy version, a rebuild of the critical capability, or another replacement. The percentage alone cannot decide.
Follow-up 4: Usage data is unreliable, but engineering urgently wants to delete the old code. How do you proceed?
Stop expanding adoption, then reconcile logs, schedules, API calls, support records, customer-success knowledge, and billing accounts. A reversible hide or migration pilot can run on low-risk accounts, but permanent deletion is unsafe while dependency is unknown. If a reliable inventory cannot be built quickly, treat data uncertainty as a blocker rather than interpreting “usage not observed” as “nobody uses it.”
Follow-up 5: Two customers demand permanent access. Should you create a dedicated version?
Compare the revenue with the lasting fork cost, including security fixes, infrastructure, on-call ownership, testing, and staff knowledge. Prefer the standard replacement, paid migration, or a time-limited exception. A long-lived dedicated version is reasonable only if contract value and strategic importance sustainably cover its operating responsibility and the company accepts it as a formal product commitment. A temporary exception should not quietly become an indefinite legacy system.