Prompt and context
This product interview question tests whether you can turn “low usage” into a verifiable product decision. Sunsetting a feature affects user jobs, sales commitments, support workflows, and engineering maintenance, so one usage number is not enough. You need to define the problem, identify affected groups, compare maintenance with migration cost, and design staged validation and exit controls.
What the interviewer is assessing
- Whether you distinguish low-frequency but critical jobs from genuinely low-value functionality.
- Whether you use segments, alternative paths, and customer evidence instead of one universal threshold.
- Whether you can stage discovery, validation, migration, communication, and shutdown.
- Whether you explain customer value, commercial risk, technical cost, and success metrics together.
Clarifying questions to ask
First clarify the denominator and time window behind “3%”: all accounts, active accounts, or accounts eligible for the feature? What are the users’ frequency, task success, renewal status, and contractual commitments? Is the feature used indirectly through an API, export, audit, or support workflow? Is there an equivalent alternative, and what are its completion rate and migration cost? Also clarify version dependencies, regional compliance requirements, customer notice periods, and acceptable shutdown timing.
A 30-second answer framework
I would not decide from 3% alone. I would verify the denominator, user jobs, and revenue or compliance exposure, then segment customers into high-value critical users, low-frequency users with viable alternatives, and ineffective usage. I would compare continued maintenance, limiting new enablement, migration, and full shutdown, then run a reversible migration pilot with a small group and measure task success. I would only phase out the feature after the alternative meets predefined thresholds, critical customers confirm the plan, and support and sales are ready, with explicit recovery and exception paths.
Step-by-step deep dive
1. Translate low usage into user jobs
Segment by account, role, region, plan, contractual commitment, and recency. Observe the jobs, frequency, success rate, and failure reasons. Beyond access logs, inspect API calls, exports, tickets, sales commitments, and compliance records. Low frequency may mean “used only at a critical moment,” or it may mean poor discoverability or a failed experience; those require different product actions.
2. Define the cost and alternative conditions
Build a cost model for continued maintenance, read-only retention, migration, and shutdown. Include engineering maintenance, incident risk, support training, and opportunity cost; compare them with capacity released, complexity reduced, and error paths removed. Set observable thresholds for the alternative, such as task completion, migration success, critical-customer confirmation, support volume, and renewal risk, instead of one global adoption rate.
3. Validate impact with a reversible pilot
Disable entry points first for internal accounts or low-risk customers who opt in. Provide migration tools, exports, and human assistance, then compare task success, completion time, error rate, and help requests. When random assignment is not feasible for enterprise accounts, use before-and-after comparisons and segmented interviews, recording what the evidence cannot establish. The pilot must be pausable and reversible before any broad, irreversible migration.
4. Handle key-customer, contract, and trust risk
Create an exception list for customers with high renewal value, explicit commitments, compliance dependencies, or no viable alternative. Have customer success, sales, support, engineering, and legal agree on notices, migration dates, data retention, and escalation contacts. Do not let a few large customers decide for everyone, and do not force a critical job to close just to improve an average metric. Exceptions need a deadline, cost, and exit condition.
5. Shut down in phases and verify the outcome
Stop enabling the feature for new customers, then give existing customers migration reminders and a read-only window, and finally disable writes and entry points. At every phase watch task completion, migration failures, support tickets, performance, refunds, and renewal signals, with pause thresholds. After launch, check for hidden API calls, abnormal data access, and customer workarounds. Delete code and data only after results are stable, retaining audit records and migration documentation.
Example of a strong answer
Three percent does not prove that the feature has no value. I would verify the denominator and time window, segment by account value, user job, contract commitment, and available alternative, and inspect APIs, tickets, sales promises, and compliance dependencies. I would compare maintenance, read-only retention, migration, and shutdown costs, then set thresholds for task success, migration success, critical-customer confirmation, and support volume. I would run a small reversible pilot with exports, migration tools, and human help, and give high-risk customers time-bounded exceptions with explicit cost and exit conditions. If the pilot passes, I would stop new enablement, offer an existing-customer migration and read-only window, and then phase out access while monitoring failures, tickets, refunds, and renewals. I would remove implementation and data only after the evidence is stable and would retain an audit trail.
Common mistakes
- Treating low usage as low value without checking critical-moment jobs and indirect use.
- Using only averages instead of segmenting by account value, plan, region, role, and contract.
- Announcing shutdown before finding and validating an alternative, shifting migration cost to customers.
- Replacing repeatable behavioral evidence with one interview or one large customer’s request.
- Deleting the feature without migration, read-only, notice, exception, and rollback stages.
- Reporting engineering hours saved while ignoring task failures, support volume, revenue, and trust guardrails.
Follow-up questions and answers
Should a feature used once a year still be sunset?
Not based on frequency alone. Check whether that use supports audit, compliance, disaster recovery, or a high-value business job, and whether the alternative is reliable. On-demand enablement, read-only retention, or low-cost maintenance may be better, but the choice needs task-success and risk evidence.
What if a key customer refuses to migrate?
Determine whether the blocker is a capability gap, migration cost, or contractual commitment. Offer a bounded adaptation, assisted migration, or time-limited compatibility window. Record cost, owner, deadline, and exit condition; do not keep the legacy path indefinitely.
How do you show that shutdown did not harm renewals?
Track migration completion, critical-job success, support tickets, refunds, health scores, and renewals by segment, comparing with similar non-migrated accounts or historical periods. You cannot claim perfect causality, but you can predefine anomaly thresholds and pause actions.
What if engineering wants to delete the code immediately?
Put deletion benefits beside migration, notice, data-retention, and rollback risks in one decision record. If customer or contract risks remain open, stop new enablement or move to read-only first, complete migration validation, and then delete. A deletion date can be clear without skipping exit conditions.