/void

Feature Creep Pitfalls & Scope Management

Purpose: Use this file when Void is evaluating feature growth, zombie functionality, or oversized product scope.

Contents:

• Core causes and detection signals for feature creep
• 90/10 principle and zombie-feature thresholds
• Strategic growth vs creep rules
• Pruning lifecycle, removal flow, and feature-addition gates

8 Common Causes

Empirical Anchor

Microsoft's Kohavi et al. found that even with careful up-front analysis, only ~1/3 of shipped features improved the metrics they were designed to improve. Combined with 2026's ~41% AI-generated code share and the +23.5% incidents-per-PR signal above, the default assumption should be that unvalidated new functionality is more likely to harm than help the product surface it lands on. Feature-addition gates and pruning lifecycles below are calibrated to that prior.

Detection Signals

Product Signals

Delivery Signals

90/10 Principle and Zombie Features

Rules:

• Often 90% of users use only 10% of features.
• The low-usage majority of features can consume a disproportionate share of maintenance cost.
• Regulatory and security features are exceptions and should not be removed on usage alone.

Feature Classification

Strategic Expansion vs Feature Creep

Strategic expansion

• Deepens the core value proposition.
• Solves a major pain point for existing users.
• Is backed by usage evidence.
• Preserves product coherence.

Feature creep

• Expands sideways away from the core.
• Solves "nice to have" requests without evidence.
• Copies competitors without clear strategy.
• Adds confusion and cross-feature dependency.

Pruning Lifecycle

INTRODUCE -> MONITOR -> EVALUATE -> PRUNE or GROW

Recommended controls:

• define the success metric before release
• define the exit criterion before release
• review usage and maintenance cost at least quarterly
• prefer staged retirement with flags or migration paths

Removal Decision Flow

Usage <5%?
  -> No: keep as Active/Core
  -> Yes
     -> Regulatory or security requirement?
        -> Yes: keep
        -> No
           -> Alternative exists?
              -> No: re-evaluate impact
              -> Yes
                 -> CoK >4?
                    -> No: DEFER
                    -> Yes: propose REMOVE with a phased plan

Feature-Addition Gate

Every new feature request should answer:

1. What problem does it solve?
2. How many users are affected?
3. How does it align with the core value proposition?
4. What is the success metric?
5. What is the removal or re-review criterion?
6. What is the ongoing maintenance cost?

If the gate is incomplete, default to DEFER or REJECT.

One In, One Out

Rule: when scope is already broad, adding one feature should force a conversation about removing one.

Exceptions:

• very early product stage
• regulatory or mandatory features

Void Use

• Use low-usage features (<5%) as strong REMOVE candidates.
• Use feature-creep signal count to decide whether to trigger Batch Audit.
• Use the pruning lifecycle when a hard delete is unsafe.

Quality gates:

• usage <5% -> zombie-feature review
• onboarding >30 min -> recommend scope reduction
• missing gate answers -> block feature expansion
• 3 or more feature-creep signals -> recommend Batch Audit

Sources: ProductPlan: Feature Creep · Intercom: Managing Feature Requests · Basecamp Shape Up · Kohavi et al. — Online Experimentation at Microsoft (Microsoft Experimentation Platform) · LeadDev — How AI-generated code accelerates technical debt (2026)