How do you decide which platform versions to drop from a support matrix, and what do you owe users when you drop one?

### Why this is a judgement call A support matrix compounds. Each new platform version usually arrives without an old one leaving, so a matrix that is never pruned grows monotonically — more pipeline minutes, more devices, more images, more one-platform defects competing with feature work. Pruning is therefore continuous portfolio management, and the reason it is a lead's problem is that the inputs sit in different departments: engineering knows the cost, product knows the commitments, support knows who is still there, and only telemetry knows the truth about usage. ### The inputs, in the order that settles arguments **1. Your own usage share.** Measure from the product's own telemetry — sessions, active accounts, and the requests behind them — not from published market-wide statistics, which describe a population that is not your customer base. Segment it: share of *sessions* answers a different question from share of *revenue* or share of *enterprise accounts*. **2. Stated commitments.** Contracts, published support policies, procurement answers, and anything sales said in writing. A platform with a tiny share and a signed commitment is not droppable this cycle, and finding that out after the announcement is the expensive path. **3. Upstream support status.** When the platform's own vendor has ended support for a version, that is the strongest external argument available and the cleanest thing to communicate, because it is also a security argument rather than a convenience one. **4. The cost of the cell.** Be concrete: pipeline minutes per run, device or image inventory, the count of defects in the last few releases that reproduced only there, and the engineering hours those consumed. A cell with a heavy defect tail is more expensive than its run time suggests. **5. Switching cost for the people on it.** A browser generation is a same-day upgrade; a locked-down desktop fleet in a regulated environment can be a procurement cycle. The lead time you owe scales with this, not with your release cadence. ### Representative versus exhaustive Within what remains, the second lever is depth. Exhaustive coverage — every point release, every device model — buys far less than it costs, because most point releases share a code base and behave identically for your purposes. A defensible **representative** selection covers the axes of real difference: - one version per engine generation or platform API level, not per point release - the **oldest** supported version and the **newest**, because boundaries break first - the lowest-capability device class in the matrix - one member of each vendor build family that has historically diverged and then a periodic wider sweep, less often, to catch what the representative set misses. The honest framing in an interview is that this is sampling: it trades a known, bounded risk for a large cost reduction, and the way you manage the risk is by re-choosing the sample whenever the field-defect evidence says the sample missed something. Be careful with popular claims here. There is no industry-standard usage threshold at which a platform becomes droppable; teams that quote a specific percentage are quoting their own policy. Similarly, the evidence about how many defects are unique to a single platform varies enormously by product type, so quantify from your own defect history rather than a remembered figure. ### What you owe the people you drop Dropping is a withdrawal of a promise, and the process is where reputations are made: - **Announce with lead time** proportional to switching cost, in the release notes, in-product, and directly to accounts identified from telemetry. - **Warn in place.** A banner shown only on the affected platform reaches exactly the people concerned and nobody else. - **Pin a last-supported release** and say how long it will receive security fixes. This is what turns "we dropped you" into "you have a supported option while you plan". - **Move the tier before removing it.** Fully supported → deprecated → unsupported, over at least one release, so the change is visible before it bites. - **Verify from telemetry.** Watch the tail migrate. If it does not move, that is data about switching cost, and the deadline may need to move with it. - **Only then remove the code** and the compatibility branches. Removing them while users remain is what makes the drop irreversible at the worst moment. ### A worked example A hotel booking channel manager finds that engine generation N-3 accounts for 0.42% of console sessions but 38 properties, of which 6 sit under contracts with an explicit support clause, and their connectors carry part of a 1,200-request-per-minute promotion peak. The cell costs roughly 34 pipeline minutes per release and produced 5 of the last 19 client defects. The decision that survives scrutiny is not "drop it, it is under half a percent": it is to deprecate this release, notify the 38 properties with named dates, honour the 6 contracts to their term with a pinned last-supported release, and remove the cell after the tail has been observed to move — with the cost figures on the record so the next review starts from evidence rather than argument.