Angesichts des Tempos der KI und unserer Nutzungssignale ergibt eine feste Roadmap darüber hinaus schlicht keinen Sinn mehr.
Dieses Meeting basiert auf zwei Inputs: Der erste ist direktes Kundenfeedback – wie Bugs, UX-Herausforderungen und Produktlücken – das über kontinuierliche Feedback-Guides in unserer Benutzeroberfläche eingereicht wird. Obwohl diese Daten qualitativer Natur sind, können wir sie mit Pendo tatsächlich quantifizieren: Wir können messen, wie viele Nutzer auf dieselbe Frustration stoßen, wie viele dieselbe Anfrage gestellt haben und welcher Account-Wert hinter jeder Priorität steckt. Und wenn ein Nutzer besonders engagiert ist, versuchen wir, ihn zu einem Gespräch einzuladen.
Der zweite wesentliche Input sind Issues in Agent Analytics. Ich bin der Lead PM für Leo, Pendos KI-Produktassistenten. Wir nutzen Agent Analytics jede Woche, um Leo genauso zu messen, wie wir es von unseren Kunden für ihre eigenen Agenten erwarten würden. Im Folgenden teile ich zwei Beispiele, wie das in der Praxis aussieht.
Die Leitplanke, die Tausende von Nutzergesprächen scheitern ließ
Als Leo eingeführt wurde, haben wir bewusst entschieden, How-to-Fragen nicht zu unterstützen. Fragen wie: „Wie erstelle ich ein Segment?" oder „Wie aktualisiere ich meine Roadmap?" Nutzer stellten diese Fragen, und Leo verwies sie an Pendos Wissensdatenbank.
Wir haben diese Leitplanke eingebaut, weil Leo bei solchen Fragen halluzinierte. Wir hatten ihn noch nicht mit einer aktuellen Wissensquelle verbunden und wollten keine falschen Antworten liefern. Das ist die Realität kontinuierlicher Abwägungen beim Aufbau einer Roadmap und der Produktentwicklung.
Obwohl wir glaubten, verantwortungsvoll zu handeln, zeigte uns Agent Analytics schließlich, dass wir Frustration erzeugten.
Der Issue-Detektor hat es markiert, ohne dass wir danach fragen mussten: Über 60 % aller Issues in Leo ließen sich auf diese eine Ursache zurückführen. Ein Problem, verteilt über Tausende von Gesprächen, das immer wieder auftauchte. Ohne Agent Analytics hätten wir keine Möglichkeit gehabt, den Ernst dieser Lücke zu verstehen, als wir uns auf den Übergang von der geschlossenen Beta zur vollständigen Veröffentlichung vorbereiteten. Ein PM kann keine datengestützten Priorisierungsentscheidungen treffen ohne aggregierte Erkenntnisse aus allen Nutzergesprächen. Mit diesen Daten wussten wir, dass wir nach nur einem Gespräch mit Leo immer mehr Nutzervertrauen verloren.
Um das zu beheben, haben wir innerhalb von Leo einen dedizierten Wissens-Subagenten entwickelt, ähnlich wie seine anderen Subagenten für Aufgaben wie quantitative Analysen und Guide-Erstellung. Wir haben einen für Wissen hinzugefügt, ihn mit unserem aktuellen Wissensspeicher verbunden und Leo in die Lage versetzt, How-to-Fragen präzise zu beantworten, anstatt sie abzuwimmeln.
Über Nacht verschwand dieses Problem aus unserer Problemliste. Mit einem einzigen Architektur-Release gingen wir von Tausenden markierter Gespräche auf null.
Die Nutzer, für die wir nicht entworfen haben – und wie wir sie entdeckten
Leos ursprüngliches ICP war klar: Menschen, die Pendo nicht kennen, keine Zeit haben, Analytics zu erlernen, und schnelle Antworten auf einfache Fragen möchten. Als wir Leo im vergangenen Jahr einführten, zeigte sich diese Gruppe.
Allerdings tauchte auch eine zweite Gruppe auf – und leider eine, für die wir nicht gebaut hatten: Analytics-Power-User. Pendo-Champions, die Leo betrachteten und sagten: Du hast gerade eine konversationelle Benutzeroberfläche über all meine Daten gelegt. Sie begannen sofort, komplexe Analytics-Fragen zu stellen, wie etwa die Analyse von App-übergreifenden Conversion-Funnels und Abfragen über große Datensätze. Leo konnte damit nicht gut umgehen. Wir wussten, dass diese Einschränkungen existierten, aber wir wussten nicht, wie oft Nutzer auf sie stießen oder welche Lücken die meiste Reibung verursachten.
Mit Agent Analytics erstellten wir nachverfolgte Anwendungsfälle, um die Aufteilung zu quantifizieren: Wie oft stellen Nutzer einfachere Fragen, die Leo gut beantwortet, und wie oft befinden sie sich in einem Bereich, in dem die Prompts komplexer sind und die Erfahrung abbricht? Wir kategorisierten nach Komplexitätsstufe und nach Absicht: Akquisitionsfragen, Adoptionsfragen, Conversion-Fragen usw.
Pendos Sr. Director of Analytics und ich setzten uns mit diesen Daten zusammen und nutzten sie, um die Reihenfolge festzulegen, in der wir welche Funktionen entwickeln würden. Das Beste daran war, dass unsere Agent Analytics-Daten die Reihenfolge bestimmten, in der wir bauen würden. Was, wie jeder PM bestätigen kann, dem Bauchgefühl oder der lautesten Stimme im Raum weit vorzuziehen ist. Wir wussten objektiv, wie häufig Nutzer auf jede Lücke stießen und welche Auswirkungen wir von jeder Verbesserung erwarten konnten.
Letztendlich erweiterten wir Leos Werkzeugset, um die komplexeren quantitativen Anfragen zu bewältigen, die die zweite Gruppe stellte.
Evals zeigten, dass wir bereit waren – aber wir brauchten mehr als das
Bevor wir die Tool-Änderungen an Leos Tausende von Nutzern auslieferten, mussten wir wissen, ob sie die Erfahrung wirklich verbessern oder das Problem nur verlagern würden. Unsere Evals sahen gut aus (durchgehend grün).
Das Schwierige daran ist, dass wir Evals allein nicht mehr vertrauen. Im letzten Jahr hat unser Team Leo kontinuierlich weiterentwickelt und verbessert, und wir haben festgestellt, dass man in der Test-Automatisierungssuite alles auf Grün haben kann – und dann stellt der erste echte Nutzer etwas, das die Tests nie antizipiert haben, und der Agent versagt. Evals sind kontrolliert, aber Nutzer sind es definitiv nicht. Hinzu kommt die nicht-deterministische Natur dieser Modelle: Wir könnten jeden Test bestehen und trotzdem beim ersten echten Gespräch scheitern.
Um diese Hürde für eine sinnvolle Optimierung zu überwinden, führten wir in Agent Analytics ein Experiment durch, bevor wir die quantitativen Änderungen für alle Nutzer ausrollten. Wir A/B-testeten die neuen Tools mit 20 % unserer Nutzerbasis. Das Ergebnis: ein Rückgang der Fehlerrate um 67 % für diese Gruppe – bei echten Nutzern, nicht bei synthetischen Bots. Und da es mit dem breiteren Kontext des Nutzerverhaltens verbunden ist, konnten wir Nutzerengagement und KI-Qualitätsmetriken direkt daneben verfolgen.
Dies gab uns die Überzeugung, diese bedeutenden Backend-Änderungen breiter auszurollen. Anstatt uns auf übermäßig optimistische Bewertungen oder ein einmaliges Daumen-hoch von einem internen Testnutzer zu verlassen, haben wir eine objektive, skalierbare Möglichkeit, jedes neue Update für Leo mit Zuversicht zu veröffentlichen.
Was wir seitdem beobachtet haben
Leos neue Besucherakzeptanz ist in den letzten 60 Tagen allein um +16,1 % gestiegen. Noch bedeutsamer für einen PM: Unsere wöchentlich wiederkehrenden Besucher sind um 61,3 % gestiegen. Das zeigt mir, dass Leo für unser Publikum einen echten Mehrwert bietet und kein einmaliger Neuheitstrend ist.
Obwohl die Bindungsrate steigt, gibt es noch mehr zu tun. Ich bin dankbar, dass wir einen konsistenten Prozess etabliert haben, um die Zeit meines Teams und der Ingenieure kontinuierlich auf Basis echter Nutzersignale zu priorisieren: das Problem in AA finden, die Grundursache ermitteln, die richtige Infrastrukturänderung vornehmen, vor dem Rollout mit einem Experiment bestätigen und dann unsere Leitsterne wachsen sehen.
Diese Schleife ist unser Ansatz zur Verwaltung von Leo – und dieselbe Schleife würde ich jedem PM empfehlen, der einen KI-Agenten entwickelt.
Verbinden Sie Verhaltenskontext mit jedem Agenten, den Sie entwickeln oder kaufen, und messen Sie dann, ob er funktioniert, mit Pendo für KI-Agenten. Mehr erfahren.
