Il fondatore di AI che costruisce un’impresa autonoma spiega come creare workflow agentici per la consegna dei progetti e il supporto clienti
Amos Bar Joseph è un imprenditore seriale che ha imparato dagli errori commessi in passato con la gestione tradizionale dei progetti, le strategie di go-to-market e i modelli di business. Di conseguenza, la sua ultima impresa, Swan AI, punta a diventare completamente autonoma. E questo significa che l’AI gestirà i progetti—e praticamente tutto il resto.
Amos Bar Joseph
CEO di Swanai
Dalla Pianificazione alla Velocità Decisionale: La gestione tradizionale dei progetti si concentra molto sulla pianificazione, la documentazione e il coordinamento. Amos mostra che in un’azienda AI-first, l’esecuzione diventa economica e rapida, quindi il vero collo di bottiglia è la velocità con cui si riconoscono modelli e si prendono decisioni.
Workflow Autonomi: Swan AI ha eliminato riunioni di aggiornamento, lunghi piani di progetto, catene di approvazione e revisioni trimestrali — sostituendoli con aggiornamenti asincroni, definizioni di risultati, diritti chiari di decisione e segnali di feedback automatizzati. Questo cambiamento ha ridotto il tempo di coordinamento dal 60% al 10%, permettendo al team di dedicarsi principalmente al lavoro vero, non a parlare del lavoro.
Ruoli Umani Devono Essere Definiti: I ruoli umani devono essere definiti prima di automatizzare con l’AI, perché le implementazioni falliscono non per limiti dell’intelligenza artificiale ma perché le squadre non chiariscono mai cosa devono gestire gli umani; Amos spiega che l’AI dovrebbe occuparsi completamente dei compiti a basso impatto e bassa complessità, assistere nelle aree in cui la complessità o il rischio sono più alti, e lasciare le decisioni ad alto impatto e alta complessità alle persone.
Abbiamo incontrato Amos per capire cosa significhi tutto questo nella pratica. Ecco cosa ci ha raccontato.
Come un modello di business autonomo trasforma la consegna dei progetti
Sono il cofondatore e CEO di Swan AI, una piattaforma di automazione GTM che si integra tra canali di comunicazione (email, Slack, ecc.), CRM e fonti dati B2B per gestire i flussi di lavoro GTM. La utilizziamo anche internamente per la consegna dei progetti e la gestione dei clienti.
Stiamo costruendo la prima azienda autonoma con la missione di raggiungere $10M ARR per dipendente con un piccolo team e un esercito di agenti AI. La nostra azienda autonoma è progettata per la collaborazione uomo+AI, non per la coordinazione tra persone, e può scalare grazie all'intelligenza — non aumentando il personale.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Questa limitazione si è trasformata in un laboratorio accidentale per la consegna dei progetti. Quando non puoi risolvere i problemi assumendo persone, ogni decisione di progetto diventa esistenziale: ci farà decuplicare i risultati o è solo attività che sembra progresso?
Questo filtro spietato ha rivelato schemi che non vedevo quando, nelle mie due startup precedenti, mi concedeva il lusso di assegnare persone ai problemi, e che ho fondato e fatto crescere seguendo il vecchio manuale “crescita a tutti i costi”. Ora, dopo aver osservato oltre 200 aziende implementare l’AI attraverso il prodotto Swan, riesco a individuare immediatamente gli schemi di fallimento.
Perché l'AI sta spostando la consegna dei progetti dalla pianificazione al riconoscimento di schemi e alla velocità decisionale
Il cambiamento più radicale riguarda come distribuisco il mio tempo — ed è quasi l’opposto del project management tradizionale. Dedico pochissimo tempo alle attività che richiedevano la mia attenzione in passato, come la pianificazione iniziale, le riunioni di avanzamento e la documentazione che nessuno legge. Fra poco spiegherò perché.
Ecco ora su cosa focalizzo la mia attenzione:
- 60% va al riconoscimento di schemi e alle decisioni: Analizzo in tempo reale cosa funziona nelle nostre oltre 200 implementazioni. Non revisioni mensili, ma individuazione quotidiana di schemi. Quali implementazioni stanno producendo risultati moltiplicati e quali sono in fase di stallo? Dove si verificano davvero i colli di bottiglia rispetto a dove pensavamo sarebbero stati? La sfida è decidere rapidamente cosa eliminare e su cosa investire di più — e non si può fare questo durante una trimestrale. Per questo, abbiamo una dashboard Retool per il monitoraggio clienti e inviamo alert su Slack. Uso anche Metabase, dove abbiamo analisi di prodotto più dettagliate per ogni cliente.
- 30% è dedicato alla progettazione dei loop di feedback: Come capiamo entro 48 ore se una implementazione AI sta funzionando? Quali segnali ci dicono di cambiare rotta invece che insistere? Sto creando "sistemi di rilevamento anomalie" — modi per intercettare quando l’AI esce dal copione o un flusso non produce risultati prima che diventi una crisi. Per riuscirci, è importante stabilire un piano chiaro che parte da piccoli passi facilmente misurabili. I Project Manager tradizionali pianificavano per il successo; io progetto sistemi che segnalano subito i fallimenti, così possiamo correggerli quando sono ancora minimi.
- 10% riguarda il vero e proprio "lancio del progetto": Prima era il culmine di mesi di lavoro. Ora è solo martedì. Pubblicare la versione 1 è routine e trattiamo il lancio come l’inizio dell’apprendimento, non la fine della pianificazione. Il lancio non rappresenta più il successo — dà solo il via a un reale feedback.
In un mondo dominato dall’AI, l’execution è poco costosa e veloce. Il vero collo di bottiglia è la velocità decisionale. Il mio ruolo si è spostato da "realizzare il piano perfetto" a "prendere rapide decisioni sulla base di feedback reali". Ecco perché il 90% del mio tempo è sui sistemi di apprendimento, non sui sistemi di esecuzione.
In un mondo dominato dall’AI, l’esecuzione è poco costosa e veloce. Il vero collo di bottiglia è la velocità decisionale.
Come eliminare la tassa di coordinamento nella consegna progetti
Il nostro passaggio dal project management tradizionale a quello snello non è stato un cambio di metodologia, ma l’eliminazione di rituali specifici che ci rallentavano. Ecco cosa è stato eliminato e cosa lo ha rimpiazzato:
Riunioni di avanzamento (40% del calendario) → Aggiornamenti asincroni (ora il 5% del tempo)
- Eliminato: Riunioni settimanali di stato progetto con slide
- Sostituito da: Aggiornamenti brevi su Slack quando cambia qualcosa, non secondo un calendario
- Perché funziona: Le informazioni circolano quando serve, non quando lo dice il calendario
- Risultato: Recuperate oltre 15 ore a settimana per ogni founder
Piani progetto dettagliati (2-4 settimane all'inizio) → Definizione degli obiettivi (2-4 ore)
- Eliminato: Documenti di requisiti completi, mappe dei flussi di lavoro, matrici di rischio
- Sostituito con: Chiarezza sul risultato desiderato e primo esperimento da eseguire
- Perché funziona: I piani diventano subito obsoleti; i risultati restano rilevanti
- Risultato: Prime versioni rilasciate in giorni, non mesi
Catene di approvazione → Chiare responsabilità decisionali
- Eliminato: "Fallo vedere alla leadership" per le piccole decisioni
- Sostituito con: Soglie definite — sotto $X o impatto Y, semplicemente esegui
- Perché funziona: La velocità conta più che evitare piccoli errori
- Risultato: Il tempo tra decisione e azione è passato da giorni a ore
Revisioni trimestrali → Feedback quotidiani
- Eliminato: Riunioni programmate tipo "vediamo a che punto è il progetto"
- Sostituito con: Metriche automatiche che avvisano se c’è un problema
- Perché funziona: I problemi si intercettano al giorno 2, non al mese 3
- Risultato: I problemi vengono risolti prima che diventino crisi
Siamo passati dal passare il 60% del tempo a coordinare il lavoro al 90% del tempo a svolgerlo. Non perché siamo più disciplinati, ma perché abbiamo tolto la tassa di coordinamento creata dal project management tradizionale.
Come l’IA cambia i rituali di delivery richiedendo un contesto più ricco
Il pensiero tradizionale suppone che l’IA comporti meno comunicazione umana. Nella nostra esperienza è l’opposto: quando c’è l’IA in squadra comunichiamo più esplicitamente, perché l’IA ha bisogno di contesto per essere utile.
Per noi questo è particolarmente rilevante perché usiamo il nostro stesso prodotto per eliminare la “tassa di contesto” — ovvero si integra su tutti i nostri canali di comunicazione per raccogliere e recuperare il contesto. Ascolta.
Questo ha un grande impatto sui nostri rituali. I progetti di customer success sono un buon esempio. Quando un cliente segnala un problema o fa una richiesta, i nostri founder comunicano intenzionalmente con più dettagli del necessario l’uno per l’altro — perché sappiamo che l’IA sta raccogliendo queste informazioni.
Ecco come si traduce praticamente:
Invece di: “Il cliente X vuole la funzione Y, ne parliamo domani”
Scriviamo: “Il cliente X ha richiesto la funzione Y. Contesto: stanno avendo problemi di scalabilità a 200 lead/giorno, il loro team di 3 SDR è sopraffatto, e questa funzione permetterebbe di gestirne 500/giorno senza nuove assunzioni. È allineato al nostro ICP di scalabilità SMB. Urgenza: alta — stanno valutando la concorrenza questa settimana.”
Così, quando chiunque nel team — compresa l’IA — interagisce con quel cliente, ha accesso al contesto rilevante.
Sì, serve 2-3 minuti in più per comunicazione. Ma si risparmiano ore in:
- Riunioni di allineamento — l’IA tiene tutti sincronizzati
- Raccolta del contesto — l’IA sa già la situazione
- Passaggi di consegne — l’IA mantiene il contesto tra le interazioni
Quando consideri l’IA come un membro del team che deve rimanere aggiornato, i rituali di comunicazione e documentazione cambiano radicalmente — e lì l’IA diventa davvero utile, non solo una feature.
Perché definire prima i ruoli umani è essenziale per implementare l’IA con successo
I fallimenti nell’implementazione di IA quasi mai sono dovuti all’incapacità dell’IA. Falliscono perché i team non rispondono prima a una domanda più fondamentale: “Cosa spetta agli umani in questo workflow?”
Questo è lo schema che vedo di continuo nelle nostre oltre 200 implementazioni:
I team trascorrono settimane chiedendosi “L’IA può occuparsi di questo compito?” Mappano il processo attuale, identificano ciò che si può automatizzare con l’IA, costruiscono il sistema e lo lanciano. L’IA funziona. Riesce a coprire in modo affidabile il 70-80% dell’attività.
Poi tutto si incrina. Non perché l’IA si rompa, ma perché nessuno ha definito cosa devono fare gli umani su quel 20-30% restante. Così succede una di queste due cose:
- Gli umani micromanagiano tutto. Non si fidano dell’IA, quindi revisionano ogni decisione, trasformando di fatto un’implementazione da $20K in un costoso sistema di suggerimenti. Il team si sfinisce a controllare i compiti dell’IA.
- Gli umani abbandonano del tutto la responsabilità. Presumono che “l’IA se ne occupa” e smettono di prestare attenzione. Poi qualcosa si rompe o va fuori dai binari, e nessuno se ne accorge finché non diventa una crisi per il cliente.
Questo accade perché abbiamo affrontato l’implementazione dell’AI al contrario. Ci siamo chiesti “Cosa possiamo automatizzare?” invece di “Dove il giudizio umano è insostituibile e come possiamo costruire l’AI per amplificarlo?”
Invece, ogni progetto AI dovrebbe partire dalla definizione del ruolo umano. Quali decisioni richiedono intuizione? Dove il contesto è fondamentale? Quali modalità di errore necessitano la supervisione umana? Solo dopo, si costruisce l’AI per occuparsi di tutto il resto e fornire i giusti segnali al momento opportuno affinché l’essere umano possa prendere decisioni.
Sembra ovvio ripensandoci. Ma quando si è entusiasti delle potenzialità dell’AI, è incredibilmente facile saltare questo passaggio e concentrarsi solo su ciò che l’AI può fare — invece di progettare fin da subito la collaborazione uomo-AI.
Un quadro pratico per decidere cosa dovrebbe automatizzare l’AI
Penso alle decisioni di automazione su due dimensioni: impatto dell’errore e complessità del giudizio richiesto. Questo genera quattro categorie distinte, che illustrerò tra poco.
Quando si sale di livello in complessità o impatto, il ruolo dell’AI passa da "titolare" a "assistente". Ma bisogna stabilire in anticipo quale ruolo ha l’AI per ciascun workflow — non dopo il lancio, quando gli umani non sanno se fidarsi o meno delle decisioni dell’AI.
Questo schema non riguarda ciò che l’AI può fare a livello tecnico. Si tratta di stabilire cosa dovrebbe gestire l’AI considerando il profilo di rischio e il giudizio necessario.
Basso impatto + bassa complessità = automazione totale
Esempio 1: Enrichment e ricerca dati
- L’AI recupera informazioni sull’azienda, tech stack, profili social
- Se commette errori, gli umani li rilevano durante la revisione
- Nessun giudizio richiesto — solo raccolta dati
- Implementazione: integrazioni API, output strutturato da AI, controlli umani a campione
Esempio 2: Lead scoring iniziale e instradamento
- L’AI attribuisce punteggi rispetto a criteri ICP definiti, instrada verso il workflow appropriato
- Gli instradamenti errati sono evidenti e facili da correggere
- La logica è codificabile (dimensione aziendale, settore, segnali comportamentali)
- Implementazione: regole + punteggio AI, revisione umana dei casi limite
Basso impatto + alta complessità = preparazione AI, decisione umana
Esempio: Risposte di assistenza clienti
- L’AI redige risposte basandosi su casi precedenti simili
- La complessità deriva da tono, contesto e casi limite
- Basso impatto se viene revisionata prima dell’invio
- Implementazione: AI scrive, l’umano revisiona/modifica, si apprendono le correzioni
Alto impatto + bassa complessità = automazione con salvaguardie
Esempio: Invio di messaggi outbound
- Alto impatto perché, se gestito male, può danneggiare il brand o il mercato
- Ma la complessità rimane relativamente bassa — la qualità è misurabile
- Implementazione: AI genera, workflow di approvazione rigorosi, interruttori automatici se la performance cala
Alto impatto + alta complessità = gestione umana
Esempio: Pivot strategici di progetto
- Decidere se interrompere o raddoppiare un’implementazione
- Richiede riconoscimento di pattern su più contesti
- Un errore costa caro: risorse sprecate o opportunità perse
- Implementazione: AI segnala dati (calo utilizzo, pattern feedback), la decisione finale spetta all’umano
Esempio: Negoziazioni complesse con clienti
- Discussione sui prezzi, espansioni, rischi di rinnovo
- Richiede lettura della dinamica di relazione, contesto politico, preoccupazioni non espresse
- Sbagliare mina la fiducia, difficile poi da ricostruire
- Implementazione: AI si occupa della ricerca e preparazione, l’umano conduce la conversazione
Come i workflow agentici hanno permesso un sistema di supporto auto-apprendente in 13 ore
Ecco un esempio della complessità che abbiamo affrontato utilizzando workflow agentici nella costruzione di un’azienda automatizzata.
La limitazione: Puntare a $10M ARR per dipendente con soli 3 founder significava che non potevamo assumere personale per superare gli ostacoli. Quando i ticket di supporto hanno superato i 200 a settimana, la risposta tradizionale — assumere 2 Customer Success Manager — non era disponibile per noi. Ogni ticket richiedeva l’attenzione totale di un founder — ricercare la risposta, scrivere la risposta, documentarla da qualche parte. Stavamo affondando.
V1 (settimana 1): Rispondere alle domande conosciute
Siamo partiti dal minimo indispensabile: agente AI in Slack che poteva rispondere a circa 20 domande che avevamo già documentato in Notion.
- Strumenti: Swan AI, Slack, Notion
- Configurazione: 6 ore
- Risultato: 15% dei ticket gestiti
- Nuovo problema: I clienti erano frustrati nel ricevere risposte del tipo "Non lo so". Stavamo ancora rispondendo manualmente all’85% dei ticket.
V2 (settimana 2): Gestire le domande sconosciute
Abbiamo aggiunto un percorso di escalation: l’AI rimane nella conversazione con il cliente, ma ci segnala internamente quando non sa qualcosa. Noi rispondiamo, l’AI consegna la nostra risposta.
- Configurazione: 3 ore
- Risultato: 35% di risoluzione autonoma
- Nuovo problema: Abbiamo notato che continuavamo a rispondere sempre alle stesse nuove domande. Ogni escalation non insegnava nulla all’AI — era solo un sistema di smistamento.
V3 (settimana 4): Imparare dalle escalation
Abbiamo costruito il ciclo di apprendimento. Ora, quando rispondiamo a una domanda nell’escalation, l’AI acquisisce automaticamente la Q&A, la struttura e la aggiunge alla knowledge base.
- Configurazione: 4 ore
- Risultato: 70% di risoluzione autonoma in 2 settimane
Perché ha funzionato: Ogni versione ha richiesto meno di 6 ore di sviluppo perché non pianificavamo la perfezione — rispondevamo a feedback specifici. La funzionalità "self-learning" non era prevista. È emersa naturalmente chiedendoci: "Perché stiamo rispondendo due volte alle stesse domande?"
Ora, gestiamo oltre 200 ticket a settimana, il 70% in modo autonomo, e la nostra knowledge base cresce organicamente dalle domande reali dei clienti.
Quindi il mio consiglio è: Rilascia il minimo indispensabile che risolve il problema immediato. Guarda dove si rompe. Aggiungi la feature minima per correggere quel punto. Ripeti. Siamo arrivati a un sistema sofisticato di apprendimento automatico senza mai pianificarlo dall’inizio.
Rilascia il minimo indispensabile che risolve il problema immediato. Guarda dove si rompe. Aggiungi la feature minima per correggere quel punto. Ripeti.
Altri ambiti promettenti per workflow agentici
Stiamo anche utilizzando workflow agentici in:
- Onboarding: Nuovo cliente → Swan guida la configurazione in modo conversazionale, pone domande ICP, configura i workflow in base alle risposte
- Successo: Monitora i pattern di utilizzo → segnala opportunità di espansione o rischi → segnala ai founder con raccomandazioni
Perché i feedback loop contano più della scelta dello strumento AI, e come costruirli
Tutti chiedono, "Quale strumento AI dovremmo usare?" Domanda sbagliata.
La cosa che ci fa risparmiare più tempo non è uno strumento, ma il fatto che sappiamo entro 48 ore quando qualcosa si rompe.
Inseriamo feedback loop in ogni implementazione. Monitoriamo:
- Schemi di escalation: Quando l’AI passa il caso agli umani, segnala che serve aiuto
- Tassi di override: Quando gli umani modificano gli output dell’AI, segnala che il giudizio era debole.
- Metriche di risultato: Meeting fissati, ticket risolti, ecc. — non solo attività.
- Trigger di fallimento: Avvisi automatici quando la performance cala.
Senza feedback loop, lanci l’AI e speri che funzioni. Quando ti accorgi che non funziona — di solito tramite lamentele o review trimestrali — hai già perso mesi.
Con i feedback loop, intercetti i problemi in pochi giorni e li risolvi prima che diventino gravi.
Abbiamo visto impatti concreti:
- Support AI: Dal 35% al 70% di autonomia in 2 settimane grazie all’analisi delle domande che richiedevano risposte migliori
- Qualification AI: Miglioramento della precisione del 40% in 30 giorni monitorando gli override umani
La scelta dello strumento AI conta molto meno della tua capacità di rilevare cosa non va e iterare rapidamente. Il "tool" che fa risparmiare più tempo è il sistema che ti dice che cosa va migliorato prima che diventi una crisi.
Uno stack tecnologico AI-native che abilita la consegna autonoma dei progetti
Detto ciò, ci sono alcuni capisaldi:
- Progetti Claude (Strumento di produttività AI): Creo ed elaboro tutti i documenti relativi al progetto in un Progetto Claude. In questo modo il contesto dell’AI si accumula e diventa più intelligente a ogni conversazione.
- Shortwave (Strumenti di comunicazione AI): È un nuovo client email nativo AI con un agente AI integrato che mi aiuta a recuperare facilmente il giusto contesto tra tutto il caos della mia casella di posta. Aiuta anche a scrivere ottime email e ad allineare gli stakeholder senza dover cambiare contesto o perdersi nella ricerca di vecchie discussioni.
- N8N (Software di automazione dei flussi di lavoro AI): Lo uso per creare agenti AI collegati al nostro Retool e Metabase così possiamo ricevere gli aggiornamenti di progetto direttamente su Slack.
Perché la gestione dei progetti si sta evolvendo in gestione della velocità
L'AI nella gestione dei progetti si evolverà dalla semplice consegna di progetti alla gestione della velocità tramite adattamento continuo.
Credo che l’AI renderà così veloce la realizzazione e il cambiamento delle cose che i progetti con un inizio e una fine definiti diventeranno obsoleti. Quando termina un progetto di tre mesi, i requisiti sono già cambiati, le capacità dell’AI sono evolute e la soluzione "completata" è già datata.
Quello che le sostituirà saranno cicli di miglioramento continuo con rapidissimi feedback. Invece di "lanciare il portale clienti nel Q3", sarà "evolvere costantemente le interazioni con i clienti, rilasciare cambiamenti ogni giorno basandosi sul feedback reale."
I "velocity manager" ottimizzeranno per:
- Velocità feedback-soluzione — non date di consegna
- Frequenza di iterazione — non fine progetto
- Velocità di apprendimento — non gestione dello scope
Il successo sarà definito da quanto rapidamente rilevi i problemi e realizzi le soluzioni, non dal raggiungimento di milestone predefinite.
I PM che sopravvivranno stanno già rafforzando questa abilità: rilasciano versioni v1 imperfette, iterano sulla base dell’utilizzo reale, ottimizzano la velocità invece della perfezione. Chi invece perfeziona ancora i propri diagrammi di Gantt non riconoscerà più il lavoro tra cinque anni.
Perché la velocità di iterazione batte la pianificazione — e come i leader possono rilasciare più velocemente con l’AI
Ecco il mio consiglio: punta sulla velocità di iterazione, non sulla perfezione dell’implementazione.
Smetti di: pianificare per settimane, lanciare solo quando tutto è perfetto, evitare qualsiasi errore.
Inizia a: rilasciare versioni minime utili in pochi giorni, creare prima il ciclo di feedback, imparare da iterazioni rapide.
E rendilo pratico: riduci del 75% la fase di pianificazione del tuo prossimo progetto. Rilascia qualcosa di imperfetto questa settimana che ti insegni ciò che conta davvero. Misura il successo sulla base della rapidità con cui passi da "questo non funziona" a "ecco la v2."
La velocità di apprendimento batte in ogni caso la profondità della pianificazione.
La velocità di apprendimento batte in ogni caso la profondità della pianificazione.
Rimani aggiornato
Puoi seguire il lavoro di Amos sull’automazione dei flussi GTM su LinkedIn e sulla newsletter di Swan. Puoi anche dare un’occhiata a Swan e ad Autonamos, il clone digitale di Amos.
Altre interviste ad esperti in arrivo su The Digital Project Manager!
