Costruire la funzione di prodotto in Raffle AI

Quando Raffle ha cambiato leadership, ho preso in carico il prodotto — un ruolo che nessuno ricopriva — ho portato un processo di pianificazione deliberato in un'azienda veloce e reattiva e ho costruito la piattaforma partner su cui oggi gira un nuovo canale di rivenditori.

Contesto

Raffle AI sviluppa soluzioni di ricerca e chat basate sull'AI per le aziende. Il team è piccolo, e lo è di proposito: due sviluppatori frontend, due sviluppatori backend, una data scientist, un designer, un CTO, il supporto tecnico e io.

Per gran parte della vita dell'azienda, la direzione di prodotto è stata guidata dalla founder — una professionista capace, con un background commerciale, che ha portato avanti l'azienda nei suoi primi anni in gran parte con la propria energia. Quel tipo di slancio guidato dai founder è ciò che tiene in vita le aziende agli inizi, ma crea un ambiente di prodotto particolare: veloce, fortemente guidato dai clienti e difficile da scalare. Le priorità cambiavano cliente dopo cliente. La piattaforma aveva accumulato debito tecnico, diversi grandi progetti fondamentali si erano arenati e molte funzionalità erano soluzioni una tantum costruite per clienti specifici invece che per il prodotto nel suo insieme.

Quando il board ha cambiato la leadership, quel vuoto è diventato qualcosa su cui potevo agire.

Come è iniziato

L'ho proposto direttamente al nuovo CEO.

Non c'era nessuno dedicato al prodotto e il vuoto era evidente. Due anni dentro il prodotto mi avevano dato una conoscenza profonda di cosa facesse e dove fosse fragile. Tra un background in product design al Politecnico di Milano, lo sviluppo frontend e un coinvolgimento crescente tra vendite e marketing, mi trovavo a mio agio a lavorare direttamente sia con l'engineering sia con il business.

È stato d'accordo. Il prodotto rientrava formalmente sotto il CTO, che è stato sincero nel dire che sarebbe stato un ruolo difficile. Era già impegnato su più fronti tra compliance di sicurezza, prospect e lavoro tecnico approfondito, e non aveva mai avuto il tempo di guidare la direzione di prodotto. Mi ha sostenuto pienamente fin dall'inizio, e abbiamo lavorato come veri partner per tutto il percorso.

Cosa ho introdotto

Prima di tutto, visibilità condivisa. Ho migrato il backlog da un ClickUp disordinato a Linear, ripulendolo e ristrutturandolo nel processo. Prima che chiunque potesse allinearsi sulle priorità, tutti dovevano vedere lo stesso quadro di ciò che esisteva e di ciò che era in corso.

Poi, un ritmo di pianificazione: allineamento trimestrale attorno a un obiettivo di business chiaro, seguito da una fase di discovery e quindi dall'esecuzione con requisiti, scope e scadenze definiti — revisionati dal team prima di iniziare il lavoro.

La discovery è diventata la parte su cui ho investito di più. Ogni ciclo attinge a poche fonti concrete: il feedback del customer success raccolto regolarmente e inserito nel backlog, le priorità strategiche del CEO, la nostra analisi dei punti in cui il prodotto faticava e un controllo sulla concorrenza per non rimanere indietro sulle funzionalità ormai imprescindibili. Nessun singolo input decide la direzione; emerge dal valutarli insieme.

Ho reso i POC una parte standard dello scoping. Prima di impegnare il team in un progetto importante, costruivo un prototipo funzionante per testarne la fattibilità e dare forma ai requisiti. L'esempio più chiaro è l'attuale refactor della chat — il passaggio da un sistema che riassumeva i risultati di ricerca a una chat completamente agentica con tool calling e livelli di contesto. Prima di scrivere un solo requisito, ho costruito una versione funzionante grezza per mettere alla prova l'approccio, per poi passarla alla nostra data scientist, che l'ha trasformata nel design document di produzione. Ci sono volute alcune settimane in parallelo ad altro lavoro — ma il team ha iniziato l'esecuzione con un quadro chiaro di ciò che stava costruendo e del perché.

Non ho detto all'engineering come lavorare. Il mio compito era rendere chiari gli obiettivi e solidi i requisiti. Il resto spettava a loro.

Questo non significava che tutto rallentasse. Il lavoro strutturato era circa l'80% della roadmap; il restante 20% era lasciato intenzionalmente flessibile per fix rapidi, risultati facili da ottenere e quel lavoro opportunistico di cui una startup ha comunque bisogno. Le correzioni continuavano a esserci — semplicemente erano definite nello scope, prioritizzate con criterio e pianificate, invece di essere lasciate dominare.

La piattaforma partner

L'esempio più chiaro di ciò che questo processo ha reso possibile è la piattaforma partner costruita nel Q1 2026.

Raffle aveva individuato nei partner — rivenditori e integratori — un canale di crescita significativo, ma non esisteva alcuna infrastruttura per supportarli. Ho lavorato a stretto contatto con il nostro partnerships manager partendo da zero: cominciando con una discovery approfondita su ciò di cui avevano realmente bisogno, per poi generalizzare deliberatamente quei bisogni in qualcosa di scalabile invece di costruire l'ennesima soluzione una tantum.

Quello che abbiamo costruito è stata una piattaforma completa di gestione degli account per i partner:

• Un flusso self-serve per creare e configurare gli account dei clienti ed eseguire gli scrape
• Un sistema di piani e permessi per assegnare le funzionalità in base agli accordi commerciali — completamente scalabile, e ora usato anche internamente
• Un sistema di template per i widget così che i partner potessero configurare nuovi clienti in modo rapido e coerente
• Una dashboard di monitoraggio per tracciare le performance degli account e far emergere problemi e opportunità in anticipo

Il risultato: gli account gestiti dai partner sono passati da zero a più di 200, e la base clienti complessiva di Raffle è cresciuta da circa 100 a oltre 300. Quella categoria di clienti prima non esisteva — il prodotto non poteva supportarla. Costruivamo a mano soluzioni su misura per una manciata di clienti; questo ha trasformato tutto ciò in qualcosa che i partner potevano vendere e scalare in autonomia.

Voglio però essere chiaro sul numero in evidenza: quella crescita non si è tradotta in modo proporzionale in fatturato. I nuovi contratti sono più piccoli e il churn ha compensato parte del volume, e colmare quel divario è un lavoro ancora in corso. Ma niente di tutto questo sarebbe stato possibile prima che la piattaforma esistesse.

Come ha risposto il team

Ero un designer che entrava in un ruolo da PM in un team che aveva già un designer — qualcuno con tutte le ragioni per metterlo in dubbio. La tensione è stata reale ma breve, e il team mi ha seguito più in fretta di quanto mi aspettassi.

Non ho cercato di presentarmi come un PM. Mi sono concentrato sull'essere utile e ho lasciato che fosse il lavoro a guadagnarmi il ruolo. La consegna e la qualità di ciò che abbiamo rilasciato sono venute dal team; il mio compito era rendere tutto questo più facile.

Cosa è cambiato

Le funzionalità hanno iniziato a richiedere più tempo. Il prodotto è migliorato in modo sostanziale.

Prima, una correzione poteva essere rilasciata in un giorno. Una vera funzionalità che rimuove una limitazione fondamentale del prodotto richiede due o tre mesi. Quel compromesso ne vale la pena — ma solo se si è onesti al riguardo. Continuiamo a muoverci velocemente sulle cose che meritano velocità. Ciò che è cambiato è che la lentezza è diventata una scelta, non un sintomo.

Il cambiamento è visibile in due numeri. Le correzioni impreviste sono scese da circa una al giorno a circa una a settimana o una ogni due settimane — e quelle rimaste vengono definite nello scope e prioritizzate con criterio invece di essere sfornate su richiesta. E le consegne puntuali della roadmap sono cresciute ogni trimestre man mano che il processo maturava: da circa il 50% nel mio primo trimestre a circa il 60%, poi il 70% e circa l'80% oggi. Le prime roadmap erano troppo ambiziose e mancavamo le scadenze; man mano che la pianificazione diventava più realistica, le consegne miglioravano ogni trimestre.

Il team è passato dall'essere reattivo all'essere intenzionale, e la differenza si vede in ciò che abbiamo rilasciato: un completo refactor della ricerca vettoriale che ha ridotto i costi e i tempi di indicizzazione, una revisione totale dei widget, la piattaforma partner dietro una nuova categoria di clienti e una chat agentica — attualmente in corso — che punta a cambiare radicalmente ciò che il prodotto è in grado di fare.

Il divario di fatturato che ho menzionato prima è il prossimo problema da risolvere, ed è reale. Ma è un problema su cui l'azienda ora può davvero lavorare. Diciotto mesi fa il prodotto non era affatto in grado di scalare; oggi ha un fondamento che rende possibile una crescita sostenibile — e costruire quel fondamento, insieme al team, è il senso vero dell'ultimo anno di lavoro.