Il caso Not Just Analytics mostra cosa cambia quando il codice arriva prima, dal passaggio delle novità a marketing e supporto alle decisioni su prototipi, debito tecnico e accesso ai dati.
Cosa succede se il tuo team riesce a rilasciare più velocemente, ma chi deve spiegare quelle novità ai clienti continua a lavorare allo stesso ritmo? Andrea Barbieri, co-founder e CTO di Not Just Analytics, mi ha raccontato che a un certo punto le funzionalità si accumulavano più in fretta di quanto il team riuscisse a comunicarle.
La conversazione parte dalle dashboard e arriva a un problema che riguarda chiunque guidi un’organizzazione engineering. Ogni accelerazione cambia il lavoro di chi riceve il risultato. In questo caso il primo effetto si è visto fuori dal team di sviluppo.
1. Una dashboard vale per le decisioni che rende possibili · 00:59
«Questo qui è il nostro obiettivo, quindi è stato quello di creare delle dashboard per semplificare la lettura dei dati.»
Not Just Analytics nasce da un problema concreto. Yari Brugnoni, che lavorava come social media manager, aveva bisogno di dimostrare come stavano andando i profili che gestiva. Il primo strumento era interno. È diventato un prodotto quando si è capito che anche altri avevano bisogno di leggere quei dati con meno fatica.
La scelta rilevante è stata dare spazio a segnali come le visite al profilo o i clic sui link nelle storie. Un conteggio dei like e un clic verso una destinazione rispondono a domande diverse. Per chi deve decidere se ripetere una campagna o cambiare un contenuto, questa distinzione vale più di un grafico in più.
La domanda da portare a una review di prodotto è semplice. Dopo aver visto questo dato, che cosa può decidere l’utente? La risposta orienta sia le metriche da esporre sia il modo in cui l’AI potrà interpretarle.
2. La chat AI funziona. Perché l’utente dovrebbe aprire proprio la tua? · 05:17
«Questo però ci ha portato a un prodotto che dava una buona qualità di output, ma che cadeva molto spesso nel confronto con ChatGPT.»
Il primo esperimento aiutava a scrivere contenuti. L’utente poteva collegare il profilo, aggiungere informazioni, riprodurre il tono di voce e partire da notizie o trend. La qualità dell’output, racconta Andrea, era buona. Il problema era il confronto quotidiano con uno strumento che gli utenti usavano già.
Il team ha poi integrato l’AI nella lettura dei dati del prodotto. L’utente può partire dalle proprie metriche e ragionare su quali contenuti hanno funzionato e come si è comportato il profilo. Qui la domanda ha un contesto già disponibile dentro il SaaS.
Prima di investire in una chat, proverei a scrivere tre domande che un cliente si pone già oggi e a identificare i dati necessari per rispondere. Se ogni risposta dipende da informazioni che il prodotto possiede e aggiorna, hai un’ipotesi concreta da testare. Puoi anche verificare se l’utente riesce a risalire ai numeri su cui poggia l’interpretazione.
3. Misura il tempo dal rilascio a quando il cliente lo capisce · 10:26
«Il collo di bottiglia non è più stato lo sviluppo, ma è stato la parte di comunicazione.»
Quando le novità si sono accumulate, il team si è fermato a rivedere il flusso. La pipeline legge il task, lo confronta con le modifiche del commit e genera una base testuale che il resto dell’azienda può consultare in Notion. Marketing la usa per preparare i contenuti. Supporto può vedere che cosa è uscito e spiegare una funzionalità a chi ne ha bisogno. Lo stesso passaggio alimenta il changelog.
Task e commit rispondono a due domande diverse. Il task spiega perché si voleva fare una modifica. Il commit mostra che cosa è cambiato. Mettendoli insieme si può preparare una bozza che rispetta meglio ciò che il cliente troverà nel prodotto. Chi cura la comunicazione può poi scegliere cosa raccontare, a chi e quando.
Se vuoi capire se il problema esiste anche da te, parti da cinque rilasci recenti. Per ognuno ricostruisci quando è andato in produzione, quando supporto ha avuto materiale per rispondere e quando il cliente ha saputo della novità. Le attese tra quei momenti ti dicono dove intervenire.
4. Un prototipo funzionante cambia la conversazione con engineering · 17:21
«Avendo questo impatto con il cliente riescono a capire quelli che sono effettivamente i bisogni del cliente.»
A un retreat Andrea ha mostrato alcuni strumenti per prototipare con l’AI. L’entusiasmo maggiore è arrivato dai colleghi non tecnici. Chi parla ogni giorno con i clienti può ora mostrare un flusso da provare. Una discussione che sarebbe partita da pagine di requisiti può partire da un esempio concreto di quello che l’utente dovrebbe riuscire a fare.
Il passaggio successivo richiede giudizio ingegneristico. Engineering può usare il prototipo per chiarire il comportamento atteso, capire dove si innesta nel prodotto e verificare le conseguenze su UX, sicurezza e mantenibilità. Quanto del prototipo riutilizzare dipende dal codice esistente e dai vincoli della funzionalità.
Per far funzionare il passaggio chiederei a chi presenta il prototipo di portare anche due elementi. Quale problema del cliente sta cercando di risolvere? Quale comportamento vuole poter verificare? Queste risposte aiutano il team a conservare l’intento anche quando cambia l’implementazione.
5. Se il cliente vuole interrogare il dato, dove deve succedere? · 22:02
«Ha bisogno di interrogare il dato reale e ha la capacità di interrogare il dato.»
Andrea racconta che una parte del pubblico voleva scegliere in autonomia le domande, le visualizzazioni e il modo di impaginare i risultati. Per questo il team stava sperimentando un accesso via Model Context Protocol (MCP), che avrebbe permesso a quel segmento di lavorare con i dati di Not Just Analytics dal proprio client AI.
Per un CTO la scelta riguarda anche la distribuzione. Se il cliente preferisce lavorare in un altro ambiente, puoi valutare quali dati e operazioni esporre, con quali permessi e come verificare l’uso che ne viene fatto. La dashboard rimane una modalità di accesso utile per chi vuole trovare subito le analisi più comuni.
Lo stesso ragionamento aiuta nelle decisioni build vs buy. Un team può costruire un’interfaccia interna in poco tempo. Prima di impegnarsi, conviene stimare chi la aggiornerà al prossimo cambio delle API o quando la persona che l’ha costruita cambierà ruolo. Quel costo ricorrente va messo sul tavolo insieme al prezzo dell’abbonamento.
La prossima volta che introduci uno strumento AI in engineering, scegli anche un passaggio a valle da osservare. Quanto tempo passa prima che supporto sappia rispondere, che il cliente scopra la novità o che il team possa verificare il comportamento in produzione? Se quel tempo rimane uguale, hai già un punto da indagare nella prossima review del flusso.
Su CTO Mastermind ho approfondito lo stesso problema dal punto di vista della Developer Experience, seguendo una modifica dalla scrittura del codice alla produzione. L’AI non risolverà la tua Developer Experience
