di cosa parla questo post. uno sguardo build-in-public su un progetto. un team di prodotto fintech al round series b aveva una funzionalità ai che faceva bella figura in demo ma non riusciva ad andare in produzione. l'abbiamo ricostruita in una funzionalità di produzione in 5 settimane. è arrivata al 100% degli utenti, e i ticket di supporto su quella funzionalità sono calati del 60% dopo il lancio.
il prototipo esisteva già. un product manager l'aveva costruito in lovable in un weekend. sembrava vero. faceva bella figura nell'all-hands. poi è rimasto fermo per quattro mesi, perché sembrare vero ed essere affidabile sono due lavori diversi.
avviso pre-pubblicazione: il cliente è anonimo. il rollout di 5 settimane e il calo del 60% dei ticket sono i numeri effettivi del progetto consegnato, non proiezioni. non lo nominiamo perché il contratto lo vieta. qui il punto è la costruzione, non il logo.
#perché un buon prototipo si blocca prima della produzione?
perché il prototipo risponde a una domanda diversa da quella della produzione. il prototipo dimostra che l'idea può funzionare una volta, con un input pulito, con il founder al comando. la produzione deve funzionare con l'input disordinato, alle due di notte, senza nessuno che guarda, ed essere difendibile quando un cliente contesta ciò che la funzionalità gli ha detto. è in quel divario che muoiono la maggior parte delle costruzioni v0 e lovable. non perché l'idea fosse sbagliata. perché non c'era un percorso dalla demo alla cosa a cui puoi mettere la tua firma.
come si porta un prototipo ai in produzione?
si parte dal problema reale, non dall'interfaccia della demo. si ricostruisce la funzionalità dentro il proprio prodotto con risposte in streaming, una suite di test che verifica le risposte rispetto a casi noti come corretti, un log di audit e una revisione umana dove conta. per questo team fintech quel percorso ha richiesto 5 settimane e ha ridotto i ticket sulla funzionalità del 60%.
#cosa abbiamo costruito davvero?
non siamo partiti dalla casella di chat del prototipo. siamo partiti dalla loro coda di supporto. i tre ticket a maggior volume su questa funzionalità indicavano tutti la stessa cosa: gli utenti non riuscivano a ottenere una risposta chiara senza scrivere un'email al supporto. così abbiamo costruito la funzionalità per rispondere prima a quelle tre domande, dentro il loro prodotto e il loro design system, non come un widget incollato sopra.
- risposte in streaming così la funzionalità sembra immediata invece di uno spinner. la risposta si scrive man mano che si forma.
- una suite di test che verifica la funzionalità rispetto a risposte note come corrette a ogni modifica, così una modifica a un prompt non può rompere silenziosamente un altro caso.
- un log di audit su ogni risposta, così quando un cliente contesta ciò che la funzionalità ha detto, il supporto può recuperare l'input e l'output esatti.
- un'esperienza integrata nel prodotto costruita dentro il loro design system, così si legge come parte del prodotto, non come una finestra di chat incollata sopra.
we are
abbiamo ricostruito un prototipo bloccato in una funzionalità pubblicata, con streaming, una suite di test, un log di audit e un'esperienza nativa integrata nel prodotto.
we aren't
non abbiamo appoggiato una casella di chat generica sopra il prodotto chiamandola funzionalità ai.
#perché i ticket di supporto sono calati del 60%?
perché abbiamo costruito la funzionalità partendo a ritroso dai ticket. le tre domande che generavano il maggior volume di supporto sono le tre a cui la funzionalità ora risponde dentro il prodotto, prima che un utente debba scrivere un'email a chiunque. il log di audit ci dice quali domande la funzionalità gestisce e quali arrivano ancora a una persona. è lo stesso log che ci ha permesso di sapere che il calo del 60% era reale e non un calo stagionale. è misurato, per tipo di ticket, rispetto alle otto settimane precedenti al lancio.
la suite di test è il motivo per cui il calo si è mantenuto nel tempo. prima del lancio, ogni modifica veniva verificata rispetto alle risposte note come corrette. una modifica a un prompt che risolveva un caso e ne rompeva altri due veniva intercettata prima di arrivare a un utente. è la differenza tra una demo che funziona una volta e una funzionalità che funziona ogni volta. i team di prodotto la chiamano shipping. siamo d'accordo. maggiori informazioni su come affrontiamo il lavoro di prodotto sono qui.
#quanto tempo ci è voluto per pubblicarla?
cinque settimane, dal prototipo al 100% degli utenti. la prima settimana è stata dedicata al log di audit e alla suite di test, perché non puoi migliorare ciò che non puoi misurare. le settimane due e tre hanno ricostruito dentro il prodotto le tre risposte ai ticket più frequenti. la quarta settimana è stata dedicata all'esperienza nel design system e allo streaming. la quinta settimana è stato un rollout graduale, il dieci percento degli utenti alla volta, tenendo d'occhio il log di audit per qualsiasi cosa sfuggita ai test. nessun lancio big-bang. nessuna ricostruzione durata un trimestre.
è passata da una cosa che mostravamo in demo a una cosa che abbiamo pubblicato, e la coda di supporto è come sappiamo che ha funzionato.
questo è ciò che accomuna la maggior parte dei nostri casi studio build-in-public. il successo non è il modello. sono le parti noiose intorno ad esso: la suite di test, il log di audit, i controlli di revisione, il rollout che puoi osservare. è questo che trasforma un prototipo in qualcosa che puoi mettere davanti a ogni utente. se hai una costruzione v0 o lovable ferma alla demo senza un percorso in avanti, è esattamente quel divario che colmiamo. dicci cosa stai costruendo.