Worum es in diesem beitrag geht. Ein illustratives praxisbeispiel, kein kundenergebnis. Das fintech-team, sein produkt und jede zahl sind annahmen. Es zeigt, was nötig ist, um einen ai-prototyp, der in der demo gut aussieht, in ein feature zu verwandeln, das du allen nutzern zeigen kannst.
Angenommen, ein produktteam eines fintech in series b. Ein product manager hat an einem wochenende in lovable einen prototyp für ein ai-feature gebaut. Er wirkt echt und kam im all-hands gut an. Dann bleibt er liegen, weil echt aussehen und verlässlich sein zwei verschiedene aufgaben sind.
zu diesem beispiel: das team ist generisch, und kein kunde steht dahinter. Nichts hier ist ein geliefertes ergebnis oder eine prognose. Das design ist der punkt, nicht 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 ai-prototyp in die produktion?
Beginne beim echten problem, nicht bei der demo-oberfläche. Baue das feature in deinem eigenen produkt neu, mit streaming-antworten, einer testsuite, die antworten gegen bekannte gute fälle prüft, audit-logging und menschlicher prüfung, wo sie zählt. Miss dann die support-tickets zum feature vorher und nachher.
#Was umfasst das produktionsdesign?
Beginne nicht bei der chatbox im prototyp. Beginne bei der support-warteschlange. Angenommen, die drei tickets mit dem höchsten volumen zu diesem feature zeigen alle auf dasselbe: nutzer bekommen ohne mail an den support keine klare antwort. Baue das feature so, dass es zuerst diese drei fragen beantwortet, im eigenen produkt und design-system des teams, nicht als aufgesetztes 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 bauen einen steckengebliebenen prototyp zu einem ausgelieferten feature um, mit streaming, testsuite, audit-logging und nativer UX im produkt.
We aren't
Wir setzen keine generische chatbox auf das produkt und nennen das ein ai-feature.
#Woran erkennst du, dass das feature support-tickets senkt?
Baue das feature rückwärts von den tickets aus. Die fragen, die das meiste support-volumen erzeugen, beantwortet das feature im produkt, bevor jemand eine mail schreiben muss. Das audit-log zeigt, welche fragen das feature abfängt und welche noch bei einem menschen landen. Dasselbe log hilft einem team, einen echten rückgang von einer saisonalen delle zu unterscheiden: vergleiche das volumen je tickettyp mit einem referenzfenster vor dem launch.
Die testsuite sorgt dafür, dass jede verbesserung hält. Vor dem launch läuft jede änderung gegen die bekannten guten antworten. Eine prompt-änderung, die einen fall behebt und zwei andere bricht, wird abgefangen, bevor sie einen nutzer erreicht. Das ist der unterschied zwischen einer demo, die einmal funktioniert, und einem feature, das jedes mal funktioniert. Produktteams nennen das ausliefern. Wir auch. Mehr dazu, wie wir produktarbeit angehen, steht hier.
#In welcher reihenfolge baut man es?
Zuerst audit-log und testsuite, denn was du nicht messen kannst, kannst du nicht verbessern. Dann die antworten auf die top-tickets im produkt neu aufbauen. Dann die UX im design-system und das streaming. Zuletzt ein gestufter rollout an einen wachsenden anteil der nutzer, wobei das audit-log auf alles beobachtet wird, was die tests übersehen haben. Kein big-bang-launch.
Der maßstab: es soll von etwas, das du vorgeführt hast, zu etwas werden, das du ausgeliefert hast, und die support-warteschlange zeigt dir, ob es funktioniert hat.
Das haben unsere praxisbeispiele gemeinsam. Der gewinn ist nicht das modell. Es sind die langweiligen teile drumherum: die testsuite, das audit-log, die review-gates, der rollout, den du beobachten kannst. So wird aus einem prototyp etwas, das du allen nutzern zeigen kannst. Wenn du einen v0- oder lovable-build hast, der bei der demo festhängt und keinen weg nach vorn sieht, ist das genau die lücke, die wir schließen. sag uns, was du baust.
