La seconda versione
10 marzo 2026
L'ultima riga del mio articolo precedente su come rilasciare era: "La seconda versione sarà migliore comunque."
L'ho scritto come consolazione — un modo per rendere più digeribile l'imperfezione di un primo lancio. Ma più ci penso, più mi sembra che sottovaluti quello che succede davvero dopo aver spedito.
La seconda versione non è solo migliore. È un tipo di lavoro diverso.
Cosa è davvero la prima versione
La prima versione di qualsiasi cosa è un'ipotesi. Hai preso una serie di decisioni — cosa costruire, cosa includere, come dovrebbe funzionare — basandoti sulla tua migliore intuizione su cosa serve agli utenti. Alcune di quelle intuizioni sono giuste. La maggior parte sono parzialmente sbagliate. Alcune sono completamente sbagliate in modi che non avresti potuto anticipare.
Non sai quali siano quali finché delle persone reali non lo usano.
Non è un fallimento della pianificazione. È la natura di costruire software per altri esseri umani. Nessuna quantità di ricerca, interviste agli utenti o lavoro di design sostituisce pienamente il guardare qualcuno usare davvero quello che hai costruito. La mappa non è mai il territorio.
Il compito della prima versione è fare contatto con la realtà. Tutto qui. Tutto il resto — l'architettura, la rifinitura, le funzionalità su cui hai agonizzato — è solo il biglietto d'ingresso.
Il segnale che torna indietro
Quando Barba Studio è stato lanciato, mi aspettavo lamentele sull'interfaccia del calendario. L'avevo fatto in fretta e sapevo che non era ottimale. Quello che ho ottenuto: nessuno ha menzionato il calendario. Quello che hanno menzionato erano i promemoria degli appuntamenti — nello specifico, che volevano personalizzare il testo del messaggio.
Avevo costruito un sistema di promemoria. Funzionava. Ma avevo reso il messaggio un template fisso perché la personalizzazione sembrava scope creep all'epoca. Per ogni utente, quel template fisso era la prima cosa che volevano cambiare.
Questo è il tipo di segnale che ottieni solo rilasciando. Non è che non avrei potuto pensare alla personalizzazione dei messaggi in anticipo — probabilmente avrei potuto. Ma l'avrei classificata più in basso di dieci altre cose, e avrei avuto torto. L'utente mi ha detto esattamente cosa costruire dopo.
La seconda versione non è un'ipotesi. È una risposta.
Costruire con il segnale vs. costruire al buio
La maggior parte del lavoro prima di un primo lancio è costruire al buio. Stai prendendo decisioni senza feedback, senza dati d'uso, senza sapere quali parti di quello che hai costruito contino davvero per qualcuno. È necessario — devi cominciare da qualche parte — ma è anche costoso. Ogni ora che spendi sulla funzionalità sbagliata è un'ora che non puoi recuperare.
Dopo il lancio, questo cambia. Hai dati. Sai cosa viene usato e cosa no. Sai dove le persone abbandonano. Sai cosa chiedono. Le decisioni che prendi nella seconda versione sono radicate in qualcosa di reale.
Per questo ho cominciato a pensare che la prima versione di un prodotto non sia davvero l'inizio della sua costruzione. È la fine della fase di ricerca. La costruzione inizia sul serio con la seconda versione.
Quando iniziare
Non subito.
C'è una finestra dopo il lancio in cui sei inondato di reazioni iniziali — alcune utili, alcune rumore, alcune contraddittorie. Lanciarsi subito nella seconda versione basandosi su quella prima ondata è un errore. Stai reagendo a dati incompleti prima che abbiano avuto il tempo di depositarsi.
Quello che faccio: lascio girare il prodotto per qualche settimana. Raccolgo tutto — messaggi di supporto, conversazioni, pattern d'uso se ho strumentazione. Poi ci mi siedo sopra e cerco pattern. Non richieste individuali — pattern. Le funzionalità che persone diverse chiedono in modi diversi. I punti di attrito che emergono più e più volte. Le cose che nessuno menziona che mi aspettavo fossero importanti.
Quel riconoscimento di pattern è da dove viene lo scope della seconda versione.
Cosa cambia, cosa no
La seconda versione è di solito più focalizzata della prima, non più grande. La prima versione è spesso troppo ampia — hai costruito per utenti ipotetici, quindi hai coperto molto terreno in modo difensivo. La seconda può essere più stretta perché sai quale terreno conta davvero.
Cosa cambia: le cose che gli utenti ti hanno detto. Cosa non cambia: le cose che gli utenti non hanno menzionato. Se nessuno si è lamentato del flusso di onboarding, il flusso di onboarding probabilmente va bene. Rilascialo di nuovo.
Sembra ovvio, ma la tentazione è di usare la seconda versione come occasione per aggiustare tutto quello che non ti piaceva della prima. È così che le seconde versioni diventano la loro trappola della perfezione. La disciplina è la stessa di prima: lascia che il segnale guidi lo scope, non il tuo gusto personale.
Quando non c'è una seconda versione
A volte un prodotto non genera abbastanza segnale per costruirci sopra una seconda versione. Le persone lo usano una volta, non tornano, non dicono perché. Anche questo è un dato — forse il più importante che puoi ottenere.
La mancanza di engagement non è una ragione per iterare. Potrebbe essere una ragione per ripensare, o per fermarsi, o per fare domande più difficili su se quello che hai costruito risolve un problema reale per persone reali. Nessuna seconda versione è meglio di una seconda versione che raddoppia su una prima versione che nessuno voleva.
La seconda versione non è automaticamente migliore. È condizionata al fatto che la prima versione ti abbia insegnato qualcosa. Se non l'ha fatto, il lavoro non è iterazione — è qualcos'altro.
Rilascia la prima versione per imparare. Costruisci la seconda da quello che hai imparato. Questo è l'intero ciclo.