Come costruire un MVP nel modo giusto: Twitter e Uber

ForrestKnight apre il video con una premessa che ogni founder dovrebbe interiorizzare: l'MVP è uno strumento di validazione, non una scusa per spedire qualcosa di mediocre. Negli anni Duemila il concetto è stato abbracciato da product manager e developer per i motivi giusti, poi è degenerato in un alibi: "tagliamo tutto, tanto è solo l'MVP". Il risultato è una raccolta di prodotti che falliscono perché confondono scope ridotto con qualità ridotta.

La distinzione che cambia tutto

La tesi del video è netta: lo scope si limita, la qualità no. Un MVP fatto bene mantiene codice pulito, design coerente, UX usabile e contenuti curati. Quello che cambia è il numero di problemi che risolvi e il numero di audience che servi. Uno e uno, all'inizio. Risolverli bene per quel singolo segmento è ciò che ti dà segnali validi quando metti il prodotto in mano agli utenti reali.

Se ti accontenti di "barely functional" perché tanto refattorizzi dopo, stai facendo due errori in uno: stai costruendo debito tecnico che ti rallenterà sul vero work, e stai contaminando i test con un'esperienza così rotta che non saprai mai se gli utenti rifiutano l'idea o l'esecuzione.

Le quattro condizioni del test

ForrestKnight elenca quattro caratteristiche che un MVP deve soddisfare per produrre dati utili. Una sola audience target ben definita. Un solo pain point centrale per quell'audience. Una UX che sia funzionale, comoda e riconoscibile. Un build veloce, da mettere in mano agli utenti in tempi brevi. Se anche una sola di queste manca, i risultati del test diventano biased: non stai più misurando se la tua ipotesi regge, stai misurando il rumore di un esperimento mal progettato.

Per scegliere cosa entra e cosa resta fuori, il framework è una sequenza di domande dal punto di vista dell'utente, non del developer. Chi è il tuo utente. Quali sono i suoi pain point. Quali tra questi hanno il rapporto sforzo-impatto migliore. Se l'utente è disposto a pagare per quella soluzione. Le risposte selezionano la feature di partenza in modo brutale ma onesto.

Cose che non scalano: feature, non bug

Un passaggio importante riguarda l'automazione. La tentazione di automatizzare tutto fin dall'inizio è forte, ma costruire automazione richiede tempo che in fase MVP non hai. ForrestKnight cita il suo esempio: invece di automatizzare l'invio quotidiano di una nuova domanda, la spediresti a mano ogni mattina. L'utente vede un servizio che funziona; tu validi l'ipotesi senza spendere due settimane su un cron job che potrebbe diventare inutile se l'idea non regge.

È la stessa logica del "do things that don't scale" di Paul Graham: simuli a mano ciò che un giorno sarà automatico, e automatizzi solo dopo aver visto che il valore esiste.

Twitter e Uber: come si parte sul serio

Gli esempi che chiudono il video sono utili da tenere a mente. Twitter è nato come progetto interno di Odeo con una sola funzione: postare status update via SMS. Niente web interface, niente timeline, niente DM. I dipendenti lo usavano così tanto che hanno deciso di estenderlo al pubblico. Uber, beta lanciata nel 2010, faceva una cosa sola: connetteva utenti a tassisti via iPhone, con pagamento in-app e una UI minimale. Tutto il resto, Uber Eats compreso, è arrivato dopo che il primo loop aveva traction.

La lezione per un builder italiano è semplice da enunciare e brutale da applicare: smetti di immaginare il prodotto finito, isola la singola feature che da sola risolve il problema centrale, e accetta che tutto il resto sia scope creep travestito da ambizione. Quella feature isolata è l'MVP. Il resto è una lista d'attesa che si sblocca solo se i numeri ti dicono che hai imboccato la strada giusta.