AI für product-teams. AI für product-teams bedeutet, ein ai-feature in die eigenen produktoberflächen zu bauen, das nutzer:innen übernehmen und weiter nutzen. Kein demo. Ein feature mit einer retentionszahl und einer support-ticket-zahl dahinter.
Die meisten product-teams haben bereits einen prototyp. Er entstand an einem wochenende mit Lovable, Bolt oder v0. Er sah im standup toll aus. Dann steckte er auf dem weg in die produktion fest.
Die lücke liegt nicht im modell. Die lücke liegt in allem drum herum. Streaming, evals, audit-logging und ein platz im produkt, an dem die nutzerin schon ist. Das ist die arbeit zwischen einem v0-screen und einem feature, das nutzer:innen behalten.
#Warum bleibt der prototyp vor dem launch stecken?
Ein prototyp beantwortet eine frage: kann das modell die sache tun. Ein produktions-feature beantwortet vier weitere. Streamt es, damit die nutzerin nicht auf einen spinner starrt. Bleibt es korrekt, wenn sich der prompt ändert. Kannst du belegen, was es einem kunden vor sechs wochen gesagt hat. Und lebt es da, wo die nutzerin ohnehin arbeitet, nicht hinter einem separaten tab.
Was ist der unterschied zwischen einem ai-prototyp und einem produktions-feature?
Ein prototyp beweist, dass das modell die aufgabe in einem demo bewältigen kann. Ein produktions-feature fügt streaming hinzu, damit antworten sofort ankommen, eine eval-suite, damit qualität hält, wenn sich prompts ändern, audit-logging, damit du belegen kannst, was gesagt wurde, und eine in-produkt-ux, damit nutzer:innen es annehmen. Der prototyp ist die einfachen 20 prozent.
#Chat-box dranschrauben oder in die eigenen oberflächen bauen?
Der standardschritt ist eine schwebende chat-blase in der ecke. Sie ist schnell ausgeliefert. Sie bleibt auch ungenutzt, weil deine nutzerin nicht zum chatten gekommen ist. Sie kam, um eine zahlung zu senden, eine buchung abzugleichen oder einen streitfall zu eröffnen.
Der bessere schritt ist, die AI in die oberfläche zu legen, wo diese aufgabe passiert. Ein sinnvoller standardwert im formular. Eine einklick-erklärung neben der transaktion. Eine antwort, die in dem panel erscheint, das die nutzerin ohnehin geöffnet hatte.
We are
Stennir baut ki in die produktoberflächen ein, die deine nutzer schon verwenden, mit vorab definierten kennzahlen zu akzeptanz und support-tickets, damit sichtbar wird, ob es angekommen ist.
We aren't
Stennir ist kein team, das eine generische chat-box an deine app schraubt und das ein ai-feature nennt.
#Wie sieht das bei einem regulierten fintech aus?
Zur veranschaulichung: ein fintech der series b mit einem kundenseitigen ki-assistenten, gebaut in Lovable. Er beantwortet fragen in der demo. In produktion kann er nicht gehen: kein streaming, keine möglichkeit, qualität zu messen, kein audit-trail für ein reguliertes produkt. Das ist ein hypothetisches team, kein kunde.
- streaming: antworten erscheinen token für token, damit die nutzerin eine antwort entstehen sieht statt eines lade-spinners.
- eval-suite: ein fester satz echter fragen läuft bei jeder prompt-änderung, damit qualität nicht still zurückfällt, wenn jemand den system-prompt bearbeitet.
- audit-logging: jede antwort wird mit ihren eingaben gespeichert, damit ein reguliertes fintech belegen kann, was einem kunden wann gesagt wurde.
- in-produkt-ux: der assistent antwortet in der transaktionsansicht, die die nutzerin ohnehin geöffnet hatte, nicht in einem separaten chat-tab.
Ein team in dieser lage würde das feature zuerst an einen kleinen teil der nutzer ausrollen und dann ausweiten. Zu beobachten sind die nutzung des features und die support-tickets zum abgedeckten thema, denn nutzer, die die antwort im produkt bekommen, eröffnen kein ticket, um zu fragen. Lege beide ausgangswerte vor dem start fest, damit sich die veränderung messen lässt.
Der prototyp zeigt, dass menschen es wollen. Die arbeit für die produktion sorgt dafür, dass sie es weiter nutzen. Die ticketzahl ist die, nach der ein CFO fragt.
#Wie scopest du einen build wie diesen?
Wir führen es über ki-umsetzung aus: der code gehört dir von tag eins an. Den prototyp, den du schon in v0, Bolt oder Lovable gebaut hast, behältst du als ausgangspunkt. Wir bringen ihn den rest des weges zu einem feature in deinem produkt. Umfang und konditionen klären wir im 30-minuten-gespräch.
Wenn du das muster für dein team konkret willst: die seite ki für produkt zeigt, wo ki in einem produkt ihren platz verdient, und in der ki-beratung werden solche projekte zugeschnitten. Du willst sehen, wie wir denken, bevor du dich entscheidest? Lies das journal oder buche einen 30-min-discovery-call.
