journal

ai per team di prodotto: da v0 a una feature che dura

il percorso da un prototipo ai fatto con Lovable o v0 a una feature in produzione che gli utenti adottano. cosa costruire nelle tue superfici, con il calo dei ticket di supporto come prova.

omar f.applied ai & data··4 min di lettura

ai per team di prodotto. l'ai per i team di prodotto significa inserire una feature ai nelle superfici del tuo prodotto che gli utenti adottano e continuano a usare. non una demo. una feature con un numero di retention e un numero di ticket di supporto dietro.

la maggior parte dei team di prodotto ha già un prototipo. l'ha costruito in un weekend con Lovable, Bolt o v0. sembrava ottimo nello standup. poi si è bloccato sulla strada verso la produzione.

il divario non è il modello. il divario è tutto quello che gli sta intorno. streaming, eval, audit logging e un posto nel prodotto dove l'utente è già. è questo il lavoro tra uno schermo di v0 e una feature che i tuoi utenti tengono.

#perché il prototipo si blocca prima del lancio?

un prototipo risponde a una domanda: il modello sa fare la cosa. una feature in produzione ne risponde altre quattro. fa streaming così l'utente non fissa uno spinner. resta corretta quando il prompt cambia. puoi dimostrare cosa ha detto a un cliente sei settimane fa. e sta dove l'utente già lavora, non dietro una scheda separata.

qual è la differenza tra un prototipo ai e una feature in produzione?

un prototipo dimostra che il modello sa fare il compito in una demo. una feature in produzione aggiunge lo streaming perché le risposte sembrino immediate, una suite di eval perché la qualità tenga quando i prompt cambiano, l'audit logging per dimostrare cosa è stato detto, e una ux nel prodotto perché gli utenti la adottino. il prototipo è il 20 percento facile.

#conviene aggiungere una chat box o costruire nelle proprie superfici?

la mossa predefinita è una chat bubble fluttuante nell'angolo. si lancia in fretta. resta anche inutilizzata, perché il tuo utente non è venuto per chattare. è venuto per inviare un pagamento, riconciliare un estratto conto o aprire una contestazione.

la mossa migliore è inserire l'ai nella superficie dove quel lavoro accade. un suggerimento predefinito intelligente nel form. una spiegazione con un click accanto alla transazione. una risposta mostrata nel pannello che l'utente aveva già aperto.

we are

stennir costruisce l'ai nelle superfici del prodotto che i tuoi utenti già usano, con i numeri di adozione e di calo dei ticket di supporto a dimostrare che ha funzionato.

we aren't

stennir non è un team che aggiunge una chat box generica alla tua app e la chiama una feature ai.

#come è andata con una fintech di serie b?

una fintech di serie b è venuta da noi con un assistente ai rivolto ai clienti costruito con Lovable. rispondeva alle domande in una demo. non poteva andare in produzione. niente streaming, nessun modo di misurare la qualità, nessuna traccia di audit per un prodotto regolamentato.

  • streaming: le risposte si formano token per token, così l'utente vede una risposta prendere forma invece di uno spinner di caricamento.
  • suite di eval: un insieme fisso di domande reali gira a ogni modifica del prompt, così la qualità non regredisce in silenzio quando qualcuno modifica il system prompt.
  • audit logging: ogni risposta viene registrata con i suoi input, così una fintech regolamentata può dimostrare cosa è stato detto a un cliente e quando.
  • ux nel prodotto: l'assistente risponde all'interno della vista transazione che l'utente aveva già aperto, non in una scheda chat separata.

l'abbiamo consegnato al 100% degli utenti in 5 settimane. i ticket di supporto su quella feature sono calati del 60% dopo il lancio, perché gli utenti ottenevano la risposta nel prodotto invece di aprire un ticket.

il prototipo ha dimostrato che le persone lo volevano. il build in produzione è ciò che li ha fatti continuare a usarlo. il calo del 60% dei ticket è la parte di cui si è preoccupato il nostro cfo.

head of product, fintech di serie b (engagement sotto nda)

#come si fa lo scope di un build di questo tipo?

lo gestiamo tramite il servizio di build: scope fisso, fee fissa, e il codice è tuo dal primo giorno. tieni il prototipo che hai già fatto in v0, Bolt o Lovable come punto di partenza. noi lo portiamo fino in fondo, fino a una feature nel tuo prodotto.

se vuoi lo schema per il tuo team, la pagina ai per il prodotto illustra dove l'ai guadagna il suo posto in un prodotto, e la pratica di consulenza è dove questi build vengono eseguiti. vuoi le prove prima di impegnarti? vedi il lavoro.

torna al journal
productai featureprototype-to-productionuse case

dicci cosa ti serveconsegnato.

prenota una call da 30 min