Der Feature-Friedhof: Was passiert mit Features, die niemand nutzt?

Jedes Produkt hat sie.

Features, deren Bau Tage gedauert hat.

Features, die in Planungsmeetings spannend aussahen.

Features, bei denen alle überzeugt waren, dass Nutzer sie lieben würden.

Und dann …

Hat sie niemand benutzt.

Sie sitzen still im Produkt, nehmen Platz weg, erhöhen die Komplexität und werden langsam zu etwas, woran das Team nicht mehr denkt.

Willkommen auf dem Feature-Friedhof.

Jedes Feature beginnt mit einem Grund

Die meisten ungenutzten Features sind keine schlechten Ideen.

Genau das macht das Problem so interessant.

Ein Team baut normalerweise nichts ohne Grund.

Vielleicht haben Nutzer danach gefragt.

Vielleicht hat ein Konkurrent es gelauncht.

Vielleicht haben die Analytics eine Chance gezeigt.

Vielleicht dachte der Gründer, es würde das Produkt besser machen.

Oder vielleicht war das Team einfach überzeugt:

„Das werden die Nutzer lieben.“

Also wird es gebaut.

Getestet.

Gelauncht.

Und dann kommen die Zahlen.

Fast niemand klickt drauf.

Bauen ist leichter als Entfernen

Wenn ein Feature erst einmal existiert, kann es sich anfühlen wie ein Eingeständnis des Scheiterns, es wieder zu entfernen.

Die Gespräche klingen dann meistens ungefähr so:

• „Aber wir haben drei Wochen daran gebaut.“
• „Was, wenn Nutzer es später brauchen?“
• „Vielleicht haben die Leute es einfach noch nicht entdeckt.“
• „Lassen wir es erst mal drin.“

Und das Feature bleibt.

Dann kommt ein weiteres Feature dazu.

Und noch eins.

Und noch eins.

Irgendwann ist das Produkt kompliziert – nicht, weil irgendjemand das geplant hätte, sondern weil nie etwas entfernt wird.

Die versteckten Kosten eines ungenutzten Features

Ein ungenutztes Feature muss nicht jedes Mal eine Rechnung schreiben, wenn jemand es ignoriert.

Es kann das Team trotzdem etwas kosten.

Es kann zum Beispiel:

• Die Oberfläche unübersichtlicher machen.
• Den Wartungsaufwand erhöhen.
• Zusätzliche Tests erfordern.
• Mehr Dokumentation nach sich ziehen.
• Mehr Support-Anfragen auslösen.
• Das Onboarding verwirrender machen.
• Aufmerksamkeit von wichtigeren Features abziehen.

Das Feature hat vielleicht fast null Nutzer und macht trotzdem Arbeit.

Das ist eine der seltsamen Eigenheiten von Software.

Auch ungenutzter Code kann etwas kosten.

Mehr Features heißt nicht immer mehr Wert

Man misst Fortschritt leicht an der Zahl der ausgelieferten Features.

Fünf Features diesen Monat.

Zehn nächsten Monat.

Zwanzig bis Ende des Jahres.

Das fühlt sich produktiv an.

Aber Nutzer wählen ein Produkt nicht, weil es die längste Feature-Liste hat.

Sie wählen es, weil es ihnen hilft, etwas besser, schneller oder einfacher zu erledigen.

Manchmal verbessert ein weiteres Feature dieses Erlebnis.

Manchmal gibt es Nutzern einfach eine Sache mehr, die sie verstehen müssen.

Mehr ist nicht automatisch besser.

Manchmal ist es einfach nur mehr.

Und was, wenn Nutzer das Feature gar nicht finden?

Hier wird es spannend.

Ein Feature mit geringer Nutzung ist nicht unbedingt ein nutzloses Feature.

Vielleicht wissen Nutzer einfach nicht, dass es existiert.

Das ist ein wichtiger Unterschied.

Bevor du etwas entfernst, frag dich:

„Ignorieren Nutzer dieses Feature, oder finden sie es einfach nicht?“

Ein nützliches Feature, das in einem verwirrenden Menü vergraben ist, kann in deinen Analytics völlig nutzlos aussehen.

Ein besseres Onboarding könnte helfen.

Eine klarere Navigation könnte helfen.

Eine bessere Beschriftung könnte helfen.

Ein kleiner Hinweis im Produkt könnte helfen.

Bevor du ein Feature also auf den Friedhof schickst, stell sicher, dass es wirklich dorthin gehört.

Sprich mit den Nutzern, die es tatsächlich nutzen

Analytics können dir sagen, was passiert.

Nutzer können dir oft sagen, warum.

Wenn nur 2 % der Nutzer ein Feature verwenden, sprich mit ein paar von ihnen.

Frag sie:

• „Warum nutzt du es?“
• „Welches Problem löst es für dich?“
• „Was würdest du tun, wenn dieses Feature morgen verschwindet?“

Vielleicht stellst du fest, dass das Feature nicht beliebt ist, für eine kleine Gruppe von Nutzern aber enorm wertvoll.

Und das ist ein wichtiger Unterschied.

Ein Feature muss nicht beliebt sein, um wertvoll zu sein.

Die Frage, der sich jedes Feature irgendwann stellen muss

Irgendwann sollte sich jedes Produktteam fragen:

„Wenn wir dieses Feature heute nicht hätten, würden wir es noch einmal bauen?“

Wenn die Antwort Nein lautet, lohnt es sich, genauer hinzuschauen.

Vielleicht braucht das Feature ein Redesign.

Vielleicht sollte es für die meisten Nutzer ausgeblendet werden.

Vielleicht sollte es mit etwas anderem zusammengelegt werden.

Oder vielleicht … sollte es entfernt werden.

Wie viel Zeit schon in etwas geflossen ist, sollte nicht entscheiden, ob es bleiben darf.

Das ist einfach die Sunk-Cost-Falle.

Ein Feature zu entfernen ist auch Produktentwicklung

Etwas zu löschen kann sich wie ein Rückschritt anfühlen.

Ist es aber nicht.

Unnötige Komplexität zu entfernen kann ebenfalls Fortschritt sein.

Wenn ein Feature verschwindet, kann das Produkt:

• Leichter zu verstehen sein.
• Leichter zu warten sein.
• Ein einfacheres Onboarding haben.
• Leichter zu erklären sein.
• Leichter zu navigieren sein.

Manchmal lautet das beste Produkt-Update nicht:

„Wir haben etwas Neues hinzugefügt.“

Sondern:

„Wir haben das Produkt einfacher gemacht.“

Und das wissen Nutzer vielleicht mehr zu schätzen als einen weiteren Button in der Oberfläche.

Aber mach daraus keine Aufräumaktion

Hier lauert noch eine andere Falle.

Ein Team kann regelrecht besessen davon werden, alles zu entfernen, was keine riesigen Nutzungszahlen hat.

Das ist nicht immer klug.

Manche Features werden selten genutzt, sind aber extrem wichtig, wenn jemand sie braucht.

Nimm einen Export-Button.

Die meisten Nutzer fassen ihn vielleicht nie an.

Aber die, die es tun, sind vielleicht darauf angewiesen.

Die Nutzung allein sollte also nicht über das Schicksal eines Features entscheiden.

Schau aufs große Ganze:

Nutzung + Wert + Nutzerfeedback + Wartungsaufwand.

So lässt sich viel besser beurteilen, ob etwas bleiben sollte.

Bau mit einer Frage, nicht nur mit einem Feature

Bevor du etwas baust, frag dich:

Welches Problem lösen wir?

Dann:

Wer hat dieses Problem tatsächlich?

Und schließlich:

Woran merken wir, dass wir es gelöst haben?

Diese Fragen klingen simpel.

Aber sie können Wochen an Entwicklungszeit sparen.

Statt zu feiern, wie viele Features das Team ausgeliefert hat, feier lieber, wie viele echte Probleme gelöst wurden.

Das ist ein viel besserer Maßstab für Fortschritt.

Der Friedhof ist nicht immer etwas Schlechtes

Jedes Produkt wird irgendwann Features haben, die nicht funktioniert haben.

Das ist normal.

Manche Ideen scheitern.

Manche Experimente bekommen keine Zugkraft.

Manche Features werden überflüssig.

Das gehört zum Software-Bauen dazu.

Das Ziel ist nicht, den Feature-Friedhof komplett zu vermeiden.

Das Ziel ist, aus dem zu lernen, was dort landet.

Wenn fünf Features aus demselben Grund scheitern, ist das eine nützliche Information.

Wenn Nutzer eine bestimmte Art von Funktionalität immer wieder ignorieren, ist das ein Signal.

Wenn das Entfernen von etwas das Engagement sogar verbessert, ist das eine Lektion.

Scheitern wird wertvoll, wenn du genau hinschaust.

Zum Schluss

Gute Produkte entstehen nicht durch endloses Hinzufügen.

Sie entstehen, indem man versteht, was bleiben verdient.

Jedes Feature sollte sich seinen Platz verdienen – nicht, weil das Team wochenlang daran gebaut hat, sondern weil es jemandem wirklich hilft.

Manchmal heißt das, etwas Neues zu bauen.

Manchmal heißt es, etwas Bestehendes zu verbessern.

Und manchmal …

heißt es, den Feature-Friedhof zu öffnen und endlich etwas loszulassen.

Denn in Software ist weniger nicht immer mehr.

Aber Unnötiges ist nie umsonst.