Killing Features and Products

Every Feature Is a Standing Promise

The hardest feature to kill is rarely the one nobody remembers. It is the feature that once felt promising, has a few users, appears in a sales conversation every few months, and took real effort to build. It is not obviously dead. It is just expensive in ways the founder has stopped measuring.

Every feature is a standing promise. It promises that onboarding will explain it, support will answer for it, tests will cover it, permissions will protect it, analytics will distinguish it, documentation will mention it, and future changes will avoid breaking it. A large company can distribute that promise across teams. A solo founder pays for it with attention.

Deletion is therefore not cosmetic cleanup. It is how a solo founder defends product clarity and preserves the ability to move.

The useful question is not, “Does anyone use this?” It is, “Does this feature earn the surface area it forces the product to carry?”

Follow One Feature to Its Edges

Consider a founder building a customer-research product for small product teams. Early prospects asked for public insight boards: polished pages where they could present findings to executives. The founder built public links, stakeholder comments, custom themes, board permissions, notification settings, and a separate presentation dashboard.

Six months later, retained customers use the product differently. Every week they capture interviews, tag evidence, compare objections, and write synthesis notes. They rarely publish boards. Yet boards generate most permission questions, complicate every release involving accounts or comments, and make onboarding look as though the product is primarily a presentation tool.

Calling boards “one feature” hides their reach. They occupy the first-run tour, navigation, role model, public routing, email system, analytics taxonomy, documentation, screenshots, support replies, tests, and sales language. A change to authentication must consider anonymous viewers. A change to comments must consider stakeholders without accounts. A change to themes must not break old public links. The visible screen is only the entrance to the feature’s operating footprint.

That footprint is the surface area tax. It includes code, but it also includes every decision that must continue to remember the feature. The tax becomes dangerous precisely because it is distributed: no single test, help article, or support reply seems large enough to force a decision.

Trust belongs in the calculation. If users can see a capability, they assume the product stands behind it. A neglected feature can make the whole product feel unreliable even when the core workflow is sound.

Put Present Evidence Ahead of Past Effort

Weak features survive through individually plausible arguments. The boards took weeks to build. One respected customer asked for them. Removing them may disappoint someone. They might become useful later. None of those claims measures present value.

The founder needs a record that makes both value and obligation visible. For the modeled research product, a feature decision record might read:

FEATURE DECISION: PUBLIC INSIGHT BOARDS

Promise
  Let research teams present selected findings to stakeholders.

Target-segment use
  Two target accounts publish boards about once a month. Most retained
  teams never publish one; their weekly work is capture and synthesis.

Business and learning value
  Board use has no observed connection to renewal or higher pricing.
  Current evidence points toward a private research repository, not a
  public presentation product.

Operating burden
  Permissions and themes create recurring support. Public links,
  comments, notifications, and access rules enlarge routine releases.

Dependency and trust
  Two accounts have active stakeholder reviews stored in boards. Their
  data and shared links cannot disappear without warning and export.

Strategic fit
  Boards blur the first value moment and attract presentation-oriented
  prospects who do not adopt the retained research workflow.

Decision
  Stop new board creation now. Export and retire existing boards after a
  60-day support window. Remove the entire public-board surface afterward.

The quantities are modeled, not benchmarks. A real record should use account-level evidence and the natural frequency of the job. Monthly use may be healthy for a monthly workflow. Frequent clicks may indicate confusion rather than value. A rarely used invoice export may be indispensable because it closes the accounting cycle for paying customers.

Segment evidence is equally important. Ten free users outside the chosen market should not outweigh two retained customers who fit the thesis. But one high-paying outlier can pull a product into bespoke service. The question is whether the feature helps the market the founder has chosen, not whether somebody can be found to defend it.

Learning value can justify a temporary feature even before revenue appears. In that case, name the uncertainty it is testing and the event that will end the test. “We may need it later” is not an experiment; it is a refusal to decide.

Choose the Smallest Honest Treatment

Evidence does not produce only two verdicts. A feature that clearly strengthens activation, retention, revenue, trust, or differentiation should be kept deliberately. If it is strategically important but fragile, its unreliability is debt worth paying down.

A broad feature may contain one valuable path. Narrow it by removing options, settings, or segments that do not contribute to that path. If current users depend on a feature that no longer belongs in the product, hide it from new accounts while planning its retirement. Sunset it when dependencies require notice, export, or migration. Kill it directly only when value and dependency are both weak.

These treatments protect against opposite errors. Timidity keeps a weak feature because a few users have touched it. Impatience removes a real dependency because the founder is tired of supporting it.

For the research product, narrowing would make sense if customers used a simple read-only research digest but ignored themes, comments, and presentation controls. The founder could preserve the digest and delete the rest. The evidence record says something stronger: the target workflow is private capture and synthesis, while the two remaining boards carry stored work. That makes a bounded sunset more honest than either narrowing or immediate deletion.

Freeze the Dependency Before Removing It

The first sunset step is not deleting code. It is preventing the dependency from growing.

Remove board setup from onboarding. Stop promising boards in sales material. Block new public-board creation. Do not add the last requested theme or accept another use case that deepens the old promise. If a feature flag controls access, give the flag an owner, a removal date, and an observable exit condition. A permanent flag is merely a smaller junk drawer.

Next, identify actual dependence. Recent use is a clue, not a complete answer. Inspect stored data, shared links, paid terms, automation, and the downstream people who may rely on the output without holding an account. Separate casual exploration from a workflow that would fail if the feature vanished.

The two board-using accounts need direct contact. They need to know what will stop, when new creation ends, how long existing links will work, what the export contains, and where to ask for help. If a board contains the record of a consequential review, the founder must verify the export rather than assuming that a file exists.

Notice should be proportional to dependency. A hidden beta used by no active account may disappear after a final data check. A paid workflow with stored customer work may require a longer notice period, migration help, refunds or contract handling, and a tested archive. Disappointment cannot always be prevented. Surprise data loss and disguised abandonment can.

Say What Is Going Away

Feature removal is one of the moments when early users decide whether the founder is serious. Plain communication carries more trust than polished ambiguity.

For the research product, the note could say:

Subject: Retiring shared insight boards on September 30

We are retiring shared insight boards because retained teams use the
private interview repository and synthesis workflow, while public boards
have made onboarding and permissions less reliable.

New boards can no longer be created after August 15. Existing board data
will remain available for export until September 30. If you use a board
for an active stakeholder review, reply and we will plan the transition
with you.

The interview repository and synthesis workflow is not changing.

The dates are illustrative and must be replaced by a real plan. The form of the note is what matters: it names the removal, gives the reason without blaming users, states the timeline, protects work, offers a path for blocked accounts, and identifies the stable core.

Do not call a removal an upgrade when the user’s workflow is going away. Do not bury the date beneath a new positioning story. Users do not need the founder’s entire strategy; they need an accurate account of what will happen to their work.

Finish the Deletion

A feature is not gone when its navigation item disappears.

After the support window, remove the public routes, permissions, jobs, notifications, tests, analytics events, documentation, screenshots, settings, and sales language that existed for boards. Decide explicitly what happens to stored data. Deletion, retention, and backup behavior must match customer commitments and applicable obligations; an unreachable database table is not automatically a responsible archive.

Watch the transition. Failed exports, requests to retired routes, background-job errors, support volume, cancellations, and unexpected use reveal dependencies the inventory missed. Keep a bounded rollback path where the risk warrants it, but do not let rollback readiness become indefinite dual operation.

Then verify that the product actually became smaller. Did onboarding lose steps? Did the permissions model become easier to reason about? Did a class of support tickets disappear? Can releases touch comments or authentication with fewer branches? Does the product now describe its value without explaining an adjacent presentation tool?

The founder should name the attention being reclaimed before starting the sunset. “Less complexity” is too vague to verify. Fewer public-link incidents, one less permissions mode, shorter onboarding, a smaller test matrix, or clearer positioning can be observed. Deletion earns its disruption when that recovered attention strengthens the product that remains.

Sometimes the Feature Is the Product

The same reasoning applies when the whole product no longer earns its promises. The stakes are higher because every active user is a dependency and every operational system belongs to the retiring surface.

A product may deserve closure when target users do not retain after reaching first value, customers will not pay enough to support its operating model, custom founder labor cannot become a product, the reachable market cannot support the founder’s aims, or stronger evidence points to another thesis. None of those conclusions follows from one quiet launch or a discouraging week. They require a fair encounter with the intended market and an honest account of what was learned.

Keeping a weak product alive is not free. Hosting, security updates, billing, support, privacy requests, backups, domain and integration renewals, and reputation continue even when development stops. Silent neglect transfers the cost to users who still trust it with important work.

The available choices should be stated plainly. Maintain the product intentionally. Sell or transfer it when a capable owner and responsible handoff exist. Freeze new sign-ups while supporting current customers. Sunset it with notice, export, refunds where owed, and a final retention plan. Archive it only after obligations have been handled.

The repository is not the deciding evidence. Code can be preserved without keeping a service open, just as lessons can be preserved without defending the thesis that produced them.

The Five-Gate Decision

Before removing a feature or product, answer five questions in order:

1. Usage: Who uses it, in which segment, at what natural frequency, and in connection with what value?
2. Strategy: Does it strengthen the current customer, value moment, positioning, business model, or learning agenda?
3. Burden: What does it cost across onboarding, support, engineering, operations, sales, and founder attention?
4. Trust: Who depends on its data, workflow, links, billing, or promises, including people who are not direct users?
5. Migration: Can those dependencies be protected through notice, export, an alternative path, support, monitoring, and a definite end date?

Weak usage and weak strategic fit make a feature a deletion candidate. Heavy burden raises the urgency. Trust and migration determine the speed and method; they do not turn past effort into future value.

The final decision should fit in one sentence: “We will stop new board creation now, export and support the two dependent accounts for 60 days, then remove the public-board surface so onboarding and permissions serve the retained research workflow.” If the sentence cannot name both the evidence and the obligation, the decision is not ready.

Practice

Choose one feature that complicates onboarding, support, release confidence, or positioning. Write a feature decision record using the fields in the worked example: promise, target-segment use, business and learning value, operating burden, dependency and trust, strategic fit, and decision.

Choose the smallest honest treatment: keep, harden, narrow, hide from new users, sunset, or kill. If the answer is sunset or kill, write the customer note before editing the code. Name one observable kind of attention the removal should return.

The next stage of a product should be built on earned surface area. Deletion makes that boundary visible: these are the customers, workflows, and promises worth making more durable; the rest no longer gets to tax the founder merely because it once got built.