Categoria: PROGETTI E IDEE

AI & GENAI, PROGETTI E IDEE

AITS 3.0.1: come un libro sui sei cappelli è diventato un motore per decidere con l’AI

Venerdì 6 novembre ho pubblicato su GitHub la versione 3.0 di AITS, l’Adaptive Intelligence Thinking System, e sabato la 3.0.1, nata da una simulazione che in poche ore ha mostrato cosa non funzionava. Il codice è aperto con licenza MIT, si installa come plugin di Claude Code, come skill su claude.ai o come server MCP per qualunque client, e serve a prendere una decisione complessa guardandola da undici prospettive diverse, con regole che il modello non può saltare e con l’ultima parola sempre a una persona.

Racconto da dove arriva AITS e mi fermo a lungo sull’ultimo passaggio, perché la 3.0.1 è una release di correzioni solo in apparenza: dentro c’è una scelta su chi, in un sistema di agenti, ha il diritto di scrivere il registro di una decisione.

AITS nasce dai Sei Cappelli di de Bono e da un libro del 2025

Uso le tecniche di Edward de Bono da anni, i Sei Cappelli soprattutto, con l’idea che si pensi meglio indossando una prospettiva alla volta e integrandole solo alla fine. Quel metodo mi è sembrato stretto per decisioni in cui una parte del ragionamento la fa già una macchina, e a giugno 2025 ho cominciato a scriverne qui, prima con gli AI-Enhanced Thinking Hats e il giorno dopo con la prima descrizione dell’Adaptive Intelligence Thinking System.

A ottobre è uscito il libro, La mente adattiva per Egea, dove i cappelli diventano agenti cognitivi, unità con una funzione sola che può svolgere una persona, un modello o più spesso una coppia fatta di entrambi. Erano otto, quattro evoluzioni dirette dei cappelli (Analitico, Emotivo-Intuitivo, Critico-Validatore, Ottimizzatore) e quattro nuovi, fino al Meta-Orchestratore che chiude la decisione. Nel post di lancio avevo promesso una piattaforma digitale, «coming soon». Ci ho messo un anno, e non è venuta come la immaginavo.

Le prime versioni hanno trasformato il libro in sub-agenti di Claude Code

A febbraio 2026 ho aperto il repository e ho scelto Claude Code, perché la sua architettura a sub-agenti offriva già quello che il libro descriveva, unità specializzate con il loro prompt e i loro strumenti chiamate da un orchestratore. L’orchestra di agenti è diventata una serie di file markdown, e una decisione partiva con un comando.

Sulle decisioni vere sono venute fuori le cose che sulla carta non si vedono, agenti che ignoravano il lavoro degli altri, conflitti risolti improvvisando, un sistema senza memoria e un agente etico i cui allarmi l’orchestratore trattava come suggerimenti. La 2.0, ad aprile, ha portato gli agenti a undici, con il Sistemico, il Foresight e la Memoria, ha dato a ognuno uno schema JSON per l’output, ha codificato in una matrice chi arbitra quale disaccordo e ha introdotto tre modalità di controllo umano con un gruppo di regole inviolabili valide in tutte.

La 3.0 sposta le regole dal prompt a un motore deterministico

Con la 2.0 avevo un problema che ho capito tardi. Regole, validazione e gate vivevano nel prompt dell’orchestratore, e un modello con il contesto pieno poteva saltarne uno senza che nessuno se ne accorgesse. Ne avevo scritto parlando di harness engineering: il modello non dovrebbe mai essere l’ultimo controllo su se stesso.

La 3.0 sposta il controllo in un motore deterministico, scritto in TypeScript, che ogni runtime chiama. Il motore valida ogni output contro il suo schema, valuta le regole dichiarate in un file YAML, apre i gate e li fa chiudere solo da una risposta umana registrata insieme al canale da cui è arrivata, e scrive ogni evento in un registro dove ogni riga contiene l’hash della precedente, così una modifica successiva diventa visibile. Anche la confidenza mostrata all’utente la calcola il motore, e si ferma al livello dell’input critico più debole.

L’altra scelta riguarda i modelli: AITS deve restare neutrale rispetto a chi produce l’AI. La specifica non nomina nessun fornitore, gli agenti dichiarano un livello di capacità e il modello lo sceglie chi usa il sistema. Il principio ha anche una base misurata, perché uno studio della Cornell presentato a ICML 2025, Correlated Errors in Large Language Models, ha osservato che su una delle classifiche analizzate due modelli che sbagliano la stessa domanda scelgono la stessa risposta sbagliata il 60% delle volte, con una correlazione più alta tra modelli dello stesso sviluppatore. Per questo gli agenti che stimano rischi e probabilità girano più volte in modo indipendente, su famiglie di modelli diverse quando sono configurate, e le posizioni di minoranza finiscono in un rapporto a parte invece di sparire nella media. Le previsioni vengono salvate con lo spazio per il loro esito, e quando gli esiti arrivano il motore misura quanto è calibrato ciascun agente, un tema su cui avevo scritto in Da RAG alla memoria.

Il motore ha fermato un piano di licenziamenti costruito su un’ipotesi

Prima di dire a qualcuno di installarlo ho voluto vederlo lavorare. Ho fatto girare il plugin in quattro sessioni reali di Claude Code su un caso costruito apposta ma verosimile, una PMI manifatturiera di Brescia con 80 dipendenti che vuole mettere un agente AI sul primo livello di assistenza e ridurre il customer care da sei a due persone in sei mesi, con 60 mila euro di budget e circa 1.800 ticket al mese.

Sul merito il sistema ha lavorato bene. Il Critico-Validatore ha calcolato che con due persone bisognerebbe automatizzare il 67% dei ticket, contro un 40% realistico, lasciando a ciascun operatore circa 540 ticket al mese. L’agente etico ha segnalato il piano come linea rossa, quattro licenziamenti di persone a tempo indeterminato decisi su un’ipotesi mai verificata, e il motore ha fermato tutto finché la persona non ha deciso. Ne è uscito un pilota a fasi sulle richieste di stato ordine e documenti di trasporto, con soglie di automazione da superare prima di toccare un posto di lavoro.

Sul metodo invece ho trovato un limite. Ogni nuovo agente che segnalava le stesse lacune nei dati riapriva un gate già chiuso, e una decisione in modalità rapida ne ha accumulati dodici, dieci per una lacuna che la persona aveva già accettato. Un sistema che chiede conferma troppe volte insegna a confermare senza leggere.

Nella 3.0.1 il registro della decisione lo scrive il runtime

I difetti di integrazione emersi nelle sessioni non comparivano nei test automatici, perché quei test parlavano con il motore direttamente, senza un modello in mezzo. Nella 3.0 il motore c’era, ma ogni suo controllo passava ancora dalla collaborazione dell’orchestratore, che doveva consegnargli gli output degli agenti, consegnarli intatti e fermarsi ai gate. Nelle sessioni l’orchestratore consegnava, ma a modo suo: in un caso ha accorciato l’output di un agente prima di inviarlo, ammettendolo lui stesso subito dopo.

La 3.0.1 toglie l’orchestratore dalla strada tra l’agente e il registro. Claude Code permette di agganciare comandi a eventi del runtime, e il plugin ne usa uno, SubagentStop, che scatta quando un sub-agente termina, in primo piano o in background. A quel punto il runtime esegue aits hook subagent-stop, che legge l’ultimo messaggio dell’agente, ne estrae l’envelope JSON, lo valida, valuta le regole e lo scrive nel registro marcandolo come copia del runtime. Quando poco dopo l’orchestratore manda la sua versione, il motore la riconosce come la stessa uscita, la registra come resubmission e tiene solo i metadati che il runtime non conosce, cioè quale modello e quale famiglia l’hanno prodotta. Nel registro della simulazione la sequenza si legge così:

{"seq":15,"type":"envelope","data":{"agent":"ethical-governance","status":"accepted","source":"runtime"},"prev":"ea8c21…","hash":"515b04…"}
{"seq":16,"type":"resubmission","data":{"agent":"ethical-governance","target_seq":15,"identical":true},"prev":"515b04…","hash":"d67455…"}

Il ragionamento è quello della contabilità, dove la scrittura parte dal documento originale e non dalla sintesi di chi gestisce il conto. Un registro alimentato dal narratore resta il racconto del narratore, e per un decisore o per un revisore che deve ricostruire chi ha detto cosa la differenza conta più di qualunque funzione nuova. C’era anche un effetto concreto sulle regole: la regola R7 apre un gate quando un agente fallisce lo schema due volte di seguito, e con due copie della stessa uscita sbagliata il gate si apriva senza che l’agente avesse avuto il suo secondo tentativo. Adesso il motore conta i tentativi dell’agente, e il numero di invii dell’orchestratore non pesa più.

Le altre correzioni seguono la stessa logica, ridurre quello che dipende dalla buona volontà del modello. I sub-agenti non vedono la variabile con cui Claude Code indica dove è installato il plugin, quindi non trovavano schemi e riferimenti, e uno di loro ha cercato i file sull’intero disco; adesso un secondo hook, all’avvio della sessione, scrive quel percorso nell’ambiente dei sub-agenti. Gli agenti che non riuscivano a leggere il proprio schema restituivano JSON a modo loro, e la soluzione è stata generare la busta esatta direttamente dagli schemi e inserirla in ogni file agente, con un test che la valida contro gli schemi stessi a ogni build. La prima versione di quella busta aveva un errore di forma, e il motore l’ha rifiutata alla sessione successiva: il test è nato da lì.

Un gate senza risposta al modulo accetta le parole riportate della persona

Il gate è il punto in cui AITS si ferma e chiede a una persona. Il canale più solido è il modulo che il client MCP mostra direttamente all’utente, perché lì il modello non può rispondere al posto suo. Nelle sessioni senza nessuno davanti allo schermo, quelle avviate da una pianificazione o da riga di comando, il client dichiarava di saper mostrare il modulo, nessuno lo compilava, e il gate restava aperto per sempre anche quando la persona aveva risposto nella conversazione.

Ho scelto di accettare in quel caso la risposta riportata dal modello, purché contenga le parole della persona; il registro la marca come riportata e annota che il modulo non ha avuto risposta, mentre un rifiuto esplicito del modulo continua a lasciare il gate aperto. Un controllo che blocca per sempre finisce disattivato da chi lo usa, e preferisco un canale più debole dichiarato nel registro a un aggiramento che non lascia traccia. Il limite si è visto subito, perché in una delle riprese l’orchestratore ha esteso un «procedi» dato su un gate anche a un gate vicino. Per questo il canale va scritto accanto a ogni risposta, così chi legge il registro sa quali decisioni sono passate da un modulo e quali da una citazione.

Due comandi installano AITS in Claude Code

In Claude Code bastano due comandi:

/plugin marketplace add fabiolalli/aits-agents
/plugin install aits@aits-marketplace

Il plugin porta con sé gli undici agenti, i playbook, il motore come server MCP e gli hook. /aits:full avvia un’analisi completa con il controllo umano a ogni passaggio, /aits:quick una decisione rapida in cui gli agenti condizionali entrano solo se una regola li chiama, /aits:diverge una fase solo generativa con il Critico lasciato fuori apposta, mentre /aits:board mostra lo stato di una decisione. Su claude.ai si carica la cartella skills/aits come skill, con altri client si collega il motore come server MCP, e chi vuole sapere quali modelli hanno prodotto ogni output copia aits.config.yaml nel progetto.

Gli ambiti sono quelli dei sette playbook pronti: go/no-go, lancio di un prodotto, due diligence per un’acquisizione, valutazione dei rischi, sprint di innovazione, impatto etico e risposta a una mossa di un concorrente. Rende di più sulle decisioni che costano care se sbagliate e che toccano persone, dove un registro verificabile di chi ha deciso cosa pesa quanto la decisione. Il report finale mette in fila gli elementi utili a chi deve documentare la supervisione umana richiesta dall’AI Act, come materiale di supporto, perché l’applicabilità va valutata caso per caso con un legale.

Gli esiti delle decisioni reali guideranno la 3.1

Il repository contiene già un banco di prova che riesegue decisioni passate e misura quanti gate e quanti rischi il sistema avrebbe intercettato e quanto erano calibrate le sue probabilità, ma per ora l’unico caso è sintetico. Dopo venti previsioni risolte per agente il motore inizia a ricalibrarle da solo, ed è lì che la memoria smette di essere un archivio.

Nella 3.1 entreranno le cose emerse dalla simulazione, un’accettazione umana che copre la stessa lacuna anche negli output successivi, una risposta ai gate che dica «cambio piano» invece di «procedi», e una scelta netta su quante volte far girare gli agenti critici in modalità rapida. In Pelle Digitale avevo descritto l’interfaccia come il punto in cui si negozia la fiducia fra noi e le macchine, e un gate è proprio quel punto: se si apre troppo spesso diventa rumore, se si apre troppo poco diventa una firma in bianco.

Chi ha in mano una decisione già presa, di cui oggi conosce l’esito, e vuole vedere cosa ne avrebbe detto AITS mi trova dalla pagina contatti. Con dieci casi così saprò quanto vale il sistema, oppure scoprirò che il prossimo pezzo da riscrivere è un altro.

Il codice è pubblico su GitHub con licenza MIT

AI & GENAI, PROGETTI E IDEE

Plenipo e l’EUDI Wallet: dare agli agenti AI un mandato invece dei pieni poteri

Domenica 25 ottobre ho reso pubblico il repository di Plenipo, la libreria che fa approvare dall’EUDI Wallet un mandato per gli agenti AI, e ho pubblicato la versione 0.4 su npm, con licenza Apache 2.0. Il mio vero primo progetto OpenSource, dopo LocalAI.

Nella stessa giornata il primo wallet reale, la Wallet API di walt.id, ha completato tutto il flusso, dalla richiesta del mandato fino alla verifica, e la sandbox è andata online con una vetrina che mostra in diretta cosa succede quando un agente prova a pagare.

In pratica una persona autorizza un agente con un mandato firmato dal proprio wallet, e qualunque servizio, una banca per esempio, verifica quel mandato prima che l’agente agisca. Lo racconto qui perché è un esperimento, con i suoi limiti dichiarati, e perché la domanda da cui nasce mi sembra più grande del codice che ho scritto per rispondere.

Un registro che non dice chi c’è dietro

Tutto parte da un fastidio. Quest’anno, studiando l’EUDI Wallet dentro un progetto di sperimentazione, mi sono messo a guardare come reti di carte e startup statunitensi stanno costruendo i registri degli agenti AI, gli elenchi che servono a un commerciante per riconoscere chi bussa alla sua API. Funzionano, ti dicono quale software ha agito e con quale chiave, ma quasi mai rispondono alla domanda che interessava a me: chi c’è dietro quell’agente, e con quale autorità lo ha mandato a spendere?

Nel frattempo in Europa sta succedendo una cosa che fuori dagli addetti ai lavori si racconta poco. Il regolamento eIDAS 2 chiede a ogni Stato membro di offrire ai cittadini un EUDI Wallet entro la fine del 2026, con dentro il PID, l’identità digitale con valore legale, e il protocollo con cui il wallet presenta le credenziali, OpenID4VP, prevede un meccanismo chiamato transaction data che permette alla persona di approvare in modo vincolante un contenuto mostrato a schermo, con una firma che copre esattamente quei byte.

Ho messo insieme le due cose. Se l’EUDI Wallet sa già firmare quello che leggo, può firmare anche il perimetro dentro cui un agente lavora per me, senza inventare identità nuove né chiavi radice nuove.

Il mandato come oggetto da firmare

Il nome viene da plenipotenziario, chi agisce con pieni poteri per conto di un altro, e il motto del progetto lo rovescia: «Mandates, not full powers». Un mandato Plenipo è un oggetto piccolo e chiuso, con le azioni permesse (pagare bollette, comprare biglietti del treno), i beneficiari ammessi, un tetto per singola operazione e uno complessivo, una data di inizio e una di scadenza, la chiave pubblica dell’agente e il numero massimo di sub-deleghe.

Le regole sono poche e testarde. Ogni mandato ha una scadenza obbligatoria, per default al massimo novanta giorni, e non può durare più del PID che lo ha firmato; se l’agente passa il lavoro a un sub-agente, il figlio può solo stringere il perimetro del padre, e un campo che il sistema non conosce viene rifiutato invece di essere ignorato, perché potrebbe essere un vincolo che qualcuno voleva applicare. La revoca passa da una Token Status List, lo standard IETF che l’EUDI Wallet usa già per sospendere le credenziali, e vale dal controllo successivo.

Ho lavorato molto su un dettaglio che sembra minore: quello che la persona vede deve coincidere con quello che viene applicato. Il mandato viaggia in JSON canonico, il wallet ne firma l’hash, e qualunque differenza fra il testo mostrato e il testo verificato porta al rifiuto. In Pelle Digitale avevo provato a descrivere le interfacce come la superficie dove si negozia la fiducia fra noi e le macchine, e qui quella superficie è una schermata di consenso dell’EUDI Wallet, dove la frase che approvi diventa letteralmente la regola.

Dal PID nell’EUDI Wallet al bonifico rifiutato

Il percorso completo ha diversi passaggi, ma si racconta in poche righe. La piattaforma che ospita l’agente prepara il mandato e lo trasforma in una richiesta OpenID4VP, la persona apre il link o inquadra il QR, il wallet mostra il mandato e risponde con il PID e la firma; del PID, per default, la richiesta chiede soltanto nome e cognome. Da lì l’agente porta con sé la catena, cioè la radice firmata dalla persona più le eventuali deleghe, e firma ogni singola chiamata legandola a quella catena precisa e a un nonce che vale una volta sola.

Dall’altra parte la banca, o qualunque servizio che riceve la richiesta, ricontrolla tutto in un ordine stabilito, dalla radice alle deleghe, dal tempo alla firma dell’invocazione, poi l’ambito e la revoca, e solo alla fine riserva l’importo in modo atomico contro ogni tetto della catena. Se qualcosa non torna arriva un rifiuto con un codice preciso, LIMIT_TOTAL o COUNTERPARTY_NOT_PERMITTED o REVOKED, e il denaro resta dov’è. La libreria si integra come guardia attorno a uno strumento MCP oppure come gateway HTTP davanti a un’API esistente.

Quello che mi ha convinto di più l’ho visto nella sandbox, in uno degli scenari scriptati. Un documento contiene un’istruzione nascosta che prova a far pagare un beneficiario diverso da quello vero, il modello può anche cascarci, e la banca rifiuta comunque, perché quel beneficiario nel mandato non c’è. Ne avevo scritto parlando di tool, skill e MCP: ogni strumento che un agente usa ha un gemello organizzativo, e una delega di potere con una soglia è proprio quel gemello, scritto in una forma che una macchina può verificare.

544 test e nessun audit esterno

Oggi Plenipo è alla versione 0.4, con 544 test nella libreria (compresi vettori di prova e test di fuzzing) e 56 nella sandbox, e una CI che gira su Node 22 e 24 con Postgres e Redis. Ci sono gli store condivisi per chi lavora su più istanze, un gateway HTTP con errori in formato RFC 9457, un registro di audit a catena di hash, l’export verso OPA e Cedar per chi ha già un motore di policy, e la gestione delle chiavi in KMS o HSM.

Sul fronte dei formati ho provato a parlare le lingue che i wallet parleranno. Oltre al tipo proprio di Plenipo c’è una mappatura verso l’e-mandate di TS12, la specifica europea per i pagamenti con il wallet, e un modello sperimentale per le persone giuridiche, dove chi firma per un’azienda presenta anche un’attestazione di ruolo e il mandato non può uscire dai poteri che quel ruolo gli dà.

Il codice ha passato due giri di revisione di sicurezza fatti con agenti AI indipendenti, che hanno trovato 35 problemi, sette gravi, tutti corretti con un test che riproduce l’attacco. Lo scrivo per quello che è: due revisioni automatiche non valgono un audit esterno, che non c’è ancora, e il README avverte di non usare Plenipo per proteggere denaro o dati reali. Wallet, PID provider e banca della sandbox sono simulati, la crittografia no.

Il passo che mi ha fatto più piacere è arrivato domenica, quando la Wallet API 2 di walt.id ha completato il flusso sia con il tipo di mandato di Plenipo sia con un e-mandate TS12 legato al PID. Va detto con precisione, perché chi lavora nei pagamenti lo noterebbe subito: quella seconda modalità serve ai wallet configurabili e ai test, mentre i wallet certificati TS12 legheranno l’e-mandate a un’attestazione della banca del pagatore, un passaggio che dipende dai PSP e che ancora non esiste.

Una scelta che passa dal codice pubblico

Ho deciso di aprire tutto, codice, sandbox e specifiche, con licenza Apache 2.0. Un meccanismo di fiducia che nessuno può leggere chiede esattamente il tipo di fede che vorrebbe eliminare, e chi dovrà accettare un pagamento firmato da un agente deve poter verificare ogni riga prima ancora di sedersi a parlarne.

Con la sandbox pubblica ho voluto rendere il tutto toccabile. Si collega Claude come connettore personalizzato all’endpoint MCP della sandbox, gli si chiede di pagare una bolletta, lui chiede un mandato al wallet di test e restituisce un codice di sei caratteri, e su plenipo.net/demo si vede in tempo reale ogni decisione della banca, con i soldi finti e i controlli veri. È il modo più rapido che ho trovato per spiegare a chi lavora nei pagamenti cosa succede quando l’agente sbaglia, o quando qualcuno prova a farlo sbagliare.

Qualche giorno fa avevo scritto della minimizzazione dei dati come scelta su quanto potere diamo all’AI. Un mandato è la stessa scelta presa dall’altro lato, quanto potere diamo all’agente quando esce a spendere per noi.

Il prossimo passo è un telefono

La sperimentazione adesso deve uscire dal laptop. Il prossimo passo è il wallet di riferimento europeo su emulatore Android, che può dichiarare tipi di transaction data propri ma va modificato per mostrare il mandato nella schermata di consenso, e poi IT-Wallet, dove serve un dialogo con chi gestisce lo schema perché oggi non c’è supporto pubblico per tipi personalizzati.

Lato mercato guardo in due direzioni. Le banche e i PSP, che con TS12 dovranno decidere se e come accettare l’e-mandate per il commercio fatto dagli agenti, e le imprese, dove un amministratore che affida un acquisto a un agente lo deve fare dentro i poteri di firma che ha davvero, con un registro che lo attesti. Su entrambi i fronti mancano ancora pezzi normativi, dagli atti di esecuzione sugli European Business Wallet a una regola comune per le attestazioni SCA, e Plenipo per ora riempie i vuoti con formati propri dichiarati come tali.

Non ho ancora capito quale di queste porte si aprirà per prima, e alcune scelte, il legame fra l’attestazione della banca e il PID per esempio, non spetta a me prenderle da solo. Fra pochi mesi però milioni di europei avranno in tasca un’identità con valore legale, e mi sembra il punto giusto da cui far partire la fiducia verso gli agenti, prima che qualcun altro la definisca altrove con regole che non possiamo leggere.

Dove trovare Plenipo

Chi lavora in una banca, in un PSP o su un wallet e vuole provarlo su un caso concreto mi trova dalla pagina contatti.

Riferimenti: Regolamento (UE) 2024/1183 (eIDAS 2), OpenID4VP 1.0, EUDI TS12.

AI & GENAI, PROGETTI E IDEE

Adaptive Intelligence Thinking System (AITS): un nuovo paradigma per il decision-making nell’era dell’intelligenza ibrida

Viviamo in un momento storico in cui il pensiero umano non può più prescindere dalla collaborazione con l’intelligenza artificiale. Dal lavoro di sperimentazione su diversi progetti e clienti ho dato vita all’Adaptive Intelligence Thinking System (AITS), un modello che rappresenta la naturale evoluzione del celebre metodo dei “Six Thinking Hats” di Edward de Bono, aggiornato e potenziato per affrontare la complessità del mondo contemporaneo.

Come nasce il modello AITS

Il modello AITS nasce dalla mia personale esperienza ultraventennale nel settore digitale e innovativo, dalla pratica continua nel supportare aziende e startup, e dall’osservazione diretta di come i metodi tradizionali, anche i più robusti come quello di de Bono, stiano mostrando limiti di fronte alle sfide del nostro tempo: accelerazione tecnologica, sovraccarico informativo, e decisioni sempre più interconnesse e multidimensionali.

AITS è stato progettato partendo dalla struttura concettuale dei “Six Thinking Hats” e integrandovi il potere dell’intelligenza artificiale per rendere il processo decisionale più adattivo, dinamico e sistemico.

A cosa serve AITS

Il sistema AITS non serve solo a prendere decisioni migliori, ma a sviluppare una cultura del pensiero critico e strategico. È utile in contesti aziendali complessi, nella gestione della trasformazione digitale, nell’innovazione di prodotto, nel crisis management, e in tutti gli ambiti in cui è necessaria una visione sistemica e inclusiva.

Con AITS, organizzazioni e professionisti possono affrontare decisioni strategiche con una modalità più robusta, chiara e inclusiva, ottenendo risultati più efficaci e sostenibili.

Il significato di Adaptive Intelligence Thinking System

  • Adaptive: indica la capacità del sistema di adattarsi dinamicamente al contesto, alle informazioni emergenti e al feedback continuo.
  • Intelligence: rappresenta l’integrazione dell’intelligenza umana con quella artificiale, creando un ecosistema cognitivo ibrido.
  • Thinking System: è un sistema strutturato di pensiero, basato su agenti cognitivi specifici che operano in sinergia, ciascuno con una funzione dedicata.

I pillar del modello AITS

Il modello poggia su tre pilastri fondamentali:

  1. Intelligenza Ibrida: l’interazione tra umani e AI è strutturata in modo che entrambi apportino il massimo valore possibile, combinando intuito e creatività umana con potenza analitica e predittiva della tecnologia.
  2. Adattività dinamica: la struttura di AITS permette la massima flessibilità, adattandosi in tempo reale ai feedback e ai cambiamenti, con modalità operative sequenziali, parallele o emergenti secondo la necessità.
  3. Etica integrata: l’approccio etico non è opzionale, ma strutturale: ogni decisione viene valutata sotto il profilo etico e della responsabilità, evitando rischi reputazionali e morali.

La value proposition di AITS

AITS offre un vantaggio competitivo significativo in un contesto dominato dalla complessità e dalla velocità decisionale:

  • Decisioni più robuste e veloci: grazie all’uso di intelligenza artificiale e al metodo parallelo-distribuito, si ottengono decisioni più rapide e basate su un numero maggiore di dati e scenari possibili.
  • Trasparenza e accountability: ogni fase decisionale è tracciata, auditabile e spiegabile, garantendo trasparenza interna ed esterna.
  • Cultura del pensiero potenziata: il metodo stimola una cultura organizzativa orientata all’apprendimento continuo, all’innovazione e alla responsabilità etica.

Come si usa, i nuovi cappelli e ambiti di applicazione già testati

AITS si utilizza attivando, in modo strutturato e flessibile, i suoi otto agenti cognitivi, che sostituiscono e ampliano i tradizionali cappelli di de Bono: Analitico, Emotivo-Intuitivo, Critico-Validatore, Ottimizzatore, Creativo-Generativo, Etico-Governance, Predittivo-Strategico e Meta-Orchestratore. Ciascun agente può essere umano, artificiale o ibrido, a seconda delle esigenze e del contesto.

Ho già applicato con successo AITS in diversi contesti: dalla pianificazione strategica aziendale alla gestione della trasformazione digitale in grandi organizzazioni, dall’innovazione di prodotto in aziende tech al crisis management in situazioni di emergenza. I risultati ottenuti confermano che l’AITS non è solo teoricamente robusto, ma anche altamente efficace nella pratica reale. Ne sto proseguendo studio e implementazione e nei prossimi giorni ne rilascerò ulteriori contenuti.

A chi serve il modello AITS

AITS è pensato per:

  • Manager e decision-maker: che devono guidare organizzazioni attraverso scenari complessi e dinamici, gestendo innovazione e trasformazioni profonde.
  • Professionisti e consulenti: che operano in settori dove la velocità e la qualità delle decisioni sono cruciali (innovazione, finanza, tech, salute, policy).
  • Formatori ed educatori: per insegnare metodi decisionali avanzati e sviluppare competenze di pensiero critico, etico e strategico nelle nuove generazioni.
  • Startupper e innovatori: per validare idee e strategie di business in modo strutturato, integrando intelligenza artificiale e analisi dei dati fin dall’inizio.

Questo modello rappresenta a mio avviso un nuovo paradigma nel decision-making: non soltanto un’evoluzione di un metodo esistente, ma come nuova modalità di interazione uomo macchina nei processi di bransttorming, creativi e progettuali.

Adaptive Intelligence Thinking System è un metodo originale e innovativo, sviluppato da Fabio Lalli, frutto della mia esperienza e ricerca personale e professionale come evoluzione del modello Six Things Hat di Edward De Bono. Il contenuto e la struttura sono protetti da copyright e proprietà intellettuale.

PROGETTI E IDEE

These AppyDays are yours and mine (oh Happy Days)

Ci siamo quasi. l’AppyDays sta per iniziare.

L’emozione e la stanchezza, l’adrenalina e la preoccupazione dei preparativi dell’ultimo minuto si alternano velocemente. Mi sembra ieri che tutto è partito. Ora siamo alle ultime ore prima dell’inizio.

Giovedi 25 Settembre inizia tutto. Domenica 28 finisce. Saranno 4 giorni intensissimi. Workshop, panel, idee, progetti ed hackathon. Aperitivi e musica in piazza.

Tutto si svolgerà a Todi, una città che sembra sperduta nel cuore dell’Italia ma che contiene in se un clima, dei panorami e una qualità della vita eccezionale. In questi 4 giorni ospiterà l’AppyDays e sarà il palcoscenico di un forte confronto tra passato e futuro, storia di ieri e storia di oggi.

Sarà il primo evento in grado di avvicinare tutti, dai bambini agli adulti, dai professionisti alle aziende, alla rivoluzione digitale in atto, generata e spinta alla velocità della luce dalle tecnologie mobile. Avremo modo di raccontare come questa rivoluzione mobile stia modificando abitudini, processi cognitivi, modalità di ricerca di informazioni, processi di pagamento e tanto altro. Partiremo da quando ci svegliamo la mattina ed utilizziamo la sveglia sullo smartphone, passando dalla ricerca del ristorante, la lettura del giornale, l’educazione dei bambini, il fitness e lo sport, i social ed il dating, fino alla religione e tutte le tecnologie Wearable e IoT.

Ci saranno molti relatori, sviluppatori e aziende che racconteranno i loro progetti, i loro successi e le criticità che oggi il mobile, sta affrontando. Avremo modo di confrontarci sulle opportunità di business e sulle modalità per riuscire a far crescere un progetto oggi.

Non saranno solo successi, perchè il digitale non è solo questo: racconteremo anche dei fallimenti di alcuni progetti e di alcune iniziative che, nel marasma del digitale, non sono riuscite ad emergere.

Di argomenti da seguire ce ne sono, considerando che abbiamo superato i 100 relatori ed un gran numero di app presenti nei vari corner. Ci saranno le community Instagramers, programmatori e Indigeni Digitali con il Camp2014.

Io sarò presente in molti panel e workshop. In particolare mi troverete:

  • Inaugurazione Tody AppyDays: il perchè dell’evento ed il mercato delle app.
    Dove: Sala del Consiglio
    Quando: 25 settembre 2014 – 10.30 / 11.00
  • Wearable: quando la tecnologia si indossa
    Dove: Cinema Jacopone
    Quando: 25 settembre 2014 – 20.30 / 21.30
    Ruolo: moderatore
  • APPgrade: evangelizzazione e nuovi media digitali
    Dove: Sala del Consiglio
    Quando: 26 settembre 2014 – 16.00 / 17.00
    Ruolo: moderatore
  • Digital Fitness: Grazie ad App e Wearable Device, allenarsi non è mai stato cos’ Hitech (ed efficace)
    Dove: Sala Affrescata
    Quando: 28 settembre 2014 – 19.00 / 20.00
    Ruolo: relatore
  • Internet of Everything: l’esperienza dell’utente al centro di tutto
    Dove: Cinema Jacopone
    Quando: 26 settembre 2014 – 20.30 / 21.30
    Ruolo: moderatore
  • Nearable: più vicini che mai
    Dove: Sala delle ceramiche
    Quando: 27 settembre 2014 – 17.00 / 18.00
    Ruolo: moderatore
  • AppStars: storie di app italiane in store
    Dove: Sala del Consiglio
    Quando: 27 settembre 2014 – 20.30 / 21.30
    Ruolo: moderatore

Insomma, da fare ne avrò e avremo modo di incontrarci per le strade o le Piazze di Todi. Ci saranno tutti. Forse gli unici che mancheranno, saranno solo Ricky Cunningham e Arthur Fonzarelli, per adesso.

E se volete rimanere aggiornati in realtime e condividere la vostra esperienza l’hashtag #todyappydays . Se invece volete scaricarvi le app per iOS o Android dell’evento, potete farlo dal sito http://app.appydays.it

Il Festival delle App è ormai alla partenza e tutto questo non sarebbe stato possibile senza l’organizzazione ed il lavoro dei miei ragazzi, in particolare Andrea e della società SediciEventi.

Io ci ho messo cuore, testa e faccia in qualità di direttore tecnico: mi auguro che l’evento sia all’altezza delle vostre aspettative ed in grado di lasciarvi qualcosa di positivo da portarvi a casa e al lavoro.

Enjoy! Ci vediamo a Todi.

PROGETTI E IDEE

L’utente al centro dell’esperienza dell’evento

Butto giù una riflessione nata dopo la partecipazione ad un evento recentemente. In Italia.

Mi capita spesso, soprattutto in Italia appunto, che di ritorno da alcuni eventi io senta manifestare e condividere un alto livello insoddisfazione, un crescente livello di frustrazione derivante dal continuo malcontento e dell’esperienza vissuta non ne rimane nulla se non solo il ricordo dell’inefficienza organizzativa fatta di mal funzionamenti del wifi, poca disponibilità d’informazioni, livello di contenuto dei relatori non adeguato al costo o difficoltà nell’utilizzo dei servizi dell’evento grazie alla poca organizzazione della logistica.

Ritengo che la pianificazione di un evento non può esser sottovaluta, gestita senza criterio o superficialmente, più che mai se si ambisce ad esser un evento di successo, proprio come avviene negli eventi all’estero. E’ necessario che la “cultura dell’evento” entri nel DNA degli organizzatori, così come lo è già fuori dall’Italia, e l’organizzazione non si limiti alla sola scelta del catering o alla location migliore.

L’errore che si sta continuando a fare (e che spesso ritrovo anche in manifestazioni importanti, manifestazioni pubbliche o di grandi aziende) è quello di costruire l’evento intorno al brand, pensando che i partecipanti siano la parte finale dell’evento, dei meri spettatori a cui propinare un messaggio, un prodotto o un marchio.

E tutto questo si manifesta con una cattiva pianificazione dei processi, un superficiale dimensionamento del wifi o della connettività, la mancanza di comunicazione fisica e una logistica poco idone (audio, sala, temperatura, copertura 3G).

Questo approccio non può più funzionare e gli utenti se ne stanno accorgendo.

Oggi un evento deve esser progettato con un mix di più fattori e scelte organizzative integrate fra loro in maniera organica e studiate in modo tale da rendere l’esperienza dell’utente completa dalla prenotazione, alla fruizione dell’evento, per passare dal post evento fino al follow up.

L’utente di una manifestazione non è più un semplice partecipante, ma è (e deve esser) parte attiva in termini di amplificazione e costruzione del contenuto. L’utente è il motivo, primo, della riuscita dell’evento.

E’ fondamentale quindi focalizzare l’attenzione sull’utente, metterlo al centro dei processi di interazione e la sua esperienza fisica, nel contesto dell’evento, deve esser completamente integrata con quella digitale in una naturale continuità informativa.

L’utente al centro dell’esperienza dell’evento: ecco cosa fare per organizzare un evento oggi, che vuole ambire ad esser un riferimento.

Recentemente ho partecipato ad eventi internazionali, ed il livello come dicevo sopra è di gran lunga differente. Faccio l’esempio l’EMCWord di Las Vegas, al quale ho partecipato anche quest’anno per la seconda volta consecutiva, che ritengo forse uno dei migliori eventi ai quali abbia mai partecipato per livello di attenzione, dettaglio ed esperienza utente generata. Dalla qualità dei relatori, al livello di contenuto, alla modalità di interazione, alle tecnologie di prossimità, alla connettività, all’organizzazione maniacale fino ad arrivare a gadget, interazione stand/utente, engagement, gamification e tanto altro. E non parliamo di un evento da poche persone, ma di un evento da circa 15K persone partecipanti in 5gg.

Sintetizzando quanto detto sopra e che, a mio avviso, un evento deve necessariamente avere oggi affinché possa raggiungere un livello di coinvolgimento alto e un risultato eccellente, i cinque concetti chiave sono:

  • produrre contenuti rilevanti ed assicurarsi che il pubblico riceva informazioni di interesse e valore, indipendentemente dal brand
  • dare al pubblico il controllo delle informazioni ed una gestione / fruizione migliore del servizio attraverso l’utilizzo di tutti i canali informativi a disposizione evitando malfunzionamenti proprio nel momento della partecipazione all’evento
  • aumentare i touch point, che grazie alle tecnologie mobile, di prossimità (pensate a NFC, RFid, QrCode, iBeacon) e di contatto (totem, wall interattivi, pavimenti, schermi, macchinette e distributori), possano abilitare il pubblico all’interazione con il contenuto dell’evento permettendo così di contribuire alla costruzione del contenuto e del valore, come vogliono, quando vogliono e in nelle modalità che conoscono.
  • costruire una relazione con l’utente che inizi con la fase di registrazione, sia viva ed interattiva durante l’evento e prosegua post evento con informazioni rilevanti, materiale e follow up.

Apparentemente sembra tutto molto semplice. Apparentemente.

Nei prossimi mesi (dal 25 al 28 settembre) supporterò, in qualità di direttore tecnico/creativo, l’evento AppyDays a Todi nel quale cercherò di capitalizzare l’esperienza fatta all’estero ed i concetti raccolti in questo post. Siete ovviamente invitati. Enjoy.

PROGETTI E IDEE

Wearable: second display, notifications e nuove interazioni

Da qualche tempo sono entrato in possesso dei Google Glass e del nuovo Samsung Gear. Mi sono preso qualche giorno per provare tutto ed utilizzare un sistema completo fatto da smartphone Android + Account google + dispositivi wearable prima di dare feedback e condividere pensieri ed opinioni in modo prematuro.

Di solito non scrivo recensioni di prodotti tech, e questo post non vuole appunto una recensione. Piuttosto vorrei condividere una riflessione molto pratica sul futuro dei dispositivi indossabili e delle opportunità che si possono aprire con la diffusione e l’adozione di queste nuove tecnologie.

Second display, notifications e nuovi processi. Questa è la sintesi della mia esperienza. Dopo aver indossato insieme Gear e Glass, abilitati da un sistema completo come quello Android, durante una giornata tipo, posso confermare che il vero valore è nella possibilità di liberare le mani dallo smartphone ed avere una fruizione più naturale delle informazioni. In mobilità. Una esperienza molto meno vincolante.

In pratica il vantaggio di questi dispositivi non è nell’aggiungere nuove funzionalità ma migliorare l’esperienza attuale e la fruizione di alcune informazioni disponibili già sullo smartphone, trasformando il processo di ricerca, fruizione e consumo in modo più naturale, annullando quasi completamente la necessità di tenere impegnate mani o sguardo.

L’esempio testato personalmente, è un viaggio in scooter per andare da un cliente:

GalaxyS3 nella borsa, Gear al polso e Glass indossati. Navigatore attivo tramite il Galaxy. Informazioni, notifiche, ed eventi al polso in realtime. Sul display dei glass  il tragitto ed altre notifiche. Squilla il telefono, vedo dall’orologio il chiamante, rispondo e faccio lo switch dell’audio sui Glass. Continuo il percorso, completo la chiamata, arrivo a destinazione sapendo di aver ricevuto 8 email e aver visto in anteprima l’sms ricevuto. Sano e salvo. Senza toccare lo smartphone.

Qualcuno mi dice che sono troppo multitasking. Vero, ma sarà necessario in futuro esser ancora più multitasking? Secondo me no, anzi, le cose potrebbero cambiare. L’orologio siamo abituati a guardarlo già normalmente. Il display dei Glass si controlla con la stessa esperienza d’uso e colpo d’occhio con il quale si controlla lo specchietto retrovisore della macchina. In linea generale la mia esperienza mi porta a pensare il contrario: utilizzando i sensi e gli arti in modo più naturale, tutto si facilità e ritorna ad “esser normale”. Non avremo bisogno di tenere impegnata la mano per impugnare il cell, controllare il display e guardare avanti e potremmo allontanarci da molti altri piccoli “tic” che abbiamo (controllare le notifiche, accendere il cell anche quando in standby…). Forse ne avremo altri? Possibile.

Il concetto che comunque vorrei sottolineare è l’importanza del display secondario e delle notifiche: sempre in modo più pervasivo siamo bombardati da notifiche e suoni che ci distraggono portando l’attenzione sullo smartphone. Avere un sistema integrato che ci permetterà di estendere il display ed indossarlo in parti del corpo comode (polso, dito, occhiali) , avere delle notifiche in punti più funzionali e leggibili, sarà necessario.

Pensate banalmente al pagamento possibile con gli occhiali. Avete il moribondo QrCode? Ecco, immaginate di poter guardare lo scontrino con il suo codice attraverso l’occhiale, veder apparire la conferma di pagamento, processare il tutto senza fare almeno 4 azioni (prendi il portafogli, metti la carta, inserisci il pin, riprendi la carta). Ma non solo, le applicazioni sarebbere tantissime.

1458444_753345621361548_468832484_n

Il tema del futuro non sarà la quantità e la qualità della tecnologia indossata ma l’attenzione richiesta per gestire la tecnologia.

Chi riuscirà a progettare sistemi sempre più utente centrici ed integrati, vincerà la battaglia sul mercato.

Sulla base di questa esperienza fatta (e che continuerò a fare per capire sempre meglio come inserire queste tecnologie nei processi di vita) e sulla base dei progetti che stiamo portando avanti, ho pensato di realizzare un elenco di principi per la progettazione di tecnologie indossabili. In particolare, secondo me, un progetto wearable dovrà:

  1. risolvere un problema sostanziale e ricorrente per la persona
  2. avere una progettazione che parte dall’uomo e non dalla tecnologia
  3. migliorare l’esperienza e non distrarre con notifiche eccessive
  4. aumentare le capacità umane, non sostituirle
  5. diminuire i problemi generati dall’aumento degli oggetti tech indossati
  6. connettere anche altri sistemi senza necessariamente aver N dispositivi tra di loro “sordi”
  7. permettere una scalabilità del software indipendentemente dallo sviluppo hardware
  8. ridurre l’invasività dell’hardware in modo inversamente proporzionale al software sempre crescente
  9. evocare una sensazione naturale e non richiedere alla persona di adattare e forzare il comportamento.
  10. rafforzare l’esperienze dell’utente rendendola più ricca e memorabile 
  11. automatizzare e snellire interazioni uomo / dispositivo

Se si progettano strumenti in questo modo, la tecnologia non diventa un qualcosa in più, ma realmente una estensione della persona e dell’esperienza. E la battaglia all’esperienza, dovranno affrontarla non solo le aziende che producono le tecnologie, ma anche chi progetta servizi in cui le tecnologie sono parti integranti di uno o più processi.

L’experience e la customer experience saranno i campi su cui ci si batterà per farsi spazio tra tutti i competitor.

Mi hanno chiesto come vedo io il futuro delle tecnologie in mobilità. Io direi: un tablet, un wristband-phone e gli occhiali, tutti connessi verso il dispositivo connesso ad internet.

Sarà una esperienza magnifica. Futuristica, ma nemmeno troppo.

PROGETTI E IDEE

Viddy, l’instagram dei video, apre le API: Developer e Brand, siete pronti?

Si chiama Viddy, è una applicazione iPhone – per adesso – che permette agli utenti di condividere filmati e video da 15 secondi. Fin da quando è nata è stata battezzata l’Instagram dei video o anche il Twitter dei microfilmati. L’applicazione, malgrado abbia tra i concorrenti applicazioni del calibro di SocialCam (disponibile tra l’altro sia per iPhone che per Android), nel giro di un anno ha raggiunto circa 40 milioni di utenti. A differenza di altre applicazioni ed altre startup l’ideatore in questo caso non è un ragazzetto giovane e smanettone, ma un imprenditore della Silicon Valley Brett O’Brien già noto per il progetto xDrive e PluggedIn.

Viddy, come Instagram, mette a disposizione degli utenti un set di filtri per abbellire i video e renderli più emozionali e completi. I video possono durare al massimo 15 secondi. Ad ogni filtro nell’app è associato un loop o una breve brano musicale, che può attivato o disattivato dall’utentedi volta in volta. Le clip preparate e abbellite dagli strumenti messi a disposizione dall’utente possono esser poi condivise sui social network (Facebook, Twitter, YouTube e Tumblr), o via e-mail o Sms. Ovviamente come tutte le piattaforme social che si rispettino, e Instagram su questo ha definito delle “linee guida” che ormai troviamo ovunque, è possibile commentare i contenuti e segnalare la propria preferenza attraverso il tasto, ormai noto, del like.

Non mi dilungo sulla descrizione dell’app, di cui potete trovate in rete già molti post tra cui quello di Silvio e quello di Federico, e vorrei focalizzarmi su una notizia di oggi che, secondo me, potrebbe far diventare questa applicazione il prossimo obiettivo per gli sviluppatori e brand: Viddy apre le API e con un post sul proprio blog dal titolo “Rule the Beach: Hack Your Way into Viddy“, di cui vi riporto uno stralcio

During August and September we’ll work with you, and our developers, on adoption of the apps you build, as well as promotion to our 40 Million+ Viddy Community. On Friday, September 28th Team Viddy will pick our favorite API partner, and fly you (or your team of up to 4 people) to Venice Beach for an interview at Viddy. The cash prize of $10,000 will be awarded at Viddy HQ.

In Viddy invitano gli sviluppatori e la community a creare nuove app per una competizione da 10K dollari e la permanenza nell’HQ di Viddy in Silicon Valley. Coders in ascolto, che fate, vi perdete questa occasione?

Viddy secondo me si è mossa molto bene dal punto di vista della gestione e dello sviluppo del progetto, un po’ come fece anche Instagram nel momento della sua crescita. Il fatto di non aver puntato direttamente al multi device le ha permesso di crescere e non morire di “Scalabilità Precoce” (come successo a Picplz per non aver trovato investitori avendo costi alti di infrastruttura e nessun modello di business), e arrivare a prendere due investimenti da 36 milioni di dollari tra febbraio e aprile 2012 (un anno preciso dalla nascita del 2011).

Inoltre Viddy, proprio per la modalità con cui sta facendo crescere la propria user base (coinvolgimento personaggi famosi, brand) e creando al momento giusto “l’evento” per coders, penso riesca a scatenare la sviluppo di un ecosistema di applicazioni intorno al prodotto tale da crescere più velocemente di altri.

A mio avviso gli sviluppatori che hanno in mente di sviluppare qualche prodotto in questa direzione, dovrebbero farci una pensata: in questo momento, visto che il video è e sarà un mercato su cui sviluppare prodotti per i prossimi anni, ha molto spazio e dovrebbe esser presidiato. Ricordiamoci comunque che sviluppare prodotti legati alle API di altri comunque ci mette nelle condizioni di esser “vincolati” e non autosufficienti. Più che mai se pensate che Viddy è nel mirino di Facebook già da un po’.

I brand infine dovranno iniziare a pensare di utilizzare il video e/o pillole di video per comunicare e presentare i propri prodotti, i concept e l’azienda, così come oggi hanno iniziato a fare con Instagram in modo continuo, avvicinando l’utente anche dal punto di vista emozionale.

Io un paio di idee per partecipare già le ho, forse mi serve il tempo… ma se qualcuno volesse unirsi, ben disponibile 🙂

UPDATE 01/08/2012
Mi hanno appena abilitato le API di Viddy: il primo problema per un eventuale applicazione che cresce velocemente, sapete qual’è? Il rate limit! 2 chiamate massime al secondo, 5000 chiamate massime al giorno! Considerate che Instagram (che già di suo è particolarmente limitato) ne ha 5000 l’ora [Guarda lo screenshoot http://cl.ly/IRj9]

UPDATE 07/08/2012
Ho appena rilasciato un primo test di applicazione di mashup tra le API di Viddy e di Dropbox: ho realizzato un sistema che permette agli utenti, attraverso la doppia autenticazione Viddy e DropBox di effettuare il Backup dei video di Viddy in formato mp4 direttamente su DropBox. In pochi minuti (a seconda della velocità della vostra connessione) avrete i video direttamente sul vostro pc. L’applicazione Viddy Backup la trovate qui http://dev.fabiolalli.com/viddy/

PROGETTI E IDEE

Nel mezzo delle difficoltà nascono le opportunità

Si parla di crisi finanziaria, problemi economici e possibili bolle, ma in Italia c’è un sistema che si muove e che sta cominciando a vivere una piccola rivoluzione. E’ la rivoluzione innescata dall’ecosistema delle Startup in Italia, quella che più volte ho chiamato l’Italian Startup Revolution. Prima Coderloop, Mashape, Spreaker. Poi Mopapp, musiXmatch, Cibando, Docebo e altre. Oggi Jobrapido e Glancee.

E adesso avanti le prossime: nei momenti di crisi e difficoltà, nascono le vere opportunità.

In the middle of difficulty lies opportunity - Albert Einstein
In the middle of difficulty lies opportunity – Albert Einstein
PROGETTI E IDEE

Il tuo prodotto non ha una community, la tua community è parte del tuo prodotto

Ieri sera, tra una lettura e un’altra sono capitato su un post di SocialFresh dal titolo “Your Product Does Not Have A Community, Your Community Is Part of Your Product” e così oggi con Woork aka Antonio Lupetti abbiamo deciso di commentarlo un pò, partendo con un video post  di sperimentazione dal titolo “Tech Juice“.

[update 06/05/2012] Vi riporto il testo del video, se non avete voglia di vederlo:

Parlando dell’importanza del social, del community management e del coinvolgimento degli utenti on line, mi ritrovo spesso a dover spiegare che gli utenti non sono un problema marginale da gestire, ma una parte importante e fondamentale del ciclo di vita del prodotto.

In genere non costituiscono un elemento di disturbo o esterno al marketing, fanno parte del ciclo di sviluppo e crescita del prodotto: lo seguono, si connettono, partecipano all’evoluzione, tanto da diventarne ambasciatori, evangelist e in alcuni casi una community .

In pratica l’utente che acquista un prodotto passa da una semplice relazione di scambio di valore fisico (pago per aver il prodotto) a qualcosa di più: si sente parte integrante del prodotto e partecipa per migliorarlo, per suggerire evoluzioni e miglioramenti.

Avere un gruppo di persone che “sposano” il prodotto e la filosofia che c’è dietro diventa quindi fondamentale per poter fare domande, chiedere e dare aiuto e costruire relazioni reali, migliorando così l’esperienza d’uso e creare un legame emotivo che è difficile da sostituire. Il contributo più importante che si può raccogliere da una community deriva dalle conversazioni degli utenti. Il modo migliore per imparare che cosa il prodotto deve fare per rendere il cliente soddisfatto, è quello di recepire le opinioni degli utenti.

E’ così possibile comprendere i trend, le preferenze e i gusti, fino ad arrivare ad un alto livello di personalizzazione.

Per quanto riguarda la relazione tra gli utenti, la connessione all’interno del ecosistema del prodotto può esser stimolata, ma prima di muoversi ed agire è fondamentale osservare dove le relazioni si sviluppano spontaneamente. Prendete per esempio il caso Apple o Instagram e la community degli instagramers che si è creata intorno. Se si riesce ad instaurare una connessione emozionale positiva, verrà da se, praticamente con un comportamento naturale, l’effettivo aumento dell’attivismo degli utenti nei confronti del prodotto.

Quando le persone fanno parte di una community, vogliono essere considerate come una parte integrante del prodotto, ed per questo che vanno sottovalutate.

Il senso di appartenenza, che da un lato come detto è molto positivo, può velocemente trasformarsi in un problema : un utente ascoltato è disposto a “marchiarsi” del brand, ma se non viene ascoltato malgrado il suo attivismo, può trasformarsi nel peggiore dei “nemici”. Può influenzare negativamente gli altri utenti e generare un allontanamento dal brand.

Sviluppare quindi una comunità di utenti intorno ad un prodotto, non è solo una mera attività di marketing, ma rappresenta la costruzione di una relazione più ampia rivolta al miglioramento del prodotto stesso.

PROGETTI E IDEE

Followgr.am: vanity url, follow button, feed rss, album e altro per Instagram

Chi legge il mio blog e mi conosce sa quanto io sia un Instagram addicted: ogni posto che vado scatto foto, commento e condivido. E’ più forte di me, amo immortalare ogni piccolo momento, fermare il tempo e memorizzare quell’istante, che porterà con se un miliardo di emozioni e ricordi. E lo farà nel tempo.

L’anno scorso scrissi un post relativamente all’applicazione, ancora ai suoi primi utenti, e alla “dipendenza emotiva” che Instagram avrebbe generato negli utenti. Poco tempo dopo, appena rilasciate le API ufficiali per gli sviluppatori, scrissi un post relativo al potenziale ecosistema di applicazioni e startup che questo avrebbe generato. Tirando le somme in effetti, i numeri di Instagram, nel giro di un anno, sono stati incredibili: con soli 4 dipendenti hanno realizzato oltre 7 milioni di utenti, 150 milioni di foto ed un investimento attuale di circa 8 milioni di dollari! E pensare che sono ancora solo su iPhone: no web, no Android.

E così, come al mio solito, preso dall’entusiamo e dalla voglia di tirar fuori un altro progetto vincente, un mese fa, insieme a Lorenzo e Annalisa abbiamo dato vita a Followgram.me: un sito web dove raccogliere le foto di Instagram, poterle gestire e visualizzare. Il tutto, realizzato in una prima versione in sole 6h di lavoro (…che dopo Yeplike fatta in 72h è stata un altra piccola soddisfazione!).

La novità principale del lavoro svolto è stata quella di dare la possibilità di mostrare i propri scatti anche a chi non possedeva un iPhone, ad oggi per molti ritenuto un limite di Instagram. Qualcuno in rete, che non manca mai, ha detto (e anche twittato) subito:  “E cosa avrebbe di differente rispetto agli altri sistemi già esistenti?“.

Giusta domanda: in effetti descritta così Followgr.am somiglia a WebStagram, Extragram e al resto dei visualizzatori di foto già esistenti. Le differenze principali, a parte il rendere pubblici gli stream delle foto degli utenti, sono:

  • la Vanity Url pubblica e senza autenticazione (che è poi stata copiata anche dagli altri)
  • la possibilità di customizzare la propria pagina personale attraverso background predefiniti o uplodabili dall’utente
  • la presenza del bottone da inserire nel proprio blog (Follow Button) semplicemente copiando un pò di codice HTML

La pagina personalizzabile, secondo noi, è la funzione più interessante per i fotografi, i blogger , per il mondo della moda, del food ma anche per brand e aziende più in generale. L’idea di una pagina personalizzata in cui raccogliere le immagini del marchio potrebbe costituire una sorta di corrispettivo della pagina di YouTube, ma soprattutto la pagina personalizzata e la forza dell’indicizzazione delle pagine può diventare un utilizzo finalizzato al business e al marketing. Non solo al tempo libero. Tale funzionalità a nostro avviso, potrebbe diventare un utile strumento per un racconto ad immagini di prodotti, delle situazioni legate al personale o ad eventi e momenti legati alla promozione di un marchio. O ancora a qualsiasi altra idea legata ad uno sviluppo delle potenzialità di un singolo frame, magari impreziosito da un effetto vintage, tipico dei filtri di Instagram.

Quello che secondo me ci ha realmente differenziato fin dall’inizio, sta nel fatto che abbiamo puntato alla realizzazione di una piattaforma leggermente diversa dagli altri: non abbiamo voluto fare un ennesimo visualizzatore di foto, ma una vera e propria estensione delle funzionalità di Instagram. E’ un pò come se avessimo reso più social Instagram: l’abbiamo Twitterizzato.

Ad oggi abbiamo dato agli utenti la possibilità di avere i Feed RSS dei propri stream e poterli condividere, la possibilità di avere gli album per la raccolta di foto scattate in momenti diversi e da utenti diversi, la possibilità di navigare i tag delle foto e memorizzare le ricerche preferite. Ovviamente, non ci siamo fermati e di nuove funzionalità ne abbiamo in mente moltissime.

I risultati ottenuti fin ora, in un solo mese, sono a mio avviso discretamente interessanti: oltre 3300 utenti iscritti, 10mila visitatori unici al giorno, 35mila pagine viste al giorno ed un trend assolutamente crescente (oggi a metà giornata eravano ben oltre la metà degli utenti di ieri!). Per non parlare poi della pubblicazione già avuta, in meno di 24h, su The Next Web, su Wired, su MacWorld, Woorkup, NinjaMarketing, e su tanti altri siti nel mondo.

Per festeggiare il nostro piccolo record personale, raggiunto ieri sera (13K utenti unici in un giorno) e la registrazione di personaggi ed utenti noti come Robert Scoble, MBC, NBC, Levis, Nespresso e Neveen Salvadurati (4SQ) e altri ancora, ci siamo regalati un infografica che abbiamo pubblicato sul blog di Followgr.am.

Buona lettura e mi raccomando… Feedback, ma soprattutto RT!

Vogliamo uscire su Mashable, TechCrunch, RWW, TNW e regalarci qualche altra piccola soddisfazione 🙂