Che differenza c'è tra PoC, prototipo e MVP?

PoC, prototipo e MVP sono tre artefatti che rispondono a tre domande diverse, e confonderli è il modo più comune di spendere un budget senza ottenere la risposta che serviva. Una proof of concept risponde a "si può fare?": verifica un'assunzione tecnica isolata, vive in un ambiente controllato e può essere buttata via il giorno dopo. Un prototipo risponde a "si capisce?": mostra il flusso e l'interfaccia a persone vere, di solito senza un vero sistema dietro. Un MVP risponde a "serve davvero?": è un prodotto ridotto all'osso ma completo, in produzione, usato da utenti reali per il lavoro vero. Le tre domande seguono una sequenza logica, ma non è obbligatorio percorrerle tutte, e sceglierne una significa dichiarare quale incertezza fa più paura in questo momento. È una dichiarazione che conviene mettere per iscritto prima di firmare, perché orienta il budget e il criterio con cui si giudicherà il risultato.

La domanda giusta è quale rischio vuoi togliere per primo

Il criterio di scelta non è la maturità dell'idea, è la natura dell'incertezza dominante. Se il dubbio è tecnologico (questo modello regge sui nostri dati? questo sistema legacy espone davvero quell'interfaccia?), la proof of concept costa poco e chiude la questione. Se il dubbio è di adozione (le persone useranno un flusso diverso da quello che fanno da dieci anni?), una proof of concept non dice nulla e serve un prototipo davanti a chi dovrà usarlo. Se il dubbio è di valore (questo ci fa guadagnare o risparmiare abbastanza da giustificare la manutenzione?), solo un MVP in produzione risponde, perché è l'unico dei tre che vive nelle condizioni reali. L'errore tipico è costruire l'artefatto più costoso per rispondere alla domanda più facile.

Un esempio enterprise

Un'azienda vuole automatizzare la lettura delle fatture fornitore. Una proof of concept prende trecento documenti storici e misura l'accuratezza dell'estrazione: costa qualche giorno e dice se la strada esiste. Un prototipo mostra all'ufficio contabilità come apparirebbero le eccezioni da validare a mano, e scopre che il flusso proposto raddoppia i clic rispetto a oggi. Un MVP mette in produzione un solo fornitore e un solo tipo di documento, con la validazione umana attiva, e misura per due mesi quanto tempo si risparmia davvero. Sono tre spese diverse e tre risposte diverse: chi le confonde presenta di solito la proof of concept come se fosse un MVP, e scopre la parte difficile mesi dopo.

Perché conta per chi decide

Per chi decide questa distinzione è soprattutto uno strumento contrattuale, perché stabilisce in anticipo cosa si compra e come si giudica il risultato. Ogni artefatto va commissionato insieme alla domanda a cui deve rispondere e al criterio che chiude la questione, entrambi messi per iscritto prima di cominciare: senza quel criterio nessuno dei tre finisce mai, e la proof of concept diventa un progetto perenne che nessuno osa dichiarare concluso, che è il modo in cui nasce la trappola del costo affondato. Vale anche il contrario: una proof of concept riuscita non è una promessa di produzione, e il divario tra le due è la ragione per cui tanti progetti AI restano bloccati alla fase dimostrativa. Sulla stima dei tempi e dei costi dell'MVP, infine, la sola difesa che funziona è guardare quanto sono costati i progetti comparabili già chiusi, cioè il reference class forecasting, perché una stima costruita sull'entusiasmo di una proof of concept appena riuscita è sistematicamente ottimista.