Prompt and scope
A public 2026 product-manager interview guide lists “Tell me about a time you killed a feature or project.” It asks candidates to name the data that changed the decision, the sunk cost, stakeholder impact, and the lesson learned. The goal is not to prove that a feature failed; it is to show that you can move capacity from a low-value path to a more important user outcome. This article covers the decision and story structure, not an automatic shutdown rule based on one metric.
What the interviewer is testing
The interviewer wants to see a user outcome defined before metrics are selected, and a distinction between “nobody discovered it,” “discovery did not lead to value,” and “usage harmed the core experience.” Google's HEART research proposes mapping Goals to Signals and Metrics, then triangulating behavioral and attitudinal evidence. A strong answer states the opportunity cost of more investment, the reversible test used, and the exit condition.
Clarifying questions to ask yourself
- Are you ending exploration, pausing release, or removing an adopted feature? Each lifecycle has different migration and communication risk.
- Which user outcome does the feature serve? If the goal is task completion time, clicks alone can mislead.
- Which users need separate cohorts? New, paid, and high-frequency users may have different adoption and retention.
- Are there legal, contractual, or migration promises? They may require read-only access or a longer notice period.
- Is the evidence correlational or causal? Experiments, control groups, interviews, and tickets support different levels of confidence.
A 30-second answer
“I owned feature X, whose goal was user outcome Y, based on assumption Z. After launch, I segmented adoption, task success, and counter-metrics. The evidence did not support the assumption, and more investment would displace project Q. I ran a reversible pause or rollout test, aligned engineering, support, and affected customers on migration, then stopped the feature and moved capacity to Q. Replace the result with your real metric; my lesson was to define an exit gate during discovery.”
Step-by-step answer
1. Define why continuing could be valuable
Write the goal as a user-visible outcome, such as “a first-time setup completes in one session,” then list observable signals: completion, time to value, repeat use, and support contacts. Google's Goals-Signals-Metrics process warns against using an easy-to-collect page-view count as a substitute for success.
2. Use cohorts and counter-metrics to locate the problem
Compare new and existing users, plan tiers, platforms, and frequency. Low adoption may mean poor discoverability or low importance; high adoption may still coincide with errors, refunds, or support load. Use funnels, retention, and qualitative feedback to distinguish “unused” from “harmful,” and state data coverage and sample limits.
3. Compare three paths and their opportunity cost
Put continued iteration, a learning pause, and shutdown with migration in one decision table. Iteration preserves upside but consumes engineering capacity; a pause tests the key assumption cheaply; shutdown releases capacity but carries migration, contract, and trust costs. You do not need fake precision, but you must state the ranking criteria and irreversible effects.
4. Design the exit and migration
Shutdown is not a delete button. Freeze the entry point for new users, preserve read or export access for existing users, announce the replacement path, and then remove jobs, metrics, and support documentation. Give each step an owner, date, and rollback condition. If the evidence supports only a pause, do not call it a final removal.
Model answer
“I owned a reporting-export feature for small teams. We expected it to reduce support-assisted exports. After launch, I segmented by team size and plan: large accounts adopted it, but small teams rarely completed a first export, and failures increased support tickets. We ran a small experiment with a simpler guide and confirmed the main issue was permission explanation, not missing formats. Completion still missed the pre-agreed threshold after the copy fix, while engineering was preparing a new permission model. I proposed freezing new entry, preserving downloads and data migration for existing reports, notifying affected customers, and moving capacity to a higher-frequency report. Replace the outcome with your real metric. My lesson was to put segmented adoption and support cost into the exit criteria at discovery time.”
Common mistakes
- “Adoption was low, so we deleted it” → no user goal or cohort → state goal, signals, sample, and counter-metrics.
- Use only the average → concentrated risk disappears → segment by lifecycle, plan, and platform and report coverage.
- Call a pause a shutdown → migration responsibility is missing → distinguish experiment, freeze, read-only mode, and removal.
- Let sunk cost justify continuation → past spend does not prove future value → compare remaining spend with the alternative opportunity.
- Invent a percentage → the result fails follow-ups → use a real metric or label a placeholder.
- Ignore counter-metrics → clicks can rise while trust falls → monitor errors, refunds, complaints, or retention.
Follow-ups and extensions
What if a high-value customer still depends on the feature?
Check contract, migration deadline, and replacement first, then calculate the retention cost by customer cohort. Keep read-only or export access, extend notice, and document exceptions; do not hide concentrated risk behind an overall average.
What if the data is not strong enough to support shutdown?
Turn the largest uncertainty into a minimum viable experiment with a pre-set sample, observation window, and stop rule. Freeze nonessential investment while learning so the team does not expand the bet without evidence.
How do you respond when engineering resists after investing heavily?
Acknowledge the completed work, separate reusable assets from unrecoverable cost, and compare future investment, user outcome, and the alternative project. Involve the team in migration and reuse so the decision is not framed as rejecting their work.
What if metrics rebound after shutdown?
Check seasonality, migration failures, and measurement changes before restoring anything. If the user outcome truly worsened, revisit the original exit condition with a small reversible rollout; a rebound is not an automatic return to the old roadmap.