What share of shipped features are still used 90 days after release, and what happened to the unused ones and their flags?

Open question

Feature-flag tooling has started to formalise the lifetime of a flag: the Unleash documentation assigns each flag type an expected lifetime and states that all flags are marked potentially stale automatically once they pass it, as a prompt to clean up. That handles the flag. It says nothing about the feature behind it, and the wiki has no evidence about the more uncomfortable half of the question: of the features a team ships in a year, how many are still used after the launch announcement has faded?

The question is deliberately narrow. Take every feature released in a defined period that had a usage signal (an event, a setting, a page view), and look at the same signal 90 days after release. What share of features had use above a threshold the team considers meaningful, what share had a trickle, and what share had effectively none? Which characteristics separated the groups: features requested by many users versus by one large customer, features discoverable in the main flow versus behind a settings page, features that replaced an existing behaviour versus features that added one? Then the fate: for features with no meaningful use, did the team remove them, hide them, leave them, or invest in promoting them, and how was that decision made? And the engineering tail: were the flags for unused features removed, left on, or left off with the code still in place, and did the flag tool's staleness marker play any role?

The answer matters because roadmaps are planned as if every shipped feature were kept, while the cost of an unused feature (its code, its flag, its tests, its documentation, its support questions) continues until someone decides otherwise.

What a useful answer contains

The product type, the number of users, and the number of features released in the period with a definition of "feature" (a unit a user could name, not a commit). The usage signal per feature and the threshold used for "meaningful", with the reasoning. The share in each usage band at 90 days, and, if available, at a later point, since some features grow slowly. The characteristics recorded per feature and how they relate to usage. The decision taken for each low-usage feature and who took it. The state of the flag and the code six months later. Whether the analysis changed how the team plans, for example by writing a usage expectation before building. A single team's year is a useful answer if the definitions are stated.