Irgendwo in deinem Produkt gibt es ein Feature, das kaum jemand mehr benutzt.
Kein Bug-Report. Kein Feedback-Ticket. Kein Kundengespräch, das es erwähnt. Einfach: Stille. Und genau diese Stille ist das Problem. Denn Stille wird in Produktteams fast immer falsch interpretiert. Kein Complaint heißt: läuft. Dabei heißt es meistens nur: niemand redet darüber.
Produktarbeit wird an Neuzugängen gemessen
Releases. Tickets. Deployments. Changelogs. Das ist der sichtbare Teil von Produktarbeit — und er wird gefeiert. Zu Recht, denn er ist greifbar.
Was kaum jemand misst: Was nutzen unsere Kunden eigentlich nicht mehr? Welche Features haben wir gebaut, weil wir dachten, sie werden gebraucht — und stellen jetzt fest, dass sie es vielleicht gar nicht werden?
Das ist keine Frage, die Produktteams sich regelmäßig stellen. Nicht weil sie unwichtig ist. Sondern weil man einfach nicht daran denkt.
Die unsichtbaren Kosten toter Features
Ein Feature, das niemand nutzt, verschwindet nicht einfach. Es bleibt. Und es kostet.
Entwickler pflegen es mit, wenn sich die Codebasis ändert. Designer denken es mit, wenn neue UI-Strukturen entstehen. Support-Teams beantworten Fragen dazu. Onboarding-Texte erklären es. Und neue Teammitglieder verbringen Zeit damit, es zu verstehen — nur um dann festzustellen, dass es in der Praxis kaum eine Rolle spielt.
Diese Kosten sind verteilt, klein und gut versteckt. Deshalb fallen sie selten auf. Aber sie summieren sich. Und vor allem: Sie lenken Aufmerksamkeit von dem ab, was wirklich zählt.
Warum Produktteams trotzdem keine Features entfernen
“Irgendjemand braucht das bestimmt noch.”
Dieser Satz ist der Klassiker. Und er ist nicht mal falsch — irgendwo gibt es fast immer jemanden, der ein Feature irgendwie nutzt. Aber die eigentliche Frage ist doch, Rechtfertigt dieser Jemand den laufenden Aufwand?
Dazu kommt: Schweigen wird oft als Zustimmung wahrgenommen. Wenn niemand fragt, nimmt man an, dass alles passt. Dabei fragen Nutzer selten aktiv nach Features, die sie nicht kennen oder längst aufgegeben haben. Sie klicken einfach drumherum. Oder sie hören auf, das Produkt zu benutzen — leise, ohne Erklärung.
Wie man es konkret angehen kann
Es gibt kein perfektes System dafür. Aber ein paar Fragen helfen:
Schau in die Daten.
Wie oft wird ein Feature tatsächlich aufgerufen? Nicht “haben wir es gebaut”, sondern “wird es genutzt”. Analytics-Daten sind hier oft ernüchternd — und lehrreich.
Frag intern.
“Was würde passieren, wenn wir das morgen rausnehmen?” Wenn die Antwort ist: “Keine Ahnung, wahrscheinlich gar nichts” — dann ist das ein gutes Signal.
Frag die Kunden.
Nicht “nutzt du Feature X?”, sondern: “Was machst du, wenn du Y erreichen willst?” Die Antwort zeigt, ob das Feature überhaupt im Kopf der Nutzer existiert.
Setz eine bewusste Schwelle.
Weniger als X% der Nutzer haben es in den letzten 90 Tagen genutzt? Dann steht es auf dem Prüfstand. Nicht automatisch weg — aber bewusst hinterfragt.
Entfernen ist auch eine Produktentscheidung
Der Reflex ist: Features sind Fortschritt. Mehr ist mehr. Aber das stimmt nicht.
Jedes Feature, das bleibt, obwohl es nicht mehr sinnvoll ist, macht dein Produkt ein bisschen schwerer. Schwerer zu erklären. Schwerer zu supporten. Schwerer weiterzuentwickeln. Und für neue Nutzer schwerer zu verstehen, die sich dann vielleicht fragen: Warum gibt es das eigentlich?
Entfernen braucht Mut, weil es sich nach Rückschritt anfühlt. Es ist aber das Gegenteil. Es ist das Zeichen eines Teams, das sein Produkt wirklich versteht. Das bereit ist, vergangene Entscheidungen zu hinterfragen. Das Klarheit über Vollständigkeit stellt.
Eine Frage für Dein nächstes Produktmeeting
Neben “Was bauen wir als nächstes?” gehört auch diese Frage auf die Agenda: “Was sollten wir uns noch mal genauer anschauen — nicht weil es kaputt ist, sondern weil wir nicht sicher sind, ob es noch gebraucht wird?”
Das ist kein Angriff auf die Vergangenheit. Es ist Produktreife.
Ein gutes Produkt ist nicht das mit den meisten Features. Es ist das, mit den richtigen Features.
Artikel teilen: X • LinkedIn • E-Mail • .