Ockhams Feature Pruning

Ockham's Razor — feature pruning

Feature pruning is the discipline of removing things that no longer earn their place. Most products accumulate features, options, and complexity over time; periodic pruning is necessary to prevent the product from becoming unusable through accumulated weight.

Pruning is hard. Users (often a small but loud minority) resist removal even when most users don't use the feature. Engineers may have spent significant effort building it. Marketing has highlighted it. The cost of removal feels concrete; the benefit (freedom from maintenance, simpler product, easier evolution) is diffuse.

But pruning, done well, is one of the highest-leverage product activities. A clean product evolves faster, costs less to maintain, is easier for new users to learn, and tends to keep its core users happier.

What's a candidate for pruning

A feature, option, or piece of UI is a pruning candidate when one or more of:

Low usage. Below 1% of users (often below 5%) without clear strategic justification.

High maintenance cost. Bugs, support tickets, broken integrations.

Dependency liability. Depends on third-party services, deprecated APIs, or aging infrastructure.

Confused with other features. Users don't know which to use; designers can't articulate the difference.

Originally built for a use case that's no longer relevant. The customer who requested it no longer exists; the workflow it supported has changed.

Functionality covered by other features. Redundant with newer, better-designed capabilities.

Cognitive overhead disproportionate to value. A setting that adds choice but most users don't engage with.

Holds back evolution. Removing it would unlock significant simplification or new capability.

What's not a candidate for pruning

Even if usage is low, don't prune when:

Critical for a small but high-value audience. The 1% who use the feature might be your most valuable customers.

Required for compliance, legal, or accessibility. The feature may serve a small audience but be essential for some context.

Required for a workflow that doesn't have an alternative. Even rare workflows shouldn't be eliminated unless an alternative exists.

Strategic for future direction. Some features are bets on a future use case; usage may grow.

Underutilized due to discoverability, not lack of value. Sometimes a low-usage feature is one users don't know exists; promotion may be a better answer than pruning.

The pruning process

A disciplined pruning process:

1. Audit. List candidates based on usage data, support patterns, and engineering input.

2. Investigate each candidate. For each: who uses it, why, what would they do without it? Talk to representative users if possible.

3. Categorize:

• Prune outright (low usage, no important users dependent).
• Prune with migration (low usage but some users dependent; provide alternatives).
• Defer (currently rare but strategically important).
• Keep (justified despite low usage).

4. Plan the migration for "prune with migration" candidates. What's the alternative for affected users? How will you communicate? What's the timeline?

5. Execute. Announce, deprecate, remove. Each step has its own timeline.

6. Measure. After pruning, did the predicted benefits materialize? Are affected users staying or churning?

Pruning patterns

Soft removal. Remove from default UI but keep accessible (e.g., behind a "legacy" menu). Lower cost; users who depend can still find it.

Hard removal. Remove entirely. Higher cost but cleaner result.

Replacement. Remove the old feature; provide a better alternative. Requires the alternative to actually serve the use case.

Deprecation announcement. Announce removal date in advance; let users prepare or migrate.

Sunset migration. Active outreach to users of the feature, helping them migrate.

The right pattern depends on usage volume, importance to users, and how cleanly the alternative covers the use case.

Worked examples

A feature with declining usage

A productivity tool has a "smart suggestions" feature that auto-recommends actions. Initially popular; over time, usage has declined as the product has evolved. Audit shows: 2% of users use it weekly; mostly long-term users; the suggestions are often ignored.

Decision: prune. Announce removal in 60 days. Email the 2% explaining the change and offering alternatives. Remove the feature; gain the maintenance time back.

Result: minimal churn; the product is simpler; the engineering team has more capacity for other work.

A configuration setting that no one understands

A settings panel has a checkbox: "Enable advanced mode." When enabled, it changes some keyboard shortcuts. Audit shows: 0.3% of users have enabled it; support sometimes gets questions about it; documentation is unclear.

Decision: prune. Remove the setting; pick the better default for both modes; eliminate the divergent code paths. Communicate the change to the small affected audience.

Result: simpler settings, simpler code, easier to support.