Every PM will face this question in an interview or a roadmap review. A feature is limping along with thin usage. Engineer hours are draining into a product line nobody uses. Do you keep it alive, or do you pull the plug?
Most candidates panic on this question. They default to saving the product because killing things feels like failure. Hiring managers see through the hedge. The best PMs treat sunset calls as portfolio hygiene. This post gives you a framework, a decision sequence, and the exact language to use when an interviewer asks about retirement.
Why sunsets are a PM skill
Shipping gets the attention. Retiring gets the respect. Marty Cagan writes that strong product teams prune live features because every one of them carries a hidden cost (Cagan). That cost shows up in support tickets, bug fixes, onboarding confusion, and the mental overhead of every engineer who touches the codebase.
When you keep a zombie product running, you pay the cost with resources that could fund your next win. An interviewer asking about sunsets wants to see if you grasp the tradeoff.
The FADE framework for sunset decisions
I use FADE to evaluate a feature or product for retirement. Four letters, four questions, one answer.
F stands for Footprint. How many users depend on the product in real terms? Not signups or page views. Daily or weekly active users who would notice the shutdown.
A stands for Alignment. Does the product still match the company's current direction? A tool built for your old ICP may be dead weight after a pivot in strategy.
D stands for Drag. What is the ongoing cost of running the product? Count engineering hours, support load, infrastructure spend, and the compliance burden.
E stands for Economics. Revenue minus drag, plus the strategic value of active learning. If the net is negative and the learning has plateaued, you have your answer.
Run every candidate through FADE before you recommend action. If two or more letters come back weak, start planning the exit.
A real example from my own work
I ship iOS apps as a solo developer. One of my early apps had a small but loyal user base. Weekly actives stayed flat for nine months. Support emails ate a full weekend every release cycle.
So I ran FADE on the app. Footprint came back as a rounding error. Alignment was gone because my focus had shifted to PM tools and career content. Drag was heavy for one person. Economics turned negative once I counted my own hours at any reasonable rate per hour.
So I retired the app. The relief freed up time for Website Auditor and my blog content. My takeaway for interviews is a simple rule. Any product that drains more than it returns is blocking your next launch.
The four-stage sunset playbook
Once you decide to retire something, execution matters as much as the decision. Botch the wind-down and you lose trust with the users who stayed loyal. Here is my recommended playbook.
Stage one: confirm the data. Pull cohort retention, revenue per user, support ticket volume, and engineering hours for the product over the last two quarters. Lenny Rachitsky notes that most sunset debates die on the first honest look at the numbers (Rachitsky). Do the work before you open your mouth in a roadmap meeting.
Stage two: line up stakeholders. Loop in engineering, support, sales, and legal before any external announcement. Each group gets a checklist. Engineering needs a deprecation timeline. Support needs a comms script. Sales needs to halt new deals on the product today. Legal needs to review data retention and contract obligations.
Stage three: communicate with users. Give users enough runway for migration. The exact window depends on contract terms and user sophistication, but 90 days is a common floor for paid products. Explain the reason in plain language. Offer a migration path or a partner product as an alternative. Refund prepaid time if you made the promise.
Stage four: execute cleanly. Turn off new signups on the first day of the announcement. Stop billing existing users on the announced date. Shut down the service after the migration window. Archive the code, export user data if required, and write a short internal post-mortem. Store the learnings somewhere your next PM can find the notes.
What interviewers listen for
When an interviewer asks about a sunset decision, they are running four tests. The first test is whether you can make a hard call with data rather than feelings. Second, they want to see if you think about ripple effects like team morale and customer trust. Third, they check whether you grasp the opportunity cost of keeping zombies alive in the portfolio. Fourth, they listen for clear communication about how you would tell affected users.
A strong answer walks through FADE, picks a specific product or feature, lands on a recommendation, and describes the wind-down plan. Weak answers hedge, refuse to kill anything, or kill the product without a user migration plan.
Common mistakes to avoid in interviews
Candidates fall into predictable traps on sunset questions. I see these every week in mock interviews with my coaching clients.
Mistake one is treating every feature as sacred ground. If you cannot name three things you would kill on the product you last shipped, you are not a PM. You are a cheerleader.
Mistake two is killing products based on feelings rather than data points. The interviewer will ask about your metrics. Have real numbers on hand.
Mistake three is forgetting the users. Any sunset that strands loyal customers is worse than keeping the product. Your answer needs a migration plan.
Mistake four is ignoring the team. Engineers who built the product deserve a clear explanation and a path to the next project. Jeff Gothelf argues that how you handle a shutdown sets the tone for future risk-taking on the team (Gothelf).
A sample interview answer
Here is how I coach candidates on the classic prompt about killing a feature. Start with context in two sentences. Name the product, the user base, and the reason you were evaluating the feature. Next, walk through your FADE analysis with specific numbers. State your recommendation in one sentence. Finally, describe the wind-down plan with a timeline.
Total length should run three to four minutes. Any longer and you lose the room. Speak shorter and you sound shallow on substance.
Putting FADE into practice this week
Pick a product you use every day. Run FADE on the product from the outside. Where would you guess the owners sit on Footprint, Alignment, Drag, and Economics? What would you recommend if you owned the roadmap?
Do this drill five times before your next interview. The muscle memory will show up under pressure.
Sunset decisions separate PMs who think like owners from PMs who think like fans. Start building the muscle today.
Works cited
Cagan, Marty. "The Product Manager Job Description." Silicon Valley Product Group, www.svpg.com/the-product-manager-job-description.
Gothelf, Jeff. "Jeff Gothelf Blog." jeffgothelf.com, jeffgothelf.com/blog.
Rachitsky, Lenny. "How to Kill a Project." Lenny's Newsletter, www.lennysnewsletter.com/p/how-to-kill-a-project.