Cosa entra davvero in un MVP da 6-8 settimane
Il vincolo è la parte utile
Sei-otto settimane per un MVP è il tempo in cui lavoriamo più spesso quando una startup deve arrivare in mano a utenti veri o davanti a un investitore. Non è un numero di marketing: è un vincolo, e il valore del vincolo è che costringe a decidere. Senza una data, ogni funzionalità sembra necessaria. Con una data, si scopre in fretta quali lo sono davvero.
La domanda giusta non è "quanto ci mettete". È: cosa deve essere vero alla fine di queste otto settimane perché il progetto vada avanti? Servono utenti che completano un flusso? Un numero da mostrare a un fondo? Un pilota con tre clienti paganti? Un MVP che serve a raccogliere non somiglia a uno che serve a validare un prezzo. Se questa risposta non è chiara, le settimane si consumano a costruire un po' di tutto.
Cosa ci sta dentro
In otto settimane, con una squadra piccola e un obiettivo chiaro, ci sta un prodotto che fa una cosa, dall'inizio alla fine, per davvero. Non un prototipo cliccabile: software che gira, con utenti reali, dati reali e i loro casi strani.
In concreto significa: un flusso principale completo, l'autenticazione, i dati persistenti, il pannello minimo per gestire quello che succede, e il deploy su un'infrastruttura vera con i backup attivi. Se il modello di business prevede un pagamento, ci sta anche l'incasso — è quasi sempre più veloce da integrare di quanto si tema, e senza è difficile validare qualsiasi cosa sul prezzo.
Ci stanno anche gli strumenti per capire se funziona: sapere quanti utenti arrivano a completare il flusso e dove si fermano vale, in quella fase, più di tre funzionalità aggiuntive. È un investimento di giorni, non di settimane, e cambia completamente la qualità delle decisioni successive.
Cosa non ci sta, e perché va bene così
Non ci stanno il pannello di amministrazione completo, i ruoli e permessi granulari, le integrazioni con sistemi terzi che non sono ancora richieste da nessuno, la versione mobile nativa e quella web, le notifiche su tutti i canali, l'internazionalizzazione, e il livello di rifinitura grafica che ci si aspetta da un prodotto maturo.
Vale la pena essere precisi su un punto: non ci stanno perché sono lavoro vero, non perché siano superflui in assoluto. Molti diventeranno indispensabili — dopo, quando saprai quali servono davvero. Costruirli adesso significa scommettere su ipotesi non verificate, ed è esattamente quello che l'MVP dovrebbe evitare.
Il caso più costoso è il pannello di amministrazione. È sempre più grande di quanto sembri e non è visibile all'utente. In fase iniziale, farlo funzionare manualmente — con un accesso diretto ai dati e una procedura per il team — libera settimane intere che vanno nel prodotto.
Le decisioni da prendere prima di partire
Ci sono quattro decisioni che, se restano aperte, mangiano il tempo di sviluppo dall'interno.
Chi decide. Una persona sola con l'ultima parola. Non è una questione di gerarchia, è di velocità: in un progetto di otto settimane, una scelta che resta sospesa tre giorni costa più di quanto costi la scelta sbagliata, che si corregge.
Cosa misuriamo. La metrica che dice se l'MVP ha funzionato, decisa prima. Se la si sceglie dopo aver visto i dati, si troverà sempre un numero che consola.
Chi sono i primi venti utenti. Non "il mercato": venti nomi. Se non esistono ancora, procurarseli è lavoro da fare in parallelo allo sviluppo, non dopo il lancio, altrimenti il prodotto esce e resta fermo.
Cosa succede alla settimana nove. Un MVP non è un punto di arrivo. Chi lo mantiene, chi risponde quando si rompe, con che budget si continua. Le squadre che non rispondono prima si ritrovano con un prodotto vivo e nessuno che se ne occupa.
Come sono fatte le otto settimane
Uno schema che regge nella pratica: la prima settimana si chiude la definizione — flusso principale, schermate, modello dati, decisioni di cui sopra. Dalla seconda si sviluppa a cicli brevi, con qualcosa di visibile e provabile ogni settimana. Non una demo raccontata: un link che si apre. È il modo più affidabile per scoprire un malinteso alla seconda settimana invece che alla settima.
Le ultime due settimane non sono per le funzionalità. Servono per i casi limite, i dati sporchi, gli errori che compaiono solo con utenti veri, la messa in produzione e la prova che i backup funzionino davvero. Chi le usa per aggiungere l'ultima cosa consegna un prodotto fragile proprio nel momento in cui viene guardato da più persone.
Le scorciatoie che si possono prendere e quelle che no
Un MVP è fatto di compromessi consapevoli, e conviene sapere quali sono recuperabili.
Si può rimandare quasi tutta la rifinitura, si può gestire a mano ciò che poi sarà automatico, si può supportare un solo browser o un solo tipo di dispositivo, si può rinunciare a coprire ogni caso limite. Sono scelte che costano poco da correggere dopo, perché toccano la superficie.
Non si possono invece rimandare tre cose. Il modello dei dati: cambiarlo dopo che ci sono utenti veri è il tipo di lavoro che riscrive mezzo prodotto. La sicurezza degli accessi: un errore lì non è debito tecnico, è un incidente. E i backup funzionanti, perché la perdita dei primi dati reali è anche la perdita dei primi utenti reali, che sono i più difficili da riconquistare.
La regola pratica: si può essere sbrigativi su ciò che si vede, mai su ciò che tiene.
Quando otto settimane non bastano
Onestamente: non è sempre la finestra giusta. Se il cuore del prodotto è un problema tecnico non risolto — un modello da addestrare, un dispositivo fisico da integrare, un vincolo normativo pesante come il sanitario o il finanziario — la parte incerta va isolata e affrontata prima, con un tempo suo. Comprimerla dentro l'MVP significa scoprire alla settimana sei che il pezzo su cui si regge tutto non funziona.
Vale anche il contrario: a volte otto settimane sono troppe. Se l'ipotesi da verificare è "qualcuno pagherebbe per questo", si può spesso testare con molto meno, e costruire solo dopo aver avuto una risposta.
Un MVP non è la versione piccola del prodotto finale. È lo strumento più economico per scoprire se il prodotto finale ha senso — e va progettato per quello, non per fare bella figura.
