MVP in 2 mesi: il metodo

Il punto di partenza: una sola domanda da validare

Un MVP in 2 mesi parte da una sola domanda chiara da validare, non da una lista di feature. Prima di scrivere codice, va definito cosa deve dimostrare la prima versione: non "funziona tutto", ma "questa cosa specifica risolve un problema reale per queste persone". Con BRUM la domanda era se un'app potesse rendere la preparazione all'esame della patente più efficace di un libro o di un corso tradizionale. Tutto il resto, il design, le feature secondarie, le integrazioni, è venuto dopo, una volta che la domanda principale aveva una risposta.

Tagliare, non aggiungere

Il lavoro più difficile nelle prime settimane non è decidere cosa costruire, è decidere cosa non costruire. Ogni feature "sarebbe carina da avere" che entra nello scope del primo rilascio è tempo tolto a validare la domanda principale. La regola pratica è semplice: se una feature non serve a dimostrare che l'idea funziona, aspetta la versione due. Questo vale anche per richieste che sembrano ragionevoli in astratto: la domanda giusta non è "è utile?", ma "è utile per rispondere alla domanda che stiamo validando ora?".

Stack e architettura pensati per il primo giorno, non per il decimo anno

Un errore comune nelle fasi iniziali è progettare un'architettura per una scala che il prodotto non ha ancora. In 2 mesi serve uno stack che permetta di muoversi velocemente, con scelte reversibili dove possibile: meglio un'architettura semplice che si può rifattorizzare dopo, che una complessa pensata per un carico di utenti che potrebbe non arrivare mai. Le decisioni davvero difficili da cambiare in seguito, quelle sì, vanno prese con cura fin dall'inizio; il resto può restare volutamente semplice.

Iterazione settimanale, non un unico grande rilascio

Due mesi non bastano per un piano rigido definito il primo giorno e seguito alla lettera. Servono cicli brevi, settimanali, con priorità che si aggiustano man mano che emergono vincoli tecnici o feedback anche informale. L'obiettivo delle prime settimane è avere qualcosa di funzionante il prima possibile, anche scarno, per iniziare a imparare dal contatto con utenti reali. Ogni settimana che passa senza qualcosa di testabile in mano è una settimana in cui si continua a costruire sulla base di ipotesi, non di dati.

Store readiness: l'ultimo miglio che spesso si sottovaluta

Pubblicare in store, Apple App Store e Google Play, non è un dettaglio dell'ultimo minuto, è parte del piano fin dall'inizio: linee guida di review, requisiti tecnici, privacy policy, asset grafici. Sottovalutare questo passaggio nelle ultime settimane è uno degli errori più comuni che allunga i tempi inutilmente. Va pianificato dal primo giorno, non aggiunto all'ultimo momento: capire in anticipo quali requisiti si applicano al proprio caso evita sorprese proprio quando mancano pochi giorni al lancio previsto.

Cosa succede dopo il primo rilascio: il caso BRUM

L'MVP in store non è il traguardo, è il punto di partenza per imparare. Con BRUM, dopo il primo rilascio in 2 mesi, il lavoro è continuato ascoltando gli utenti reali e iterando in continuo: oggi la piattaforma conta 150.000 download, un rating di 4,5★ e 50.000 utenti attivi al mese. Nessuno di quei numeri esisteva al lancio: sono il risultato di iterazioni successive costruite sopra un primo rilascio onesto, non perfetto, e di un ascolto costante di cosa funzionava e cosa no per chi usava davvero il prodotto.

Cosa serve davvero per riuscirci in 2 mesi

Non serve un team enorme: serve un mandato chiaro e la capacità di decidere velocemente senza passare da troppi livelli di approvazione. In pratica serve qualcuno con esperienza tecnica che possa prendere quelle decisioni, stack, scope, priorità, senza bisogno di convalidarle ogni volta con l'intera azienda: è uno dei motivi per cui, nelle fasi early-stage, questo ruolo viene spesso coperto da un fractional CTO piuttosto che da un team allargato. La velocità nasce più dalla chiarezza del mandato che dalla dimensione del team.

Domande frequenti