Che cosa decidere prima di costruire un MVP

Un MVP non è una versione ridotta di ogni idea della tua roadmap. È il prodotto utile più piccolo che consente a un gruppo definito di persone di completare un flusso di lavoro importante e dà al team prove per la decisione successiva.

Su quella parola, prove, vale la pena fermarsi.

L’analisi di CB Insights sul perché falliscono le startup (si apre in una nuova scheda), pubblicata nel marzo 2026, ha esaminato 431 aziende finanziate da venture capital chiuse pubblicamente dal 2023. Ha rilevato l’esaurimento del capitale nel 70 % dei casi e uno scarso adattamento prodotto-mercato nel 43 %.

La sua osservazione più utile riguarda quando avvengono i fallimenti di adattamento: «due terzi dei fallimenti di adattamento prodotto-mercato erano aziende in fase iniziale che non hanno mai trovato un mercato».

Il denaro è il modo in cui finisce. Non imparare abbastanza in fretta è spesso il perché. Lo stesso principio vale per uno strumento aziendale interno: la sua prima release deve dimostrare che un flusso di lavoro importante funziona meglio.

Quindi la prima release non è una dimostrazione della tua ambizione. È uno strumento per scoprire qualcosa. Le decisioni che seguono determinano se può farlo.

Che cosa non è un MVP

Tre fraintendimenti causano quasi tutti i danni, e conviene nominarli prima che inizi la pianificazione:

• Una versione più economica del prodotto completo. Abbassare la qualità ovunque ti lascia qualcosa che nessuno può giudicare. Taglia invece lo scopo, e costruisci bene ciò che resta.
• Un prototipo. Un prototipo risponde a una domanda di progettazione e poi si butta. Un MVP è software vero con utenti veri, e deve essere manutenibile.
• Un’architettura definitiva. La prima release deve poter cambiare. Le decisioni costose da annullare meritano più riflessione di quelle che non lo sono.

La domanda utile non è «qual è il minimo che possiamo costruire?». È «qual è il minimo che possiamo costruire che ci insegnerebbe comunque qualcosa su cui agiremmo?».

Ti serve davvero un software su misura?

Prima di definire lo scopo di una realizzazione su misura, vale la pena chiedersi se ti serva già.

Il software su misura è la risposta giusta quando il tuo flusso di lavoro è davvero specifico, quando devi essere proprietario del risultato o quando gli strumenti pronti non riescono a collegarsi al modo in cui lavora la tua azienda.

È spesso la prima risposta sbagliata quando uno strumento no-code, un foglio di calcolo o un prodotto esistente ti permetterebbero di verificare la stessa ipotesi questa settimana.

Una sequenza utile è validare la domanda con la cosa più economica che funziona, poi costruire su misura una volta che sai quali parti ne hanno davvero bisogno.

Molti prodotti di successo nascono come processo manuale o come insieme di strumenti assemblati. Diventano software su misura solo dove quell’assemblaggio inizia a fare male.

Costruire su misura troppo presto spende il tuo budget per dimostrare qualcosa che una prova molto più economica avrebbe potuto dirti. Farlo troppo tardi ti lascia a combattere con strumenti che non vanno più bene.

Rispondi con onestà prima di iniziare a definire lo scopo, non dopo.

Parti dal flusso di lavoro dell’utente

Prima di parlare di tecnologia, descrivi chi userà il prodotto, in quale situazione si trova e quale compito deve portare a termine. Se resta vago, il vago ti segue in ogni schermata e in ogni funzione.

Scrivi il flusso principale come una breve sequenza. Per esempio: un cliente invia una richiesta, un membro del team la esamina, il sistema registra la decisione ed entrambe le parti vedono il passo successivo.

Il Government Digital Service britannico la formalizza come fase di discovery. Il suo manuale dei servizi (si apre in una nuova scheda) è netto sull’ordine: «prima di impegnarti a costruire un servizio, devi capire il problema da risolvere».

Indica da quattro a otto settimane come durata tipica di quella discovery, che si chiude con una decisione esplicita sull’esistenza stessa di un servizio sostenibile.

Un’indagine breve e delimitata con un vero go/no-go costa meno di una realizzazione che scopre la stessa cosa al quinto mese.

Definisci che cosa rientra nello scopo

Poi separa il lavoro indispensabile da quello utile più avanti. Accesso, permessi, pagamenti, notifiche, report, integrazioni e strumenti di amministrazione possono contare tutti, ma la prima release non li richiede tutti allo stesso livello di dettaglio.

Un buono scopo ha una ragione per ogni funzionalità. Tieni una funzionalità nella prima release quando supera almeno una di queste prove:

1. il primo utente non può completare il flusso principale senza di essa
2. riduce un rischio di consegna che hai già individuato
3. dà al team il controllo di cui ha bisogno dal primo giorno
4. lasciarla fuori imporrebbe una riscrittura anziché un’aggiunta

Se una funzionalità non ne supera nessuna, è una decisione successiva e non un taglio. Registrarla così di solito disinnesca la discussione sul rimuoverla.

Decidi come saprai che ha funzionato

Prima che inizi la costruzione, concordate quale risultato giustificherebbe proseguire, cambiare direzione o fermarsi. Senza quello, ogni esito sembra incoraggiante.

Scegli segnali osservabili nelle prime settimane di uso reale, non quelli che richiedono un anno di dati:

• le persone completano il flusso principale senza essere accompagnate
• tornano senza essere sollecitate
• il lavoro manuale sostituito dal prodotto cala in modo evidente
• qualcuno chiede la funzionalità successiva anziché una correzione di base

Scrivi che cosa ti aspetti di vedere ed entro quando. Confrontarlo con ciò che accade è tutto il senso di rilasciare presto.

Metti per iscritto che cosa significa «fatto»

Definisci che cosa significa «funziona» prima che inizi lo sviluppo. Usa criteri di accettazione osservabili: l’utente può inviare una richiesta, la persona giusta può esaminarla e il sistema registra correttamente il risultato.

Gli orientamenti del GDS sulla scrittura delle user story (si apre in una nuova scheda) descrivono i criteri di accettazione come «un elenco di esiti che usi come lista di controllo per confermare che il tuo servizio ha fatto il suo lavoro», ciascuno formulato nella forma è fatto quando… — un enunciato.

Il valore sta nel fatto che può verificarli qualcuno che non li ha costruiti.

A livello di release, The Scrum Guide (si apre in una nuova scheda) definisce la Definition of Done come «una descrizione formale dello stato dell’incremento quando soddisfa le misure di qualità richieste per il prodotto».

Che tu usi Scrum o no, l’idea viaggia. Un livello di qualità concordato e scritto impedisce che «finito» significhi qualcosa di diverso per ciascuna persona nella conversazione.

Fissa le regole sui dati prima dello schema

Decidi quali informazioni il prodotto deve conservare e chi può accedervi. Privacy, permessi, conservazione, backup e necessità di audit sono più facili da pianificare prima delle prime tabelle di database e integrazioni.

Per i prodotti che trattano dati personali di persone nell’UE, seguire quest’ordine è la legge, non una preferenza.

Gli orientamenti della Commissione europea sulla protezione dei dati fin dalla progettazione e per impostazione predefinita (si apre in una nuova scheda) descrivono misure che si applicano fin dalle primissime fasi della progettazione del trattamento, con impostazioni predefinite tali che «i dati personali siano trattati con il massimo livello di protezione della vita privata».

Il Comitato europeo per la protezione dei dati ha adottato apposite linee guida sull’articolo 25 (si apre in una nuova scheda) in forma definitiva nell’ottobre 2020, se ti serve la posizione dettagliata del regolatore.

In pratica è un breve elenco da mettere per iscritto: che cosa raccogli, perché, chi può vederlo, per quanto lo conservi e come si ottiene la cancellazione.

Rispondere a queste domande prima di progettare il database costa molto meno che aggiungerle dopo.

Scegli tecnologia e IA con cura

Scegli la tecnologia attorno al prodotto e ai suoi vincoli. Un framework moderno può andare bene, ma la scelta migliore dipende da utenti, dati, integrazioni, esigenze di consegna e persone che manterranno il software.

L’IA merita la stessa disciplina. Decidi se sostiene il flusso principale, che cosa succede quando il suo output è sbagliato e come una persona possa rivederlo o correggerlo prima di trattarla come un requisito di prodotto.

Ora ci sono ragioni misurate per la prudenza. Il 2025 DORA report (si apre in una nuova scheda), basato sulle risposte di quasi 5.000 professionisti della tecnologia, riporta che «l’adozione dell’IA continua ad avere una relazione negativa con la stabilità della consegna del software».

Produrre più in fretta senza test e revisione solidi non si somma in consegne più rapide. Si somma in rilavorazione.

Pianifica revisioni, accessi, passaggio di consegne

Pianifica i punti di revisione prima della prima riga di codice. Demo brevi, una lista di attività condivisa e decisioni scritte dove tutti le vedono permettono di cambiare rotta finché cambiare rotta costa ancora poco.

Lo US Government Accountability Office espone l’argomento del rischio nella sua Agile Assessment Guide (si apre in una nuova scheda): la consegna incrementale con valutazione continua «può ridurre i rischi di finanziare un programma che fallisce o produce tecnologia obsoleta».

Concordate proprietà e accessi fin dall’inizio. Il progetto deve avere un repository di codice chiaro, ambienti documentati, un percorso di distribuzione concordato e un piano di passaggio di consegne che non dipenda dall’account privato di una sola persona.

La capacità DORA di controllo di versione (si apre in una nuova scheda) è precisa su che cosa vi appartiene: codice applicativo e dipendenze, strumenti di creazione degli ambienti, file di composizione dei container, configurazione cloud e artefatti di IA come i prompt.

La sua base dichiarata è che «la ricerca mostra costantemente che l’uso completo del controllo di versione predice la consegna continua».

Gli orientamenti del GDS sul controllo di versione (si apre in una nuova scheda) aggiungono l’altra metà della regola, la revisione: «ogni modifica al codice è rivista da qualcuno che non l’ha scritta».

Insieme, quelle abitudini rendono possibile un passaggio di consegne. Se ricreare il sistema dipende dal portatile di qualcuno, non hai un prodotto consegnabile: hai una dipendenza.

Pianifica tempi e budget

Un MVP focalizzato si può spesso pianificare attorno a una finestra di consegna di 6–8 settimane quando lo scopo ha quella forma. È un riferimento di pianificazione, non una promessa universale; integrazioni, approvazioni e sistemi legacy sconosciuti possono cambiare i tempi.

Aiuta sapere come falliscono i tempi del software, perché non falliscono allo stesso modo nelle due direzioni.

Uno studio su 5.392 progetti IT pubblicato sul Journal of Management Information Systems (si apre in una nuova scheda) ha rilevato che gli sforamenti di costo seguono una legge di potenza anziché una distribuzione normale.

La maggior parte degli sforamenti è modesta, ma esiste «una coda spessa che comprende un numero minore di progetti con sforamenti estremi». Pianificare sulla media sottostima il rischio che conta.

Non è solo un problema delle startup. La valutazione ad alto rischio dell’IT federale del GAO (si apre in una nuova scheda), pubblicata nel gennaio 2025, registra che gli investimenti IT federali «falliscono o incorrono in sforamenti di costo e slittamenti di calendario troppo di frequente, contribuendo poco agli esiti legati alla missione».

E questo a fronte di una spesa annua superiore a 100 miliardi di dollari. Dimensione e budget non risolvono la cosa; disciplina di scopo e cicli di feedback brevi sì.

Metti a budget le decisioni, non solo le ore di codice. Analisi, progettazione, costruzione, test, rilascio, contenuti, servizi di terzi e le correzioni dopo il lancio si sommano tutti a ciò che serve per rendere utile la prima release.

Un esempio concreto

Pensa a un fondatore che vuole una piattaforma di prenotazioni: i clienti prenotano appuntamenti, i fornitori gestiscono calendari, entrambe le parti pagano e ricevono promemoria e un amministratore sorveglia tutto. È un prodotto vero con un lungo elenco di funzionalità.

Il flusso principale, però, è stretto: un cliente trova uno slot libero e lo prenota, e il fornitore vede la prenotazione. Tutto il resto lo sostiene o può aspettare.

Una prima release disciplinata potrebbe essere così:

• Nello scopo: disponibilità del fornitore, prenotazione del cliente, una conferma e una vista semplice delle prossime prenotazioni per il fornitore.
• Rinviato: pagamenti in app (all’inizio, incasso manuale di un acconto), promemoria automatici, recensioni, ricerca tra più fornitori e la dashboard di amministrazione.
• Deciso in anticipo: quali dati dei clienti sono conservati e per quanto, di chi è il repository e che cosa significa «una prenotazione ha funzionato» come criterio di accettazione.

L’elenco rinviato non è abbandonato: è la roadmap. Ma rilasciare prima il nucleo risponde all’unica domanda che conta presto: i fornitori terranno aggiornati i calendari, e i clienti prenoteranno?

Se lo faranno, il resto vale la pena costruirlo. Se non lo faranno, nessuna integrazione di pagamento lo avrebbe salvato.

Per iniziare

L’obiettivo non è prevedere tutto. L’obiettivo è rendere visibili le ipotesi importanti, mettere alla prova il flusso principale e creare una base di prodotto migliorabile senza buttare via il lavoro.

Se hai un’idea ma non una specifica completa, parti dall’utente, dal flusso di lavoro e dalla decisione che ti serve sia sostenuta dalla prima release. Quei tre punti bastano per avviare una conversazione di pianificazione utile.