Il vero glitch dell’AI non è nel codice. È nel lessico del mercato.
Una soluzione che assomiglia a HubSpot, una che somiglia a YouTube ma fa video lezioni, una che è il clone di Instagram, e un’altra che replica un sistema di analytics tipo Google. Tutto nasce in poche ore con l’AI e, ormai, non stupisce più nessuno.
Questo, di per sé, è già un fatto enorme. Riduce i tempi, abbassa il costo iniziale, rende concreta un’idea quasi subito e cambia profondamente il modo in cui si passa dall’intuizione a qualcosa di tangibile. Per chi lavora su prodotto, innovazione, venture building o validazione, non è un miglioramento incrementale ma uno spostamento reale delle dinamiche iniziali. Cambiano le logiche con cui si esplora, si testa, si racconta un’idea, e allo stesso tempo si aprono opportunità che fino a poco tempo fa erano molto più costose, lente o semplicemente non accessibili.
Il punto, però, non è stabilire se questa accelerazione esista, perché è evidente che esista. Il punto è capire dove stia realmente avvenendo e, soprattutto, dove invece crediamo che stia avvenendo senza che sia così. In altre parole, la domanda non è “quanto siamo diventati veloci”, ma “che cosa abbiamo davvero reso più veloce”.
Il glitch più interessante, infatti, non è tecnico. È nel modo in cui il mercato interpreta quello che vede. Sempre più spesso una demo interattiva, ben costruita e coerente, viene letta come prodotto, oppure un prototipo credibile viene promosso a MVP senza aver attraversato quel passaggio che trasforma qualcosa di funzionante in qualcosa di utilizzabile, affidabile e sostenibile nel tempo. Non si tratta di un errore ingenuo, ma di una distorsione percettiva: la qualità della rappresentazione è talmente alta da anticipare la percezione di maturità.
Da qui iniziano a generarsi effetti concreti. Si costruiscono aspettative su basi non ancora solide, si prendono decisioni operative partendo da un livello di maturità che è solo apparente, si impostano conversazioni con investitori, clienti e team come se alcune fasi fossero già state superate. In realtà, molto spesso, devono ancora iniziare.
Se torniamo al significato originario di MVP nel contesto Lean, la distanza diventa evidente. MVP non è mai stato “il minimo software funzionante”, né la prima versione che riesce a girare. È il minimo investimento necessario per verificare un’ipotesi rilevante con utenti reali, producendo apprendimento reale. Il focus non è sulla costruzione, ma sulla validazione. Non sull’impressionare, ma sul capire.
È qui che oggi si crea una frattura. La presenza di un’interfaccia funzionante, spesso molto convincente, tende a essere letta come evidenza di validazione, quando in realtà è soltanto evidenza di fattibilità. Ma fattibilità e validazione sono due piani completamente diversi. Un MVP può anche non essere software: può essere una landing page, un concierge test, un prototipo assistito, un processo manuale. Ciò che lo definisce non è la quantità di codice deployato, ma la qualità dell’apprendimento che genera.
Il fatto che oggi si riesca a costruire rapidamente qualcosa che “sembra un prodotto” non significa che si sia più vicini al mercato, ma che si è diventati molto più efficienti nel rappresentarlo. E questa distinzione è tutt’altro che semantica, perché ha impatti diretti su come si leggono i progressi, si allocano risorse e si prendono decisioni.
Una demo, in questo senso, è una promessa interattiva. Può essere estremamente utile per chiarire un’idea, per allineare persone, per esplorare possibilità. Personalmente ne faccio molte, proprio perché consentono di accelerare il confronto e rendere visibile qualcosa che altrimenti resterebbe astratto. In alcuni casi possono anche essere strumenti validi per testare specifiche ipotesi. Ma nella maggior parte delle situazioni restano rappresentazioni, non ancora sistemi pronti per essere esposti a un uso reale e continuativo.
Quello che si osserva spesso è che si rimane nella zona dell’Idea MVP, a volte si entra in quella dell’esperimento, ma solo raramente si arriva a un vero Product MVP. E la differenza non è una questione di etichette, ma di implicazioni operative. Trattare un’idea resa visibile come se fosse già un prodotto porta inevitabilmente a una lettura distorta del lavoro che resta da fare, con una tendenza sistematica a sottostimarlo.
Detto questo, liquidare tutto come hype sarebbe una semplificazione sbagliata. La componente positiva è concreta e rilevante. L’AI ha ridotto drasticamente il costo della prototipazione, ha accelerato la possibilità di esplorare alternative, ha reso più rapido il passaggio da intuizione a primo riscontro. Questo incide direttamente sul modo in cui si lavora: si possono fare più tentativi, iterare più velocemente, eliminare prima le ipotesi deboli e concentrare energie su quelle che mostrano segnali migliori.
Anche il processo di validazione può beneficiarne, non perché venga automatizzato, ma perché diventa più efficiente. Il giudizio resta umano, ma il percorso che porta a esercitarlo è meno costoso e più rapido. Inoltre, si abbassa la barriera di accesso: più persone riescono a dare forma a un’idea e a portarla a un livello minimo di tangibilità.
Il problema emerge quando questa accelerazione viene interpretata come se riguardasse l’intero ciclo di vita del prodotto. In realtà riguarda soprattutto la fase iniziale, quella in cui qualcosa diventa visibile, comprensibile, dimostrabile. È la fase in cui si costruisce una rappresentazione credibile, non quella in cui si costruisce un sistema robusto.
Ed è proprio qui che si crea la distorsione più rilevante: la qualità della rappresentazione anticipa la percezione di completezza. Si ha l’impressione di essere molto più avanti di quanto si sia realmente, perché ciò che si vede è già molto vicino alla forma finale. Ma ciò che non si vede, e che determina la reale capacità di stare sul mercato, non è stato ancora affrontato.
Basta spostarsi su un caso concreto per rendersene conto. Una chat che funziona in demo non ha ancora incontrato gran parte delle condizioni reali in cui dovrà operare: gestione dei ruoli, permessi incoerenti, utenti duplicati, allegati pesanti, notifiche errate, carichi concorrenti, gestione degli errori, audit log, retention dei dati, backup, moderazione, abuso, dispositivi non performanti, connessioni instabili, recupero degli account. E questo ancora prima di entrare in temi come privacy, compliance, accessibilità, localizzazione o sostenibilità dei costi infrastrutturali.
Non si tratta di “il dopo”. È parte integrante del prodotto.
È in questo passaggio che qualcosa smette di essere credibile e inizia a essere affidabile, e il salto tra le due condizioni è esattamente quello che oggi rischia di essere sottovalutato. Il lavoro più impegnativo non è stato eliminato, ma semplicemente spostato fuori dal primo campo visivo, quello che oggi viene compresso e accelerato.
Nella pratica, è questo il punto che vedo più spesso frainteso. La prodottizzazione non coincide con la costruzione di feature, ma con la capacità di farle vivere in un contesto reale, nel tempo, senza frizioni sistemiche e senza richiedere interventi continui. Quando questo passaggio viene sottovalutato, nelle startup si generano errori di pianificazione e di aspettativa, mentre nelle aziende più strutturate si rischia di abbassare la soglia di qualità e controllo, perché la rappresentazione iniziale è già sufficientemente convincente da sembrare “abbastanza”.
Questa dinamica non è nuova. Si è già vista in altre fasi del digitale, anche se con velocità diverse. Quando i CMS hanno reso semplice pubblicare contenuti, per un periodo si è confuso il fatto di avere un sito con l’avere una strategia digitale. Quando il cloud ha reso accessibile l’infrastruttura, l’accesso è stato scambiato per capacità di gestione. Quando i social hanno abbassato la barriera di pubblicazione, la produzione di contenuti è stata confusa con la comunicazione. In tutti questi casi è cambiato il livello di astrazione, ma non la natura del lavoro sottostante.
La differenza oggi è la rapidità con cui questa compressione avviene. E quando le fasi iniziali si comprimono così tanto, il mercato tende a riscrivere il significato delle parole. Prototipo diventa prodotto, esperimento diventa MVP, una prima forma convincente viene interpretata come maturità. In realtà, spesso, si tratta di una rappresentazione molto più efficace di quanto fosse possibile in passato, non di una reale evoluzione dello stato del sistema.
Questo non è un motivo per prendere le distanze dall’AI, anzi. Sarebbe una lettura miope. È uno strumento estremamente potente e destinato a incidere profondamente sul modo in cui costruiamo. Ma proprio per questo va compreso con lucidità. Non è una scorciatoia universale, è un acceleratore selettivo. Aumenta la produttività in alcune fasi, ma non elimina la complessità complessiva, che tende piuttosto a redistribuirsi.
Siamo in una fase fisiologica, in cui stiamo imparando a usare qualcosa mentre ne stiamo ancora esplorando i confini. Il potenziale è evidente, i limiti molto meno. È una dinamica ricorrente: quando il livello di astrazione cambia rapidamente, l’entusiasmo anticipa il metodo e la disciplina arriva solo in un secondo momento.
Col tempo, il mercato torna a distinguere. Tra ciò che è dimostrabile e ciò che è sostenibile, tra ciò che appare funzionante e ciò che regge nel tempo, tra ciò che convince in una demo e ciò che può essere davvero utilizzato su scala.
L’AI ha reso molto più veloce l’inizio. Non ha reso automaticamente più semplice tutto ciò che viene dopo. Un’idea può diventare visibile in poche ore; trasformarla in qualcosa di utile, affidabile e difendibile resta un percorso che richiede ancora metodo, competenze e capacità di lettura molto più profonde.