This blog post is also available in English
TL;DR
Experimentierkultur ist kein universelles Paradigma. Sie entstand in Consumer-Internet-Unternehmen mit Ad-Revenue-Modellen. Die meisten Softwareprojekte existieren nicht in diesem Umfeld.
Output ist nicht Outcome. A/B-Tests zeigen, ob eine Änderung eine Metrik bewegt – nicht ob es die richtige Metrik ist.
Metriken ersetzen kein Nutzerverständnis. Implizites Wissen entsteht durch Beobachtung und Zeit, nicht durch strukturierte Interviews.
Unsichtbare Stakeholder werden ignoriert. Wer die Konsequenzen von Software trägt, taucht in keinem A/B-Test auf.
Dabei sein schlägt messen. Direktes Erleben und Beobachtung im echten Kontext liefern besseres Verständnis als Tests.
Agentische Entwicklung verstärkt das Problem. Schnellere Iteration hilft nicht, wenn die zugrundeliegenden Annahmen falsch sind.
In meinem Blogpost «Erst agil, dann agentisch» habe ich argumentiert, dass KI bestehende organisationale Fähigkeiten verstärkt, und dass schnelleres Experimentieren zu den möglichen Vorteilen für gut aufgestellte Teams gehört. Wer schneller umsetzen kann, der kann im gleichen Zeitraum mehr Experimente durchführen und somit mehr lernen. Doch schnelleres Experimentieren ist nicht automatisch besser. In vielen Kontexten hängt erfolgreiche Produktentwicklung von ganz anderen Faktoren ab.
Woher Experimentierkultur kommt
Es lohnt sich, einen Blick darauf zu werfen, in welchem Umfeld die Kultur des Experimentierens eigentlich entstanden ist. Sie hat sich in den Consumer-Internet-Unternehmen der 2000er und 2010er Jahre herausgebildet, wo sehr spezifische Bedingungen galten: Millionen von täglichen Nutzenden, ein enger Zusammenhang zwischen Produktentscheidungen und messbaren Ergebnissen, und ein Geschäftsmodell, das auf Engagement und Conversion optimierte. In diesem Kontext ergaben kontrollierte Experimente Sinn. Statistische Signifikanz war in Tagen erreichbar, und die Metrik, die optimiert wurde, etwa Klicks, Käufe oder Verweildauer, war eng mit dem Umsatz verbunden. Lean Startup, Growth Hacking und die DevOps-Bewegung kristallisierten sich in diesem spezifischen Umfeld heraus und wurden als universelle Methodik verpackt.
Heute ist Experimentierkultur vor allem dort zu Hause, wo dasselbe Grundprinzip gilt: Social Media, digitale Medienangebote, Free-to-play-Spiele, also Angebote, deren Geschäftsmodell auf Aufmerksamkeit und Ad-Revenue basiert. In diesen Kontexten sind die Nutzenden nicht die Kundschaft. Die werbetreibenden Unternehmen sind die Kundschaft, und die Nutzenden sind das Produkt. Engagement zu maximieren ist dann kein Proxy für Nutzerwert, es ist das eigentliche Ziel. Der Interessenskonflikt zwischen Unternehmens-Outcome und dem Outcome der Nutzenden stellt sich gar nicht.
Melissa Perri argumentiert, dass gute Produktarbeit genau diese Schnittmenge findet: Outcomes, die gleichzeitig für das Unternehmen und für die Nutzenden Wert schaffen[1]. Das ist anspruchsvoll und setzt voraus, dass man beide Seiten versteht. Es setzt auch voraus, dass die Nutzenden die Kundschaft sind. Experimentierkultur im Ad-Revenue-Kontext hat dieses Problem elegant umgangen.
Das Problem ist, dass die meisten Softwareprojekte nicht in diesem Umfeld stattfinden.
Enterprise-Software und domänenspezifische Anwendungen haben andere Erfolgskriterien, und eine grundlegend andere Beziehung zwischen dem was sich messen lässt und dem was tatsächlich wichtig ist. Perri nennt das Ergebnis die Build Trap: Organisationen, die sich auf Output-Metriken fixieren, verlieren den Faden zwischen dem, was sie bauen, und dem, was Nutzende eigentlich brauchen. Es werden Features geliefert, die Velocity ist hoch, aber die Software bedient nicht die eigentlichen Bedürfnisse der Nutzenden.
Output statt Outcome
Baldur Bjarnason beschreibt in «Out of the Software Crisis»[2] wie das in der Praxis aussieht:
„We decide on the problem without checking to make sure it’s a real problem for our end users. We then design without researching the nature and structure of the problem we’re trying to address. We ship without testing to see if it actually does the job it’s supposed to. Only then do we do some actual testing, often A/B tests. We throw two half-baked unfinished designs into a functional shipping application that people rely on to do their work and use Data™ to see which unmitigated disaster is marginally less disastrous for the working lives of those held hostage by our applications."
Der erste Satz ist dabei der entscheidende. Nicht zu prüfen, ob man das richtige Problem löst, ist Output-Orientierung in ihrer reinsten Form. Man misst was sich leicht messen lässt, nicht was wichtig ist.
Teresa Torres macht die Konsequenz deutlich: Bei Continuous Discovery[3] geht es nicht darum, beliebige Hypothesen schneller zu validieren. Es geht darum, Verständnis zu entwickeln, bevor überhaupt klar ist, was es zu testen lohnt. A/B-Tests sagen einem ob eine bestimmte Änderung eine bestimmte Metrik bewegt. Sie sagen einem nicht ob man die richtige Metrik bewegt, oder ob die Metrik irgendetwas mit dem verbindet was Nutzende tatsächlich interessiert.
Bjarnason, mit Bezug auf Deming[4], nennt das Tampering: man reagiert auf Symptome als wären sie Ursachen. Wenn die zugrundeliegende Annahme falsch ist, optimiert A/B-Testing nur gründlicher in die falsche Richtung. A/B-Tests sind wertvoll, wenn die Voraussetzungen stimmen. Zu oft jedoch werden sie eingesetzt, um echtes Nutzerverständnis zu ersetzen statt zu ergänzen.
Unsichtbare Stakeholder
A/B-Tests in hoher Frequenz ohne eine entsprechende Grundlage können allenfalls einen Glückstreffer landen. Wie kommt man also zu echtem Nutzerverständnis?
In meinem Blog-Post «Warum sich Domänenwissen nicht extrahieren lässt» habe ich argumentiert, dass Domänenwissen oft nicht bewusst abrufbar ist und sozial verteilt, also das, was Polanyi «tacit knowledge» nennt. Dasselbe gilt für Nutzerwissen. Nutzende können oft nicht artikulieren was sie wirklich brauchen, aber sie wissen es wenn sie es erleben. Metriken sind der Versuch, dieses implizite Wissen durch Verhaltensdaten zu ersetzen.
Torres rät in «Continuous Discovery Habits» zu regelmäßigen Interviews mit Nutzenden und beschreibt, welche Fallstricke es zu beachten gibt und wie man die richtigen Fragen stellt, um dieses implizite Wissen hervorzubringen: Allgemeine Fragen verleiten Menschen dazu, das generalisierte Selbstbild zu aktivieren, anstatt über ihr tatsächliches Verhalten zu reflektieren. Menschen sind schlecht darin, zu wissen, was sie typischerweise tun, aber gut darin, sich an konkrete Episoden zu erinnern. Anstatt zu fragen «Welche Kriterien sind dir wichtig, wenn du ein Restaurant auswählst?», sollte man also lieber sagen: «Erzähl mir vom letzten Mal, als du mit jemandem essen gegangen bist.»
Tools wie BMAD stellen durchaus auch Discovery-artige Fragen, etwa nach dem Problem, dem Marktumfeld und den Nutzenden. Aber sie komprimieren einen Prozess der Zeit braucht. Die Antworten, die dabei entstehen, sind das, was Befragte in diesem Moment bewusst abrufen können, nicht das, was durch Beobachtung, Iteration und Inkubation über Zeit entsteht. Und selbst wenn BMAD die richtigen Menschen befragen würde, würde die Fragestruktur systematisch das hervorbringen, was Nutzende glauben zu tun, nicht, was sie tatsächlich tun. Das implizite Wissen hingegen bleibt unsichtbar.
Leider arbeiten viele Organisationen aktiv dagegen, dieses Nutzerverständnis aufzubauen, indem sie Produktteams und Entwickler:innen bewusst von den Nutzenden abschirmen.
Und selbst wenn Interviews mit echten Nutzenden stattfinden, kommt hinzu, dass eine Software neben denjenigen, die sie direkt benutzen, auch indirekt Betroffene hat, die das System gar nicht selbst bedienen. Ich nenne diese Personen unsichtbare Stakeholder. Selbst wenn Organisationen mit Nutzenden reden, werden diese unsichtbaren Stakeholder so gut wie nie bei Designentscheidungen berücksichtigt.
Ein Beispiel für solch einen unsichtbaren Stakeholder wäre die Person die im Supermarkt die Regale einräumt. Sie hat wahrscheinlich keinen Zugang zur Bestellsoftware. Aber wenn diese Software eine Bestellung falsch kalkuliert, macht sie Überstunden. Wenn eine neue Version ändert, wie Lagerbestände angezeigt werden, und das System sich anders verhält, als ihr Vorgesetzter erwartet, landet die Verwirrung in der Filiale. Sie ist kein Stakeholder im üblichen Sinne des Wortes. Sie ist nur diejenige, die die Konsequenzen trägt. Und ob die Software ihre Bedürfnisse gut oder schlecht bedient, wird garantiert durch keinen A/B-Test gemessen.
Dabei sein statt messen
Mein Kommilitone Jörg Niesenhaus blickte kürzlich in einem LinkedIn-Post auf seine ersten Wochen bei ALDI DX zurück. Als Teil seines Onboardings verbrachte er zwei Wochen in einer Filiale, um dort wie alle anderen Mitarbeitenden zu arbeiten: Regale einräumen, Kasse bedienen, Sonderfälle wie defekte Gefriergeräte oder Ladendiebstahl bewältigen. Seine Freunde in anderen IT-Unternehmen fragten, warum irgendjemand mehr als einen Tag damit verbringen würde. Seine Antwort: ein Tag lehrt einen die grundlegenden Prozesse. Zwei Wochen lehren einen die Randfälle, das informelle Wissen, das Kolleg:innen untereinander teilen, und vor allem, wie viel Arbeit dahintersteckt, einen einzigen Joghurt oder eine Gurke zu verkaufen. Nach sieben Jahren, sagt er, kann er Entscheidungen immer noch auf das zurückführen, was er in dieser Filiale gelernt hat.
Das ist keine Empathie. Empathie setzt eine Distanz voraus. Was ALDI DX in ihr Onboarding eingebaut hat, ist direkter: Wissen das durch das Dabei-Sein und Selbst-Erleben entsteht. Man weiß, was es bedeutet, wenn der Etikettendrucker klemmt, weil er bei einem selbst geklemmt hat. Man hat die Kassiererin erlebt, den Regaleinräumer, die Filialleiterin, die um 6 Uhr morgens die Bestellung prüft. Man hat am eigenen Leib erfahren, was es bedeutet, wenn die Software einen Sonderfall nicht kennt und man den Workaround selbst improvisieren muss.
Nicht jedes Unternehmen kann oder will seine IT-Mitarbeiter:innen zwei Wochen in die Filiale oder einen vergleichbaren Raum schicken. Aber das Prinzip dahinter lässt sich auch in abgeschwächter Form anwenden. Ethnografische Feldforschung – und ihre leichter zugängliche Variante Contextual Inquiry – setzt nicht voraus, dass man selbst die Arbeit tut. Es reicht, dabei zu sein. Die Forschenden beobachten im echten Kontext, stellen Fragen, während die Arbeit passiert, sehen die Workarounds, die niemand dokumentiert, und die Randfälle, die in keinem Interview auftauchen. Jared M. Spool nennt das Prinzip exposure hours: die systematische, regelmäßige Präsenz bei echten Nutzenden in echten Situationen.
Die Hierarchie ist also ungefähr diese: selbst die Arbeit tun ist am stärksten, weil man Akteur ist und nicht Beobachterin. Dabei sein und beobachten ist die nächstbeste Variante. Man ist im Kontext, sieht was wirklich passiert. Regelmäßige Präsenz ohne formellen Rahmen ist leichter zu organisieren und hält das Gespür lebendig. Darauf folgen kurze Interviews mit Nutzenden, wie von Torres beschrieben. Und dann, weit abgeschlagen: strukturierte Interviews und A/B-Tests. Experimentierkultur operiert zu oft ausschließlich auf dieser letzten Stufe und hält die Distanz zwischen den Menschen, die Software bauen, und den Menschen, deren Arbeitsalltag davon abhängt, strukturell aufrecht. Die Nutzenden sind eine Quelle von Verhaltenssignalen, kein Mensch mit einer Aufgabe.
Noch mehr Geschwindigkeit
Es gibt noch eine kognitive Dimension die in dieser Debatte selten auftaucht. ISO 9241–110, der internationale Standard für Interaktionsgestaltung, nennt Erwartungskonformität als eines von sieben Grundprinzipien. Ein System, das agentisch beschleunigt dauerhaft Experimente an der eigenen Oberfläche durchführt, ist strukturell nicht in der Lage, diesen Anspruch zu erfüllen. Nutzende bauen mentale Modelle von Software durch wiederholte Nutzung auf. Jedes Experiment, das etwas verändert, setzt einen Teil dieses Modells zurück. Die kognitive Last, die das erzeugt, ist real, aber in den Metriken, die den Experimenterfolg bewerten, in der Regel nicht sichtbar. Hinzu kommt: je höher die Experimentierfrequenz, desto mehr Disziplin braucht es, um gescheiterte Experimente aufzuräumen, also tote Code-Pfade, verwaiste Feature Flags, UI-Elemente, die zu einer Variante gehörten, die verloren hat.
Agentische Entwicklung macht das dringlicher. Wenn Experimentierkultur schon ein fragwürdiger Fit für die meisten Enterprise-Kontexte war, verbessern Tools, die Features schneller generieren und die Kosten für mehr Experimente senken, den Mismatch nicht, sondern verstärken ihn noch. BMAD verspricht Requirements-Discovery in Stunden, indem ein Agent die Menschen befragt, die Zugang zum Tool haben. Aber das Wissen, das in komplexen Domänen am meisten zählt, ist implizit, sozial verteilt und durch strukturierte Interviews nicht zugänglich. Die Kollegin die die Regale einräumt wird nicht in diesem Interview sitzen. Ihr Wissen wird nicht in der Spezifikation auftauchen.
Die Frage ist, was man verstehen muss, bevor Experimentieren sinnvoll wird, und ob der aktuelle Druck zur Geschwindigkeit dieses Verständnis ermöglicht oder strukturell verhindert. Nutzende können kein stabiles Verhältnis zu einer Software aufbauen, die sich ununterbrochen verändert. Manchmal ist das Klügste was man tun kann nichts zu ändern.