Feature Creep¶

Explain why a product accretes capabilities past net benefit as a governance failure, not a quality one — an approval gate that judges each addition in isolation against its stated cost while structurally blind to the compounding global cost of all additions together.

Core Idea¶

Feature creep is the tendency of a software product to accumulate capabilities beyond the point of net benefit, driven by a gate that evaluates each addition in isolation while blind to the compounding cost of all additions together. Each feature is locally defensible, but the aggregate burden grows — maintenance surface, onboarding, a combinatorial test matrix. The root mechanism is a granularity mismatch: additions are approved one at a time, but cost is borne by the whole system, so the gate systematically underestimates it.

Scope of Application¶

Feature creep lives across the subfields of software and product development that govern a feature set through a per-addition gate whose decision unit is finer than its cost unit; its reach is within that domain.

Product management — the canonical pathology of long-lived consumer software.
API, protocol, and language-standard design — cost surfacing as compiler complexity and flags bitfields.
Enterprise customization platforms — ERP/CRM configs accreting until upgrade becomes infeasible.
Open-source maintenance — where the gatekeeping resource, maintainer attention, is what accumulation destroys.

The named cross-domain co-instances — mission creep, scope creep, regulatory creep — are full instances of the same accumulation-under-a-permissive-gate parent, and the breadth belongs to that parent.

Clarity¶

Naming feature creep relocates the problem from the product to the process that approved it: a quality complaint ("the product got bloated") is recast as a governance failure. That dissolves the puzzle of how a product reaches a state nobody would have approved as a whole — no single bad decision is to blame. The decisive distinction is between the unit of decision (one feature) and the unit of cost (the whole system), which shows the gate's error is a systematic, compounding underestimate, not occasional misjudgment.

Manages Complexity¶

A bloated product presents a tangle of complaints — trained-to-navigate menus, seventeen-value flags bitfields, incompatible customer configs, a combinatorial test matrix. Feature creep compresses the tangle to a single cause located in the gate, not any feature, so the search for a culprit dissolves. The analyst tracks a small set — the decision-unit, the cost-unit, the stated-versus-actual-cost gap, and its compounding rate — and reads off both the product's trajectory and which class of remedy is on-target.

Abstract Reasoning¶

Feature creep licenses moves turning on the gate relocation and the granularity mismatch. A diagnostic move reads bloat back to the gate, not a culprit feature. A boundary-drawing move separates stated from actual cost and a quality problem from a governance one. An interventionist move sorts remedies by a clean binary — attack the gate (works) versus refine the marginal calculus (cannot). A predictive move forecasts monotone, self-accelerating accumulation from the gate's structure.

Knowledge Transfer¶

Within software and product development feature creep transfers as mechanism: the diagnostic, the stated-versus-actual-cost boundary, the unit mismatch, the prediction of self-accelerating accumulation, and the remedy binary carry intact across product management, API design, customization platforms, and open-source maintenance, because each is the same per-addition gate. Beyond software it is the clearest case (B): the parent — accumulation under a permissive marginal gate, blind to global cost — recurs as genuine named co-instances (mission creep, scope creep, requirements creep, regulatory creep), each a full instance with its own gate. That parent is itself a strong prime candidate; "feature creep," with its symptom catalogue and software remedies, carries baggage that should not travel.

Relationships to Other Abstractions¶

Current abstraction Feature Creep Domain-specific

Parents (1) — more general patterns this builds on

Feature Creep is a kind of Scope Creep Prime

Feature creep is scope creep specialized to product capabilities admitted one at a time while their system-wide interaction and maintenance costs compound.

Hierarchy paths (3) — routes to 3 parentless roots

Feature Creep → Scope Creep → Ratchet Effect → Path Dependence → Dependency

Show alternative paths (2)

Neighborhood in Abstraction Space¶

Feature Creep sits in a moderately populated region (57^th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Unclustered & Miscellaneous (309 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12