Wie entscheidest du, ein Feature einzustellen, und wie machst du den Rückbau tatsächlich?

Entscheide nach Gesamtkosten, nicht nur nach Nutzung: Support-Last, Wartungsbremse und die Oberfläche, die es jeder künftigen Änderung hinzufügt, abgewogen gegen den Umsatz und die Retention, die wirklich daran hängen. Dann bau es in Stufen zurück. Neue Nutzer bekommen es nicht mehr, betroffene Accounts werden direkt mit Datum und Migrationspfad kontaktiert, die API wird mit langem Fenster deprecated, und entfernt wird erst, wenn die Nutzung flach ist.

Ich schaue auf die Gesamtkosten statt auf die Nutzung, denn Nutzung allein lässt eine Entfernung immer zu riskant wirken. Ich addiere also die Support-Tickets, die Wartungszeit und die Bremse, die es auf jede andere Änderung legt, denn ein altes Feature macht jedes Refactoring in seiner Nähe teurer. Dagegen stelle ich den Umsatz und die Retention, die wirklich daran hängen, was meist heißt zu prüfen, ob die Accounts, die es nutzen, tatsächlich gehen würden. Danach ist der Rückbau gestuft, und die Stufen zählen mehr als die Entscheidung. Neue Nutzer bekommen es nicht mehr, die verbleibenden Accounts werden direkt mit einem Datum und einem Weg zu etwas anderem kontaktiert, die API wird mit langem Fenster und einer Warnung in der Response deprecated, und entfernt wird erst, wenn der Graph flach ist. Was schiefgeht, ist eine Ankündigung per Changelog und Hoffnung. Wer eine echte Abhängigkeit hat, verdient eine E-Mail und einen Menschen, mit dem er darüber reden kann.