Die Möglichkeiten, mit denen wir heute digitale Produkte entwickeln können, haben sich durch generative KI deutlich verändert. Aufgaben, für die früher mehrere Tage Entwicklungsarbeit notwendig waren, lassen sich inzwischen teilweise innerhalb weniger Stunden erledigen und auch kleinere Teams können dadurch in kurzer Zeit erstaunlich umfangreiche Produkte entwickeln.
Das ist zunächst einmal eine gute Entwicklung. Schließlich können wir Ideen schneller ausprobieren, Prototypen erstellen und Lösungen umsetzen, für die uns bislang vielleicht die notwendigen Ressourcen gefehlt haben. Allerdings stellt sich für mich zunehmend die Frage, ob wir durch diese neuen Möglichkeiten tatsächlich bessere Produkte entwickeln, denn nur weil wir schneller mehr Funktionen entwickeln können, bedeutet das noch lange nicht, dass wir damit auch die richtigen Dinge bauen.
Hier mal ein Beispiel aus meiner Arbeit als Product Coach: Vor einiger Zeit habe ich einen Product Owner begleitet, der mit einem sehr kleinen Team (drei Teammitglieder) und umfangreicher KI-Unterstützung ein digitales Produkt entwickelte. Das Team konnte innerhalb vergleichsweise kurzer Zeit eine beachtliche Anzahl unterschiedlicher Funktionen realisieren und die Nutzer:innen haben es sehr dankbar angenommen.
Allerdings überraschte die tatsächliche Nutzung des Produktes, als wir genauer in die Nutzungsstatistiken geschaut haben, denn viele der entwickelten Funktionen wurden kaum genutzt. Das lag nicht unbedingt daran, dass die Nutzer:innen diese Funktionen nicht kannten; die Funktionen waren teilweise sogar sehr prominent innerhalb des Produktes platziert, wurden beim Onboarding vorgestellt und auch in der Kommunikation rund um das Produkt regelmäßig hervorgehoben. Trotzdem nutzten die Menschen vor allem andere Funktionen.
Nun bedeutet eine geringe Nutzungshäufigkeit natürlich nicht automatisch, dass eine Funktion keinen Mehrwert bietet. Immerhin gibt es in beinahe jedem Produkt ein paar Funktionen, die nur selten benötigt werden, aber dann besonders wichtig sind. Dennoch darf man sich, wie auch in diesem Fall, fragen, warum man diese Funktionen überhaupt entwickelt hat. Zeit also für ein wenig Reflexion: Mein Eindruck war, dass sich die Produktentwicklung zunehmend daran orientierte, was technisch möglich war, und weniger daran, welche Probleme der Nutzer:innen tatsächlich gelöst werden sollten. Wir haben Funktionen entwickelt, weil wir sie entwickeln konnten. Nicht unbedingt, weil jemand sie brauchte.
Natürlich ist die Entwicklung von Funktionen auf Grundlage eigener Ideen oder Vermutungen nicht grundsätzlich falsch. Gerade bei innovativen Produkten wissen wir häufig noch nicht, welche Lösungen tatsächlich funktionieren werden und an etwas zu arbeiten, auf das man besonders Lust hat, ist ja auch durchaus bereichernd. Allerdings sollten wir uns darüber im Klaren sein, auf welcher Grundlage wir unsere Entscheidungen treffen.
Wenn ich mit Produktteams über neue Funktionen spreche, interessieren mich deshalb insbesondere zwei Fragen:
- Welches beobachtbare Verhalten oder welches Empfinden unserer Nutzer:innen möchten wir durch diese Funktion verändern?
- Welche Anhaltspunkte haben wir dafür, dass diese Veränderung für unsere Nutzer:innen tatsächlich relevant ist?
Dabei muss nicht jede Entscheidung durch eine umfangreiche Studie oder quantitative Nutzungsdaten abgesichert sein. Das halte ich oft gar nicht für sinnvoll. Aber qualitative Interviews, Beobachtungen oder Rückmeldungen aus dem direkten Kontakt mit Nutzer:innen können wichtige Erkenntnisse liefern und sind oft schnell(er) gemacht. Entscheidend ist für mich am Ende, dass wir zwischen Annahmen und Erkenntnissen unterscheiden und unsere Entscheidungen bewusst treffen. Das heißt für mich, dass wenn wir eine Funktion entwickeln möchten, weil wir glauben, dass sie hilfreich sein könnte, ist das zunächst eine Hypothese. Das ist vollkommen in Ordnung. Wir sollten diese Hypothese allerdings auch als solche behandeln und möglichst früh überprüfen. Problematisch wird es schließlich, wenn wir unsere eigenen Vorstellungen vom Nutzen eines Produktes mit den tatsächlichen Bedürfnissen der Menschen verwechseln.
Zugegebenerweise ist es nicht neu, dass Produktteams zu viele Funktionen entwickeln. Also grundsätzlich kein neues Phänomen und unter dem Begriff Featuritis wird dieses Problem schon seit vielen Jahren diskutiert. Mit generativer KI bekommt es allerdings eine zusätzliche Dimension. Wenn die Entwicklung einer Funktion früher mehrere Wochen gedauert hätte, mussten wir uns allein aufgrund der begrenzten Ressourcen vergleichsweise intensiv damit beschäftigen, ob sich dieser Aufwand lohnt. Heute ist diese Hürde teilweise deutlich niedriger. Warum sollten wir eine Funktion nicht einfach entwickeln, wenn uns die KI dabei unterstützt und der Aufwand überschaubar erscheint?
Die Antwort darauf ist aus meiner Sicht ziemlich einfach: Weil jede zusätzliche Funktion auch einen Preis hat.
Zunächst einmal für die Menschen, die unser Produkt nutzen. Jede zusätzliche Funktion erhöht die Komplexität eines Produktes. Nutzer:innen müssen sich orientieren, relevante Möglichkeiten erkennen und gegebenenfalls zwischen unterschiedlichen Wegen zur Lösung ihres Problems entscheiden. Dabei sollten wir vor allem nicht vergessen, dass Menschen unsere Produkte in der Regel nicht nutzen, weil sie möglichst viele Funktionen ausprobieren möchten. Sie möchten damit etwas erreichen, ein Problem lösen oder eine bestimmte Erfahrung machen. Funktionen, die dazu keinen Beitrag leisten, können von diesem eigentlichen Ziel ablenken. Im ungünstigsten Fall verschlechtern sie sogar die User Experience.
Aber auch für die Organisation hat jede Funktion ihren Preis, denn selbst wenn KI uns bei der Entwicklung unterstützt, investieren wir weiterhin Zeit und Ressourcen. Wir verbrauchen Rechenleistung und Tokens, müssen Ergebnisse überprüfen, Funktionen testen und Fehler beheben. Anschließend müssen die Funktionen gewartet und bei zukünftigen Veränderungen berücksichtigt werden. Die zunehmende Komplexität kann wiederum dazu führen, dass selbst kleinere Anpassungen aufwendiger werden. Das gilt auch für die KI-gestützte Weiterentwicklung, bei der immer mehr bestehende Zusammenhänge beziehungsweise immer größere Kontexte berücksichtigt werden müssen. Eine Funktion, die wir heute innerhalb weniger Stunden entwickeln können, kann uns deshalb noch über Jahre beschäftigen.
In diesem Zusammenhang beobachte ich noch eine weitere Entwicklung, die ich gelegentlich als Sloppisierung des Product Backlogs bezeichne. Der Begriff lehnt sich an das inzwischen verbreitete „AI Slop“ an, also massenhaft erzeugte KI-Inhalte, deren Qualität und tatsächlicher Nutzen häufig fragwürdig sind. Etwas Ähnliches kann uns auch in der Produktentwicklung passieren.
Wenn es immer einfacher wird, Ideen zu generieren, Anforderungen auszuformulieren und daraus unmittelbar Funktionen zu entwickeln, wächst die Gefahr, dass wir unsere Product Backlogs zunehmend mit Dingen füllen, deren Nutzen wir nie ernsthaft hinterfragt haben. Aber das Problem ist dabei nicht die KI. Schließlich kann sie uns auch dabei unterstützen, bessere Produktentscheidungen zu treffen, beispielsweise indem sie vorhandene Erkenntnisse strukturiert, unterschiedliche Lösungsmöglichkeiten gegenüberstellt oder uns hilft, unsere Annahmen kritisch zu hinterfragen. Problematisch wird es erst, wenn wir die Geschwindigkeit der Ideengenerierung und Umsetzung mit Fortschritt verwechseln. Ein umfangreicher Product Backlog ist schließlich ebenso wenig ein Qualitätsmerkmal wie ein Produkt mit besonders vielen Funktionen.
Je einfacher es wird, neue Funktionen zu entwickeln, desto wichtiger wird die Fähigkeit, bewusst auf bestimmte Funktionen zu verzichten. Das bedeutet nicht, dass wir weniger experimentieren sollten; ganz im Gegenteil. Wenn wir mit KI schneller Prototypen entwickeln und Hypothesen überprüfen können, sollten wir diese Möglichkeiten unbedingt nutzen. Allerdings sollten wir dabei zwischen dem Ausprobieren einer Idee und ihrer dauerhaften Integration in ein Produkt unterscheiden. Nur weil wir eine Funktion schnell entwickeln können, müssen wir sie nicht automatisch unseren Nutzer:innen zur Verfügung stellen und anschließend dauerhaft betreiben.
Vielleicht wäre es sinnvoller, zunächst herauszufinden, ob überhaupt ein relevantes Problem existiert. Vielleicht können wir dieses Problem auch durch eine Verbesserung bestehender Funktionen lösen. Und möglicherweise stellen wir fest, dass unsere ursprüngliche Idee zwar technisch interessant ist, den Menschen aber keinen nennenswerten Mehrwert bietet. Auch das wäre eine wertvolle Erkenntnis.
Als Product Coach möchte ich Produktteams deshalb nicht nur dabei unterstützen, schneller und effizienter zu werden. Mindestens ebenso wichtig ist es mir, gemeinsam mit ihnen die Qualität ihrer Produktentscheidungen zu verbessern. Dazu gehört aber eben auch, Dinge bewusst nicht zu entwickeln. Denn letztlich sollten wir unsere Produkte nicht mit möglichst vielen Funktionen füllen, sondern dafür sorgen, dass sie für die Menschen, die sie nutzen, einen tatsächlichen Unterschied machen.
Was mir am Ende wichtig ist: Nur weil wir jetzt schneller noch mehr Funktionen und Inhalte entwickeln können, heißt das nicht, dass wir die richtigen Sachen bauen. Wir müssen uns deshalb weiterhin fragen, ob Menschen diese Funktion überhaupt brauchen und ob die Funktion das Leben der Menschen wirklich bereichert.