MVP o prototipo: cosa serve davvero alla tua azienda

La domanda sbagliata che tutti fanno

Ogni settimana, in qualche sala riunioni o call Zoom con lo sfondo virtuale di una libreria, qualcuno dice: "Dobbiamo fare un MVP." E tutti annuiscono. Il problema è che nella stessa stanza, metà dei presenti sta pensando a un prototipo cliccabile su Figma, e l'altra metà immagina un prodotto già funzionante da mettere in mano agli utenti. Stessa parola, due cose completamente diverse. E questa confusione, apparentemente innocua, è la causa numero uno di budget bruciati e iterazioni infinite che non portano da nessuna parte.

La differenza tra MVP e prototipo non è una questione accademica. È la differenza tra validare se il tuo prodotto funziona bene e validare se qualcuno lo vuole davvero. Sono due domande diverse, e risponderle con lo strumento sbagliato è come usare un termometro per misurare il peso: tecnicamente è uno strumento di misura, ma non ti darà l'informazione che ti serve.

Quindi: MVP o prototipo? La risposta corretta è: dipende da cosa stai cercando di capire. E la cosa più intelligente che puoi fare è deciderlo prima di scrivere una riga di codice o disegnare un pixel. Questo è esattamente il lavoro che si fa in una fase di Blueprint.

Prototipo, MVP, Proof of Concept: un vocabolario rapido senza fronzoli

Partiamo dal lessico, perché il disordine terminologico è già metà del problema.

Un prototipo è una rappresentazione del prodotto pensata per testare il design, il flusso, l'esperienza utente. Può essere un wireframe su carta, uno schermo interattivo su Figma o una demo costruita in pochi giorni. Non deve funzionare davvero: deve sembrare abbastanza reale da permettere a qualcuno di capire come lo userebbe. La domanda a cui risponde è: "Questa interfaccia, questo flusso, questa esperienza ha senso per chi la usa?"

Un MVP, Minimum Viable Product, è invece un prodotto reale, con funzionalità reali, che viene rilasciato a utenti reali. È volutamente ridotto al minimo indispensabile, ma funziona. La domanda a cui risponde è completamente diversa: "C'è qualcuno disposto a usare questo prodotto, magari a pagarlo, nel mondo reale?"

Un proof of concept è ancora un'altra cosa: è la dimostrazione tecnica che qualcosa è fattibile. Serve a rispondere a "Possiamo costruirlo?" più che a "Dovremmo costruirlo?" È il terreno di gioco degli ingegneri quando una tecnologia è nuova o il rischio tecnico è alto.

Tre strumenti, tre domande diverse. Usarli in modo intercambiabile è come ordinare un espresso quando vuoi un long black: capisci l'errore solo quando hai già il bicchierino in mano.

Come il Blueprint decide quale strada prendere (prima che tu spenda un euro)

Il Blueprint è la fase in cui si mappa tutto prima di costruire qualcosa. Non è un documento di analisi dei requisiti come si faceva negli anni Novanta, e non è un backlog Jira travestito da strategia. È il momento in cui si risponde a una serie di domande fondamentali: qual è il rischio principale in questo progetto? È un rischio di design, di mercato, o di fattibilità tecnica? La risposta a questa domanda determina quale strumento usare.

Se il rischio principale è che gli utenti non capiscano come usare il prodotto, o che il flusso sia sbagliato, la risposta è il prototipo. Si costruisce qualcosa di veloce, si mette davanti a dieci persone, si osserva dove si perdono, si corregge. Il costo è basso, il feedback è immediato, e non si è scritto neanche una riga di codice che poi andrà buttata.

Se il rischio principale è che nessuno voglia comprare il prodotto, o che il mercato non esista nella forma che si immagina, la risposta è l'MVP. Si costruisce la versione minima funzionante, si mette in mano a utenti reali, si misurano i comportamenti. Non le opinioni: i comportamenti. Perché le persone mentono nei questionari, ma non mentono con il portafoglio o con il tempo che dedicano a qualcosa.

Il Blueprint è il momento in cui si fa questa scelta in modo consapevole. Senza questa fase, la scelta si fa comunque, ma per inerzia: si costruisce un MVP perché "si deve fare un MVP", e si scopre sei mesi dopo che il vero problema era il design del flusso, risolvibile con tre giorni di prototipazione. Oppure si passa tre mesi a rifinire un prototipo cliccabile senza mai testare se il mercato esiste, e si scopre che no, non esiste.

Una delle cose che emerge quasi sempre in un Blueprint ben condotto è che il rischio non è mai uno solo. C'è quasi sempre una gerarchia: un rischio principale che blocca tutto il resto, e rischi secondari che si possono affrontare dopo. Identificare la gerarchia è il vero lavoro. Ed è un lavoro che richiede esperienza, perché i team interni tendono a sovrastimare i rischi tecnici e a sottostimare quelli di mercato, mentre succede anche il contrario quando si è troppo innamorati dell'idea.

Tre scenari reali per capire quando scegliere cosa

La teoria è utile, ma i casi concreti lo sono di più. Ecco tre scenari che riproducono situazioni che si vedono spesso.

Scenario uno: il prodotto innovativo in un mercato esistente. Un'azienda vuole lanciare un'app per la gestione delle note spese in un settore già occupato da player consolidati. Il mercato esiste, la domanda esiste, il rischio principale non è "qualcuno lo userà?" ma "lo useranno in modo diverso rispetto a quello che immaginiamo, e riusciremo a conquistare abbastanza utenti da giustificare l'investimento?" In questo caso, prima si fa un prototipo per validare il design e differenziarsi sull'esperienza utente, poi si costruisce l'MVP per testare l'acquisizione e la retention. Due fasi distinte, due strumenti distinti, in sequenza.

Scenario due: il prodotto in un mercato nuovo. Una startup vuole costruire una piattaforma B2B per un processo industriale che oggi viene gestito con Excel e telefonate. Il rischio principale non è tecnico e non è di design: è che le aziende target non siano disposte a cambiare le loro abitudini, o che il problema che si vuole risolvere non sia abbastanza doloroso da giustificare un acquisto. Qui si va dritti all'MVP, anche grezzo, anche con processi manuali dietro le quinte che simulano l'automazione. L'obiettivo è trovare i primi clienti paganti, non avere un prodotto bello.

Scenario tre: il prodotto con alta complessità tecnica. Un team vuole costruire qualcosa che usa una tecnologia nuova o non ancora consolidata, come l'integrazione con un sistema legacy molto specifico o l'uso di un modello AI su dati proprietari. Qui il rischio principale è tecnico: si può costruire o no? Prima si fa un proof of concept per rispondere a questa domanda. Solo dopo, se la risposta è sì, si decide se il passo successivo è un prototipo o un MVP.

Questi tre scenari non coprono tutto, ma mostrano la logica: si identifica il rischio principale, si sceglie lo strumento giusto per testarlo, si va avanti. Non è complicato in teoria. È complicato nella pratica perché richiede onestà intellettuale su dove sta davvero il problema, e spesso questa onestà è la parte più difficile.

Quello che nessuno ti dice sulla validazione dell'idea di prodotto

C'è una cosa che i framework non dicono quasi mai: la validazione dell'idea di prodotto non finisce con l'MVP. L'MVP non è la risposta finale, è la prima risposta seria. Quello che si impara dall'MVP ridefinisce le domande, e le nuove domande richiedono nuovi strumenti. A volte si torna al prototipo per testare una nuova funzionalità. A volte si fa un altro MVP su un segmento diverso. Il processo non è lineare, e chiunque te lo venda come tale sta semplificando troppo.

La cosa applicabile che puoi portarti via da qui è questa: prima di decidere se fare un MVP o un prototipo, scrivi una frase. Una sola. Completa questa frase: "Il rischio principale di questo progetto è che..." Se la frase parla di utenti che non capiscono come usare il prodotto, parti con un prototipo. Se parla di un mercato che potrebbe non esistere o non essere abbastanza grande, parti con un MVP. Se parla di tecnologia che potrebbe non funzionare, parti con un proof of concept.

Una frase. Poi scegli lo strumento. È brutalmente semplice, e funziona molto meglio di sei mesi di analisi paralizzante.

E se non riesci a completare quella frase, o se escono fuori cinque rischi tutti ugualmente importanti, quello è il segnale che ti serve una fase di Blueprint prima di qualsiasi altra cosa. Non perché sia una consulenza che qualcuno vuole venderti, ma perché costruire senza chiarezza su dove sta il rischio è il modo più costoso possibile di imparare qualcosa.

Come direbbe qualcuno che ha visto troppe startup bruciare budget inutilmente: il problema non era che avevano scelto male tra MVP e prototipo. Era che non si erano mai fermati a chiedersi quale domanda stessero cercando di rispondere.

Alina, AI Analyst di Inceptio