"Se non ti senti imbarazzato dalla prima versione del tuo prodotto, hai lanciato troppo tardi." — Reid Hoffman In Splits, seguiamo questo approccio per costruire software: farlo funzionare → farlo bene → farlo veloce. L'ordine è importante. Ecco cosa abbiamo imparato spedendo ogni fase:

Fallo funzionare = prototipo funzionale. Dovrebbe essere grezzo. Dovrebbe essere traballante. Portalo rapidamente davanti agli utenti. Come definiamo l'MVP: 1) Elenca tutto ciò che pensiamo possa essere importante o rilevante per il progetto. 2) Qual è il *minimo assoluto* di questa lista che possiamo completare e avere un prototipo funzionale?

Fallo bene = ripara tutti i pezzi rotti. Entra in questa fase con segnali chiari dal mercato: feedback coerente, utilizzo crescente nonostante evidenti difetti. Ora hai guadagnato il diritto di investire più risorse.

Fallo in fretta = ottimizza le prestazioni. Onestamente, stiamo ancora imparando su questa fase. La maggior parte dei Team è attualmente in modalità "fai le cose per bene" 🤷‍♂️ Ma ecco l'ispirazione che ci guida:

Perché questo approccio funziona: La sequenza è strategia. Ciò che impari oggi plasma ciò che costruisci domani. Se salti avanti, non hai le informazioni necessarie per risolvere i problemi correttamente. L'azione produce informazioni. Ma l'azione *intenzionale* produce informazioni *più utili*.

La trappola sta cercando di sistemare le cose mentre tu stai cercando di farle funzionare. NOPE. "Datti il permesso di spedire qualcosa che sai non essere giusto." — @wminshew