Worum es in diesem Beitrag geht. Ein Build-in-Public-Blick auf ein Engagement. Ein Produktteam eines Series-B-Fintechs hatte eine KI-Funktion, die in der Demo gut ankam, aber nicht live ging. Wir haben sie in 5 Wochen zu einer Produktionsfunktion umgebaut. Sie ging an 100 % der Nutzer, und die Support-Tickets zu dieser Funktion sanken nach dem Launch um 60 %.
Der Prototyp existierte bereits. Ein Product Manager hatte ihn an einem Wochenende in Lovable gebaut. Er wirkte echt. Er kam beim All-Hands gut an. Dann lag er vier Monate lang brach, denn echt zu wirken und zuverlässig zu sein sind zwei verschiedene Dinge.
Vorab-Hinweis: Der Kunde ist anonymisiert. Der 5-wöchige Rollout und der Rückgang der Tickets um 60 % sind die tatsächlich gelieferten Engagement-Zahlen, keine Prognosen. Wir nennen den Namen nicht, weil der Vertrag das untersagt. Es geht hier um den Build, nicht um das Logo.
#Warum stockt ein guter Prototyp vor der Produktion?
Weil der Prototyp eine andere Frage beantwortet als die Produktion. Der Prototyp beweist, dass die Idee einmal funktionieren kann, bei einem sauberen Input, mit der Gründerin am Steuer. Die Produktion muss bei unübersichtlichem Input funktionieren, um 2 Uhr nachts, ohne dass jemand zuschaut, und verteidigbar sein, wenn ein Kunde bestreitet, was die Funktion ihm gesagt hat. Genau in dieser Lücke sterben die meisten v0- und Lovable-Builds. Nicht weil die Idee falsch war. Weil es keinen Weg von der Demo zu der Sache gab, für die man seinen Namen hergibt.
Wie bringt man einen KI-Prototypen in Produktion?
Starte beim echten Problem, nicht bei der Demo-UI. Baue die Funktion innerhalb deines eigenen Produkts neu auf – mit Streaming-Antworten, einer Testsuite, die Antworten gegen bekannt-gute Fälle prüft, Audit-Logging und menschlicher Prüfung dort, wo es zählt. Für dieses Fintech-Team dauerte dieser Weg 5 Wochen und senkte die Tickets zur Funktion um 60 %.
#Was haben wir tatsächlich gebaut?
Wir sind nicht bei der Chatbox im Prototyp gestartet. Wir sind bei ihrer Support-Warteschlange gestartet. Die drei Ticket-Typen mit dem höchsten Volumen zu dieser Funktion deuteten alle auf dasselbe hin: Nutzer bekamen keine klare Antwort, ohne dem Support zu mailen. Also haben wir die Funktion so gebaut, dass sie zuerst diese drei Fragen beantwortet – innerhalb ihres eigenen Produkts und ihres eigenen Design-Systems, nicht als angeflanschtes Widget.
- Streaming-Antworten, damit sich die Funktion unmittelbar anfühlt statt wie ein Ladekreis. Die Antwort tippt sich, während sie entsteht.
- eine Testsuite, die die Funktion bei jeder Änderung gegen bekannt-gute Antworten prüft, sodass eine Anpassung an einem Prompt nicht heimlich einen anderen Fall kaputtmacht.
- Audit-Logging bei jeder Antwort, sodass der Support den exakten Input und Output ziehen kann, wenn ein Kunde bestreitet, was die Funktion gesagt hat.
- In-Product-UX, gebaut innerhalb ihres Design-Systems, sodass sie sich wie ein Teil des Produkts liest, nicht wie ein angeklebtes Chatfenster.
we are
Wir haben einen ins Stocken geratenen Prototyp in eine ausgelieferte Funktion mit Streaming, Testsuite, Audit-Logging und nativer In-Product-UX umgebaut.
we aren't
Wir haben nicht einfach eine generische Chatbox aufs Produkt gesetzt und sie eine KI-Funktion genannt.
#Warum sanken die Support-Tickets um 60 %?
Weil wir die Funktion rückwärts von den Tickets aus gebaut haben. Die drei Fragen, die das meiste Support-Volumen verursachten, sind genau die drei, die die Funktion jetzt in-product beantwortet, bevor ein Nutzer irgendjemandem mailen muss. Das Audit-Log zeigt uns, welche Fragen die Funktion abdeckt und welche noch bei einem Menschen landen. Genau dieses Log war der Grund, warum wir wussten, dass der Rückgang um 60 % real war und kein saisonaler Ausschlag. Er wird pro Ticket-Typ gegen die acht Wochen vor dem Launch gemessen.
Die Testsuite ist der Grund, warum der Rückgang hielt. Vor dem Launch lief jede Änderung gegen die bekannt-guten Antworten. Eine Prompt-Anpassung, die einen Fall behob und zwei andere kaputtmachte, wurde erkannt, bevor sie einen Nutzer erreichte. Das ist der Unterschied zwischen einer Demo, die einmal funktioniert, und einer Funktion, die jedes Mal funktioniert. Produktteams nennen das Shipping. Wir stimmen zu. Mehr dazu, wie wir an Produktarbeit herangehen, findest du hier.
#Wie lange hat der Launch gedauert?
Fünf Wochen, vom Prototyp bis zu 100 % der Nutzer. Woche eins war das Audit-Log und die Testsuite, denn man kann nicht verbessern, was man nicht misst. Wochen zwei und drei bauten die drei Top-Ticket-Antworten ins Produkt ein. Woche vier war die Design-System-UX und das Streaming. Woche fünf war ein gestaffelter Rollout, jeweils zehn Prozent der Nutzer, wobei das Audit-Log auf alles beobachtet wurde, was die Tests übersehen hatten. Kein Big-Bang-Launch. Kein quartalslanger Umbau.
Aus etwas, das wir demonstriert haben, wurde etwas, das wir ausgeliefert haben, und die Support-Warteschlange zeigt uns, dass es funktioniert hat.
Das ist es, was die meisten unserer Build-in-Public-Case-Studies gemeinsam haben. Der Gewinn ist nicht das Modell. Es sind die unspektakulären Teile drumherum: die Testsuite, das Audit-Log, die Prüf-Gates, der Rollout, den man beobachten kann. Genau das macht aus einem Prototyp etwas, das man jedem Nutzer zeigen kann. Wenn du einen v0- oder Lovable-Build hast, der in der Demo-Phase feststeckt und keinen Weg nach vorn hat, ist das genau die Lücke, die wir schließen. Erzähl uns, was du baust.