The previous piece argued that a channel’s value depends on the total volume arriving through it. Preferences are the lever users have on that total, and how well the lever works determines what they do with it. Given fine-grained control, people turn off the parts they don’t want and keep reading the rest. Given a single switch labeled “notifications,” they eventually flip it, and from then on every message you send goes nowhere — including the one about their failed payment.

That’s the real cost of coarse preferences: they convert a small annoyance into total disengagement, because the only tool available is the largest one. It’s the same dynamic as the fairness argument from the limits thread, in a different domain — when the system offers no way to make a proportionate adjustment, users take the disproportionate action available to them, and then you’ve lost the channel rather than one notification type.

Useful granularity usually runs along two axes rather than one. Category — which kinds of events do I care about — is the obvious one. Channel is the other, and it matters more than it looks: the same event might warrant a push notification for one person and a weekly digest line for another, and forcing a single delivery mechanism per category means someone is always getting the wrong intensity. Separating what from how lets people dial their own volume without abandoning the content, which is the outcome you want.

There’s an implementation trap here worth naming, because it’s the permissions problem again. Preferences are only real if every send path consults them, and send paths accumulate — the new feature that emails directly, the batch job that predates the preference system, the third-party service that has its own list. Each one that bypasses the check is a promise broken in the way most likely to be noticed, since the user explicitly asked not to receive that. Like access control, this wants a single point every message passes through, rather than a convention each new code path is trusted to remember.

And a small default worth defending: some things shouldn’t be optional, and they should be a short list. Security events, billing failures, and legally-required notices are legitimately unmuteable. That list stays credible only if it’s genuinely minimal — the moment product announcements get classified as essential, users learn that “you can’t turn this off” means “we decided our marketing outranks your inbox,” and the goodwill that made the real mandatory messages tolerable is spent on something that didn’t need it.