In einer Welt, in der sich eine Funktion schneller entwerfen, programmieren und ausrollen lässt als je zuvor, wird Geschwindigkeit nicht mehr das größte Problem. Die Herausforderung ist vielmehr die Entscheidung, was überhaupt lohnenswert ist zu bauen.
Es gibt diesen Punkt im Leben fast jedes entwickelten Systems, an dem die Funktionsliste ein Eigenleben entwickelt.
„Der Kunde hat danach gefragt.“
„Die Konkurrenz hat es.“
„Das dürfte nicht so schwer sein.“
„Wenn wir dieses Modul schon haben, fügen wir noch …“
„KI macht das schnell.“
Und plötzlich landet eine weitere Funktion im Backlog. Dann noch eine. Und noch eine. Nach ein paar Jahren hat das Unternehmen eine Anwendung, die fast alles kann. Nur dass es für Nutzer immer schwieriger wird, das zu finden, was sie wirklich brauchen.
Das ist nicht nur ein UX-Problem. Das ist ein Geschäftsproblem.
Wenn mehr Funktionen keinen besseren Produkt mehr bedeuten
Jahrelang war die Logik der Softwareentwicklung recht einfach: Wenn Nutzer neue Funktionen brauchen, fügen wir neue Funktionen hinzu. Klingt vernünftig.
Das Problem beginnt, wenn Produktentwicklung nur noch an der Anzahl gelieferter Features gemessen wird. Dann beginnt das Team, nicht nach dem Wert für den Nutzer zu optimieren, sondern danach, wie viele Dinge man „fertigstellen“ konnte.
Es entsteht eine sogenannte Feature Factory
Dieses Phänomen ist nicht neu. Neu ist das Tempo, in dem sich das heute entwickeln kann.
KI verkürzt den Weg vom Gedanken zum funktionierenden Prototyp erheblich. Atlassian beschreibt die Veränderung klar: Mit Entwickleragenten kann die Zeitspanne von „wir wissen, was wir bauen wollen“ bis zum funktionierenden Prototyp von Wochen auf Stunden schrumpfen.
Das ist eine enorme Chance. Aber auch eine Falle.
Denn wenn Bauen günstiger und schneller wird, ist es leichter, Dinge zu bauen, die vorher niemand zu bestellen gewagt hätte.
„Wenn wir es können, dann machen wir es“
Das ist einer der teuersten Sätze in IT-Projekten. Nicht weil jede zusätzliche Funktion ein Vermögen kostet. Das Problem liegt darin, dass eine Funktion ihr Leben nicht mit der Veröffentlichung beendet.
Jedes neue Modul muss später gewartet werden. Es muss getestet werden. Es muss bei weiteren Änderungen berücksichtigt werden. Es muss dokumentiert werden. Fehler müssen bearbeitet werden. Nutzer müssen geschult werden. Es muss ins UX eingeordnet werden. Seine Sicherheit muss überwacht werden. Es muss geprüft werden, ob spätere Änderungen etwas kaputt machen.
Deshalb sind die Kosten einer Funktion nicht nur die Kosten ihrer Erstellung. Es sind auch die Kosten ihres zukünftigen Bestehens.
Und genau diese Kosten sieht man sehr oft nicht in dem Moment, in dem jemand sagt:
„Dann fügen wir das noch hinzu …“
Die teuerste Funktion kann diejenige sein, die niemand nutzt
Stellen wir uns ein Unternehmen vor, das ein B2B-Panel entwickelt.
Kunden können Bestellungen aufgeben, Bestellhistorien einsehen, Dokumente herunterladen und ihren Ansprechpartner kontaktieren.
Es entsteht die Idee für ein umfangreiches Reporting-System. Das Team entwirft es. Entwickler bauen es. Diagramme, Filter, Exporte, Zusammenstellungen und dutzende zusätzliche Parameter entstehen. Die Funktion kommt in Produktion.
Und dann stellt sich heraus, dass die meisten Kunden einfach nur wissen wollen: wie viel ich gekauft habe, was unterwegs ist und wie der Preis ist.
Der Rest war eine Annahme. Sie brauchen es nicht. Das ist ein wichtiger Unterschied.
Ein Kunde kann um eine Funktion bitten. Das heißt nicht automatisch, dass diese Funktion sein Problem löst.
„Die Konkurrenz hat das“
Das ist ein weiterer Klassiker.
Ein Unternehmen analysiert die Konkurrenz und sieht ein neues Modul.
Und es beginnt: „Das müssen wir auch haben.“
Dabei kann die Konkurrenz ein völlig anderes Geschäftsmodell, eine andere Kundengruppe, andere Verkaufsprozesse und eine andere Produktstrategie haben.
Eine Funktion, die in einem System Sinn ergibt, kann in einem anderen komplett überflüssig sein.
Das ist besonders wichtig bei maßgeschneiderten Projekten. Es gibt keinen universellen Funktionskatalog, der jede Anwendung gut macht.
Ein System für einen Industriehersteller sollte nicht wie eine Plattform für ein Trainingsunternehmen gestaltet werden.
Ein CRM für Vertriebsmitarbeiter sollte nicht wie ein B2B-Panel für Stammkunden funktionieren.
Ein Onlineshop, der Premiumprodukte verkauft, braucht möglicherweise ein völlig anderes Einkaufserlebnis als ein Shop, dessen Hauptargument der Preis ist.
Software sollte aus dem Geschäftsmodell folgen, nicht aus dem Funktionskatalog der Konkurrenz.
KI verändert hier wirklich viel
Und genau deshalb ist dieses Thema heute besonders interessant.
Noch vor einigen Jahren musste eine Idee für eine neue Funktion viele Etappen durchlaufen, bevor ein Nutzer sie sehen konnte.
Analyse.
Design.
UX.
Development.
Tests.
Rollout.
Heute können viele dieser Etappen durch KI deutlich beschleunigt werden. Wir können schneller Prototypen erstellen. Schnittstellen schneller vorbereiten. Code schneller schreiben. Tests schneller generieren. Daten schneller analysieren.
Und genau deshalb ist allein die Geschwindigkeit der Entwicklung keine ausreichende Wettbewerbsvorteil mehr.
Wenn jeder schneller bauen kann, hat derjenige einen Vorteil, der besser auswählt, was gebaut werden soll.
Atlassian weist in seiner Studie zur Zukunft des Produktmanagements auf dieses Paradoxon hin: KI erhöht das Arbeitstempo, aber höhere Geschwindigkeit allein führt nicht automatisch zu besseren Produkten. Gleichzeitig gaben 89 % der von Atlassian befragten Führungskräfte an, dass KI ihre Arbeitsgeschwindigkeit erhöht habe, während nur 6 % sich sicher fühlten, den konkreten ROI von KI für die gesamte Organisation zu bestimmen.
Das zeigt sehr gut den Unterschied zwischen schnelleres Tun und besseren Ergebnissen.
Zuerst das Problem. Erst dann die Funktion
Guter Produktprozess sollte mit der Frage beginnen: Welches Problem versuchen wir zu lösen?
Nicht: „Welche Funktion sollen wir hinzufügen?“
Das klingt wie ein kleiner Unterschied. In der Praxis verändert es alles.
Wenn ein Kunde sagt: „Wir brauchen eine mobile App“,
dann sollte man fragen: Warum?
Vielleicht braucht er tatsächlich eine App. Aber vielleicht ist das Problem fehlender komfortabler Zugriff auf das Panel am Telefon. Vielleicht reicht ein gut gestaltetes responsives Interface. Vielleicht eine PWA. Vielleicht ein mobiler Modul für einen einzelnen Prozess. Oder die App ist nötig — aber aus ganz anderen Gründen als der Kunde ursprünglich annahm.
Dasselbe gilt für Funktionen.
„Wir brauchen automatische Berichte.“ — Warum?
„Weil die Vertriebsmitarbeiter Zeit verlieren.“ — Womit?
„Beim Abschreiben von Daten aus dem System.“
Und plötzlich stellt sich heraus, dass das Problem nicht der fehlende Bericht ist. Das Problem ist fehlende Integration.
Gute Analyse kann Monate an Development sparen.
Manchmal ist die beste Funktion keine Funktion
Das klingt paradox, aber genau das sollte die Rolle eines erfahrenen Technologiepartners sein.
Nicht nur umsetzen. Sondern auch Annahmen hinterfragen, wenn es Gründe dafür gibt.
Wenn ein Kunde mit einer Liste von zwanzig Funktionen kommt, sollte ein Softwarehaus diese nicht automatisch wie eine in Stein gemeißelte technische Spezifikation behandeln.
Es sollte fragen: Welche dieser Funktionen lösen ein echtes Problem? Welche sind kritisch? Welche steigern den Verkauf? Welche verkürzen die Arbeit? Welche verbessern den Kundenservice? Welche sind gesetzlich oder operativ erforderlich? Welche sind nur „ein nettes Extra“?
Und vor allem: Woran erkennen wir, dass eine Funktion erfolgreich war?
Ohne diese letzte Frage ist es leicht, ein Produkt zu bauen, das ständig wächst, aber man weiß nie, ob es wirklich besser wird.
Das Produkt muss lernen, „nein“ zu sagen
Im guten Product Development ist genauso wichtig wie die Liste der zu bauenden Dinge die Liste der Dinge, die wir nicht bauen. Das erfordert Mut.
Denn es ist einfach zu sagen: „Ja, wir machen das.“
Schwieriger ist es zu sagen: „Auf Basis dessen, was wir wissen, sehen wir noch keinen Grund, dafür zu bezahlen.“
Noch schwieriger ist es, dies einem Kunden zu sagen, der gerade mit einer fertigen Idee hereingekommen ist.
Aber genau hier beginnt partnerschaftliche Zusammenarbeit.
Ein Softwarehaus sollte nicht nur ein Team sein, das Anweisungen in Code übersetzt. Es sollte dem Kunden helfen, technologische Entscheidungen zu treffen.
Manchmal bedeutet das, die Funktion zu entwerfen.
Manchmal, sie zu vereinfachen.
Manchmal, sie durch eine andere Lösung zu ersetzen.
Und manchmal, vollständig auf die Idee zu verzichten.
Wie erkennt man eine Funktion, die man wahrscheinlich nicht braucht?
Es gibt keinen magischen Test, aber einige Fragen können den Enthusiasmus schnell dämpfen.
Wer genau soll das nutzen?
Wenn die Antwort „alle“ lautet, sollte man präzisieren.
Welches Problem lösen wir?
Wenn die Antwort „es wäre bequemer“ ist, bedarf das Problems wahrscheinlich weiterer Analyse.
Wie oft wird der Nutzer das nutzen?
Einmal im Jahr? Einmal im Monat? Täglich?
Gibt es einen einfacheren Weg, dasselbe Problem zu lösen?
Diese Frage ist besonders wichtig.
Wie messen wir den Effekt?
Mehr Umsatz? Weniger Arbeit? Kürzere Prozesse? Weniger Fehler? Höhere Retention?
Was passiert, wenn wir die Funktion nicht bauen?
Wenn die Antwort „eigentlich nichts“ lautet, haben wir vielleicht gerade die Funktion gefunden, die nicht gebaut werden muss.
Nicht jede Nutzeranfrage gehört ins Backlog
Das ist auch eine wichtige mentale Veränderung.
Nutzerfeedback ist unbezahlbar. Aber Feedback ist keine automatische Produktspezifikation.
Der Nutzer spricht über sein Problem aus der Perspektive seiner eigenen Erfahrung.
Er kann sagen: „Ich brauche Button X.“
Die Rolle des Produktteams ist nicht, gedankenlos Button X zu bauen.
Die Rolle des Teams ist zu verstehen: Warum der Nutzer ihn braucht.
Erst dann kann entschieden werden, ob die beste Lösung wirklich Button X ist.
Vielleicht ist die Lösung Automatisierung.
Vielleicht Integration.
Vielleicht eine Prozessänderung.
Vielleicht ein besseres Interface.
Vielleicht Nutzerbildung.
Und manchmal tatsächlich eine neue Funktion.
Das ist der Unterschied zwischen feature delivery und product development.
Daten können ebenfalls sagen: „Entfernen wir das“
Produktentwicklung sollte nicht beim Hinzufügen enden.
Man muss auch auf das Bestehende schauen.
Welche Funktionen werden genutzt?
Welche werden ignoriert?
Wo steigen Nutzer aus?
Welche Prozesse nehmen am meisten Zeit in Anspruch?
Welche Elemente erzeugen die meisten Supportanfragen?
Welche Funktionen erhöhen die Conversion?
Und welche verkomplizieren nur das Interface?
Manchmal ist das beste Entwicklungsprojekt nicht, ein weiteres Modul hinzuzufügen, sondern drei unnötige zu entfernen. Das kann das UX mehr verbessern als ein weiterer Monat Entwicklung.
KI kann auch hier helfen
Interessanterweise muss KI nicht nur zum Erstellen von Funktionen dienen.
Sie kann auch dabei helfen zu analysieren, ob Funktionen Sinn machen.
Sie kann Nutzerfeedback analysieren.
Anfragen gruppieren.
Wiederkehrende Probleme erkennen.
Supportdaten auswerten.
Gespräche mit Kunden zusammenfassen.
Dem Team helfen, Hypothesen zu vergleichen.
Lösungsvarianten vorbereiten.
Die Analyse des Nutzerverhaltens unterstützen.
Paradoxerweise kann also die beste Nutzung von KI im Product Development manchmal darin bestehen, nicht schneller eine weitere Funktion zu bauen.
Sondern darin, dass wir schneller entdecken, dass wir sie nicht bauen sollten.
Web24: zuerst fragen wir "warum?"
Jedes Softwareprojekt beginnt mit einem Bedarf.
Manchmal weiß der Kunde genau, was er braucht.
Manchmal hat er schon eine Spezifikation.
Manchmal kommt er nur mit einem Problem: „Dieser Prozess kostet uns täglich drei Stunden.“
Und das ist ein sehr guter Ausgangspunkt.
Denn dann können wir nicht darüber nachdenken, wie wir die vorgeschlagene Lösung codieren, sondern wie wir das Problem am besten lösen.
Das unterscheidet maßgeschneiderte Softwareerstellung von der Zusammenstellung eines Produkts aus fertigen Funktionen.
Bei Web24 geht es nicht darum, dass jede Anwendung möglichst viele Funktionen hat.
Es geht darum, dass sie jene Funktionen hat, die für genau dieses Geschäft wirklich notwendig sind.
Deshalb können zwei ähnliche Systeme völlig unterschiedlich aussehen und funktionieren.
Weil sich Prozesse unterscheiden.
Weil sich Nutzer unterscheiden.
Weil sich Ziele unterscheiden.
Weil sich Vertriebswege unterscheiden.
Weil sich der Kundenservice unterscheidet.
Und weil sich das Problem unterscheidet, das die Software lösen soll.
Das teuerste Backlog ist das, das niemand in Frage stellt
In der Welt der KI können wir in eine sehr interessante Phase der Softwareentwicklung eintreten.
Die Technologie wird immer besser auf die Frage antworten: „Wie bauen wir das?“
Und der Mensch wird immer besser die Frage beantworten müssen: „Sollten wir das überhaupt bauen?“
Das könnte eine der wichtigsten Veränderungen in der Softwareentwicklung sein.
Denn wenn Kosten und Aufwand für das Bauen einer weiteren Funktion sinken, wächst die Versuchung, sie hinzuzufügen.
Und damit wächst die Bedeutung von Product Discovery, UX, Datenanalyse, Nutzergesprächen und strategischem Produktmanagement. Gartner weist darauf hin, dass die schnelle Produktentwicklung durch KI unter anderem zu Problemen mit strategischer Ausrichtung und wachsendem technischen Schuldenstand führen kann, wenn das technologische Tempo nicht mit Produktmanagement einhergeht.
Deshalb gehört die Zukunft nicht allein denen, die schneller bauen können. Sie gehört auch denen, die besser auswählen, was gebaut werden soll.
Denn manchmal lautet die beste technische Entscheidung nicht: „Fügen wir noch eine Funktion hinzu.“
Sondern: „Prüfen wir zuerst, ob wir sie wirklich brauchen.“
