Feature Kill Checklist

Review a Promise, Not a Screen

A feature can be quiet and still be essential. A tax export may be opened only four times a year; that frequency says nothing about its value. Another feature may attract daily clicks because users cannot understand it. Usage begins the review, but it cannot decide the case alone.

Use this checklist when a feature complicates onboarding, support, releases, positioning, permissions, or the founder’s attention. The aim is to decide whether the feature still earns every promise attached to it—and, if it does not, to end those promises deliberately.

Do not begin with the code you hope to delete. Begin with the outcome users believe the product provides.

FEATURE UNDER REVIEW

Feature and promised outcome:
Target segment and natural frequency of the job:
Reason for reviewing it now:
Decision date:
Evidence window:

The evidence window should match the job. A week may reveal the fate of a daily workflow and completely miss an annual one. Past build effort is not evidence; neither is the founder’s fatigue. Fatigue belongs under burden, where it can be judged beside value and dependency.

Pass Through Five Gates

Answer the gates in order. Use account names or identifiable segments in the private working record rather than hiding dependence inside aggregate counts.

1. Usage: what valuable work actually passes through it?

• Which target customers use it, and how often does their job naturally recur?
• What user outcome follows its use?
• Does use correlate with activation, retention, payment, expansion, or a learning question that still has a deadline?
• Who receives the output without appearing in product analytics?
• What would users do instead?

Record non-use as carefully as use. Confirm that instrumentation, seasonality, permissions, and discoverability do not explain the silence.

2. Strategy: does it strengthen the product being built now?

• Does it serve the chosen customer and core value moment?
• Does it sharpen positioning or attract an adjacent customer the product does not intend to serve?
• Is it part of the business model, differentiation, or a named experiment?
• If it is experimental, what observation ends the experiment?

“It might matter later” leaves the gate unanswered. Give later a trigger and a review date, or stop carrying the feature for an imaginary future.

3. Burden: where does the feature continue to charge rent?

Trace the whole footprint: onboarding, navigation, permissions, data, jobs, notifications, integrations, tests, analytics, documentation, screenshots, sales claims, support replies, incident paths, and founder-only recovery work. Name recurring cost and the changes made slower or riskier by its presence.

4. Trust: who already depends on the promise?

Look beyond recent clicks. Check stored customer work, shared links, exports, automations, paid terms, invoices, access rules, downstream recipients, and support commitments. A feature can have weak strategic value and still carry a real obligation. That obligation governs the method of removal, not whether the feature deserves indefinite life.

5. Migration: can the obligation reach a clean end?

• What must users export, move, replace, or finish?
• Can the replacement preserve the outcome, not merely the data format?
• How much notice and direct help does the dependency warrant?
• What failure signals will be watched during retirement?
• When can old routes, data, code, flags, documentation, and operating procedures be removed?
• What retention, deletion, contractual, refund, privacy, or backup commitments still apply afterward?

If the migration answer is unknown, the decision is not “keep.” It is “resolve the dependency before removal.”

Choose the Smallest Honest Treatment

The checklist can produce six outcomes:

• Keep when the feature earns its footprint and works well enough.
• Harden when it is valuable but its reliability or trust boundary is weak.
• Narrow when one path creates value and surrounding options do not.
• Close to new use when existing dependence is real but should not grow.
• Sunset when the promise needs notice, export, migration, or a support window before deletion.
• Kill now when both value and dependency are weak and a final data check is clean.

Write the result as one operational sentence:

We will [treatment] [feature or boundary] because [present evidence].
We will protect [users, work, or obligation] by [migration or support action]
until [dated or observable end condition], then remove [full footprint].
The product should recover [specific attention, clarity, cost, or safety].

A decision that says only “deprecate” has postponed the work. A decision that names only deletion has ignored the promise.

Freeze the Footprint Before Shrinking It

For a sunset, prevent new dependence before touching the old path:

• remove the feature from onboarding, sales, and upgrade prompts;
• stop new creation or enrollment while preserving agreed access;
• decline enhancements that deepen the retiring promise;
• inventory active accounts, stored work, links, integrations, and downstream recipients;
• give every temporary flag or compatibility path an owner, an exit condition, and a removal date.

Then write the customer communication before writing the deletion patch:

What is going away:
Why it is being retired, in plain product terms:
Date new use stops:
Date existing use stops:
What remains unchanged:
Export, migration, alternative, refund, or support path:
Action the customer must take:
Contact for a blocked workflow:

Do not call a lost workflow an upgrade. State what will happen to customer work and verify that the promised export or alternative succeeds on a representative account.

Finish Beyond the Interface

Hiding a menu item does not reclaim the surface area. At the end of the support window, inspect each edge named in the burden gate. Remove obsolete routes, permissions, jobs, notifications, settings, tests, events, documentation, screenshots, support procedures, sales language, flags, and data according to the commitments already made.

Watch for requests to retired routes, failed exports or migrations, job errors, support contacts, cancellations, and unexpected downstream use. Keep a bounded recovery path when the risk justifies one, but give it the same end condition as the rest of the retirement.

Finally, verify the gain. A finished removal should make something observable simpler: fewer onboarding choices, one less permissions mode, fewer support cases, a smaller release matrix, lower operating cost, clearer positioning, or more founder time for the retained workflow. If the product carries nearly the same burden afterward, the feature was hidden rather than killed.

Decision Rule

The file is ready when it contains present evidence, the complete operating footprint, named dependencies, an honest treatment, a protected migration, and an observable finish. If usage is unreadable or a dependency is uncertain, assign the smallest investigation and a review date. If the feature remains, say why it earns its place. If it leaves, finish the promise as carefully as the code.