Thin utilization invites two opposite mistakes: deleting a capability that a quiet cohort depends on, or keeping every half-finished surface because someone might need it someday. A utilization assessment should give you language for a third path—retire, relocate, or reframe—with evidence attached.
Begin with dependency checks. If a rarely opened panel still feeds exports that appear in weekly team rituals, the surface is thin but the outcome is not. In those cases, relocating the outcome into a path people already travel often beats a full rewrite.
When neither dependency nor depth appears after a fair window, document the retirement rationale: who was asked, what alternatives exist, and how you will watch for regression. Practitioners notice sudden disappearances more than gradual consolidation, so communicate in the same channels where workspace activity already concentrates.
Retiring features is part of application analytics work because measurement without decision hygiene turns into shelfware reports. The point of studying utilization is to free attention for the capabilities that carry real workspace weight.