Die bezahlte Software, die nichts bringt: wenn 80 % der Funktionen niemandem dienen

Sie finanzieren die Entwicklung einer Software, Ihr Team oder Ihr Dienstleister liefert Funktion nach Funktion, und dennoch enttäuscht das Ergebnis. Das ist kein Eindruck: Studien zeigen, dass bis zu 80 % der Funktionen eines Softwareprodukts fast nie genutzt werden. Das ist jede zweite Entwicklung, manchmal mehr, für nichts bezahlt. Die Ursache ist nicht technisch, und das fehlende Glied hat einen genauen Namen: den Product Owner.

Ein KMU investiert in die Entwicklung eines maßgeschneiderten Werkzeugs oder in die Weiterentwicklung einer bestehenden Plattform. Die Wochen gehen dahin, das Budget rinnt, das technische Team liefert gewissenhaft, was man von ihm verlangt hat. Dann kommt die echte Nutzung, und mit ihr die kalte Dusche: Die Anwender nutzen nur eine Handvoll Bildschirme, ignorieren die Hälfte der Funktionen und verlangen einfache Dinge, die nie priorisiert wurden. Die Software funktioniert perfekt. Sie ist einfach zu wenig nütze. Diese Verschwendung hat eine einzige Wurzel: Niemand hat entschieden, was wirklich zählt.

Die Zahl, die die Branche kennt und verschweigt

Die Daten sind den Fachleuten bekannt und werden den Kunden selten gesagt. Die Standish Group hat bei der Analyse der tatsächlichen Funktionsnutzung in Unternehmensanwendungen festgestellt, dass 64 % von ihnen selten oder nie genutzt werden, davon 45 % nie. Neueren Datums noch: Der Hersteller Pendo hat auf Basis der Nutzungsdaten von Hunderten Softwareprodukten und Zehntausenden Anwendungen etwas noch Schlimmeres gefunden: Rund 80 % der Funktionen werden selten oder nie genutzt, und nur etwa 12 % erzeugen 80 % der täglichen Nutzung. In Geld übersetzt heißt das: Der Großteil des Entwicklungsaufwands der meisten Produkte finanziert Dinge, die die Anwender nicht hoch genug schätzen, um sie zu nutzen.

Das eigentliche Problem: Niemand sagt Nein

Warum baut man so viel Unnützes? Weil in den meisten Projekten jede Interessengruppe ihre Wünsche hinzufügt, ohne dass jemand abwägt. Der Vertrieb will diese Option, die Buchhaltung jene, ein wichtiger Kunde hat eine Funktion gefordert, dem Geschäftsführer kam in einer Besprechung eine Idee. Fehlt ein Verantwortlicher, der hierarchisiert und ablehnt, bläht sich der Umfang auf, das technische Team führt alles aus, und das Budget löst sich in Funktionen auf, die niemand nutzen wird. Softwareentwicklung scheitert fast nie an fehlender technischer Kompetenz: Sie scheitert an einem Zuviel an Gebautem und am Fehlen von Priorisierung. Man verwechselt Aktivität mit Wert.

Der Product Owner, das entscheidende Glied

In den agilen Methoden existiert eine Rolle genau dafür, dieses Problem zu lösen: der Product Owner. Seine Aufgabe ist nicht zu programmieren, sondern zu entscheiden. Er hält und hierarchisiert die Liste der Anforderungen, er übersetzt den fachlichen Bedarf in klare Prioritäten für das technische Team, und vor allem entscheidet er: was jetzt gemacht wird, was verschoben wird, was nie gemacht wird. Er baut die Brücke zwischen dem Geschäftsführer, der den Geschäftswert kennt, und den Entwicklern, die die technischen Kosten kennen. Er sorgt dafür, dass jeder Euro Entwicklung dorthin geht, was Ertrag bringt, und nicht dorthin, was belastet. Ohne diese fest gehaltene Rolle driftet ein Softwareprojekt fast immer in den Katalog unnützer Funktionen.

Warum KMU diese Rolle nicht haben, und wie sie sie bekommen

Die meisten KMU haben keinen Product Owner. Der Geschäftsführer hat weder die Zeit noch immer die Methode, das technische Team entscheidet am Ende über fachliche Prioritäten, die es nicht beherrscht, und der externe Dienstleister baut, was man bei ihm bestellt, ohne die Sinnhaftigkeit zu hinterfragen. Das Ergebnis ist vorhersehbar. Dabei verlangt diese Rolle keine Vollzeitstelle: Sie verlangt Methode, Präsenz zu den entscheidenden Momenten und das Mandat zu entscheiden. Genau das bringt ein Product Owner auf Zeit ein, indem er die Entwicklung taktet, die Priorisierung hält und das Budget gegen die Inflation der Wünsche schützt. Der Return on Investment zeigt sich schnell: weniger gebaute Funktionen, mehr nützliche Funktionen.

Weniger bauen, mehr Wert liefern