waar dit artikel over gaat. een build-in-public-blik op één traject. een productteam bij een series-b-fintechbedrijf had een ai-functie die goed demode maar niet naar productie kwam. we bouwden hem in 5 weken om tot een productiefunctie. hij ging naar 100% van de gebruikers, en supporttickets over die functie daalden na de lancering met 60%.
het prototype bestond al. een productmanager had het in een weekend gebouwd in lovable. het zag er echt uit. het demode goed tijdens de all-hands. daarna bleef het vier maanden liggen, want er echt uitzien en betrouwbaar zijn zijn twee verschillende dingen.
disclosure vooraf: de klant is geanonimiseerd. de rollout van 5 weken en de daling van 60% in tickets zijn de daadwerkelijk opgeleverde cijfers uit het traject, geen prognoses. we noemen ze niet bij naam omdat het contract dat niet toestaat. het gaat hier om de bouw, niet om het logo.
#waarom loopt een goed prototype vast voor het productie bereikt?
omdat het prototype een andere vraag beantwoordt dan productie. het prototype bewijst dat het idee één keer kan werken, op een schone invoer, met de oprichter achter het stuur. productie moet werken op rommelige invoer, om 2 uur 's nachts, zonder dat iemand meekijkt, en verdedigbaar zijn wanneer een klant betwist wat de functie heeft gezegd. in dat gat sneuvelen de meeste v0- en lovable-bouwsels. niet omdat het idee fout was. omdat er geen pad was van demo naar iets waar je je naam onder durft te zetten.
hoe breng je een ai-prototype naar productie?
begin bij het echte probleem, niet bij de demo-ui. bouw de functie opnieuw op binnen je eigen product, met streamende antwoorden, een testsuite die antwoorden toetst aan bekende goede gevallen, audit logging, en menselijke controle waar dat telt. voor dit fintechteam kostte dat pad 5 weken en daalden de tickets over de functie met 60%.
#wat hebben we precies gebouwd?
we begonnen niet bij het chatvenster uit het prototype. we begonnen bij hun supportwachtrij. de drie tickets met het hoogste volume over deze functie wezen allemaal op hetzelfde: gebruikers konden geen duidelijk antwoord krijgen zonder support te mailen. dus bouwden we de functie om die drie vragen als eerste te beantwoorden, binnen hun eigen product en eigen ontwerpsysteem, geen los aangeplakte widget.
- streamende antwoorden, zodat de functie direct aanvoelt in plaats van een laadanimatie. het antwoord verschijnt terwijl het wordt gevormd.
- een testsuite die de functie bij elke wijziging test tegen bekende goede antwoorden, zodat een aanpassing aan één prompt niet stiekem een ander geval kapotmaakt.
- audit logging bij elk antwoord, zodat support de exacte invoer en uitvoer kan opzoeken wanneer een klant betwist wat de functie heeft gezegd.
- in-product ux, gebouwd binnen hun ontwerpsysteem, zodat het aanvoelt als onderdeel van het product, niet als een chatvenster dat er iemand op heeft geplakt.
we are
we bouwden een vastgelopen prototype om tot een gelanceerde functie met streaming, een testsuite, audit logging en native in-product ux.
we aren't
we hebben geen generiek chatvenster boven op het product geplakt en dat een ai-functie genoemd.
#waarom daalden de supporttickets met 60%?
omdat we de functie achterstevoren vanuit de tickets hebben gebouwd. de drie vragen die het meeste supportvolume veroorzaakten, zijn nu precies de drie die de functie in het product beantwoordt, voordat een gebruiker iemand hoeft te mailen. het auditlogboek vertelt ons welke vragen de functie afhandelt en welke nog bij een mens terechtkomen. datzelfde logboek is hoe we wisten dat de daling van 60% echt was en geen seizoenseffect. het wordt gemeten, per tickettype, tegen de acht weken voor de lancering.
de testsuite is de reden dat de daling standhield. voor de lancering werd elke wijziging getoetst aan de bekende goede antwoorden. een promptaanpassing die één geval oploste en twee andere brak, werd opgemerkt voordat die een gebruiker bereikte. dat is het verschil tussen een demo die één keer werkt en een functie die elke keer werkt. productteams noemen dit shippen. daar zijn we het mee eens. meer over hoe we naar productwerk kijken staat hier.
#hoe lang duurde het om te lanceren?
vijf weken, van prototype naar 100% van de gebruikers. week één was het auditlogboek en de testsuite, want je kunt niet verbeteren wat je niet meet. weken twee en drie bouwden de drie belangrijkste ticketantwoorden opnieuw op binnen het product. week vier was de ux binnen het ontwerpsysteem en de streaming. week vijf was een gefaseerde uitrol, telkens tien procent van de gebruikers erbij, waarbij we het auditlogboek in de gaten hielden op alles wat de tests hadden gemist. geen big-bang-lancering. geen herbouw van een heel kwartaal.
het ging van iets wat we demoden naar iets wat we lanceerden, en de supportwachtrij is hoe we weten dat het werkte.
dat is wat de meeste van onze build-in-public-casestudies gemeen hebben. de winst zit niet in het model. die zit in de saaie onderdelen eromheen: de testsuite, het auditlogboek, de reviewpoorten, de uitrol die je kunt volgen. dat is wat een prototype omzet in iets wat je aan elke gebruiker kunt tonen. als jij een v0- of lovable-bouwsel hebt dat blijft steken bij de demo zonder duidelijk vervolg, is dat precies het gat dat we dichten. vertel ons wat je aan het bouwen bent.