We accidentally built two features that do the same thing. Customers prefer the worse one.

During a reorganization of our feature set we realized that two features built eighteen months apart by different engineers essentially solve the same problem through different interfaces. The newer one is objectively better designed, faster, and more flexible. The older one is clunkier with obvious UX limitations.

Assumed we'd deprecate the old version and migrate everyone to the new one. Checked usage data first and discovered that customers who'd been using the old version hadn't switched to the new one even though we'd announced it. They stuck with what they knew.

Talked to a few of these customers and the explanation was consistent. The old version worked for their needs. Learning the new version required effort they didn't want to invest for marginal improvement. The interface they'd memorized, clunky as it was, was faster for them than a better interface they hadn't memorized yet.

This taught me something important about the relationship between product quality and user behavior. Objectively better doesn't mean preferred. Familiarity has enormous value that product teams consistently underestimate. The cognitive cost of switching to something new, even something demonstrably superior, is real friction that many users won't voluntarily accept.

We're keeping both for now and gradually incorporating the new version's capabilities into the old version's interface. Meeting users where they are rather than where we think they should be. Product improvement that ignores the user's investment in existing behavior isn't improvement from their perspective, it's disruption.