Feature Criticality Tiering
Classifying product functionality by whether it must work, should work, or can be dropped, so degradation decisions are made in advance by the business.
Degradation is usually treated as an engineering concern, and it is not. Deciding that recommendations may disappear during an incident is a product decision, and made under pressure at 03:00 by an engineer guessing, it is made badly.
A workable tiering for a retail platform: Tier 0 — browse, search, add to basket, checkout, payment. Must work; every dependency in these paths is critical and must be redundant. Tier 1 — order history, account management. Should work; degraded is acceptable briefly. Tier 2 — recommendations, reviews, related items, personalisation, live stock counts at nearby stores. Droppable, with a defined fallback each.
What the exercise produces beyond the ranking: a defined fallback per Tier 2 feature (a generic list, a cached value, a hidden element), a feature flag to disable it, and an agreement that the degraded experience is acceptable — signed off in advance, not negotiated during the incident.
It also reveals accidental criticality. A Tier 2 feature called synchronously in the Tier 0 path is a Tier 0 dependency in practice, and finding that in the ranking exercise is far cheaper than finding it in an outage.