Ho costruito questo prodotto completamente da solo, soprattutto la sera, nei weekend e sacrificando più giorni festivi di quanti vorrei ammettere. Per molto tempo ha continuato a sembrarmi un progetto personale che, semplicemente, era accessibile sul Web.
Attivare i pagamenti ha cambiato quella sensazione immediatamente. Il codice non è diventato all’improvviso più sofisticato, ma è cambiata la mia responsabilità verso il prodotto. Nel momento in cui qualcuno può pagare, un flusso rotto non è più soltanto un edge case da sistemare in seguito. Onboarding, moderazione, retention, fiducia e affidabilità smettono di essere problemi futuri. Diventano parte di ciò che il prodotto sta promettendo adesso.
È la lezione principale che mi sono portato via dal lancio: costruire da solo un progetto ricco di funzionalità e gestire un prodotto reale sono due lavori diversi.
Nello sviluppo in solitaria, l’attenzione è diventata il collo di bottiglia
Mentre costruivo sono quasi sparito dai social. Non era una strategia di lancio. Decisioni di prodotto, implementazione, edge case, test dei flussi e preparazione della release competevano tutti per le stesse ore limitate.
Oggi capisco molto meglio questa parte del lavoro in solitaria. Il collo di bottiglia non è sempre quanto velocemente riesco a scrivere codice. È quanta attenzione posso dedicare a un numero crescente di stati, transizioni e modalità di errore nel prodotto.
Una build riuscita non risponde a queste domande. Nemmeno un pagamento riuscito.
I pagamenti hanno cambiato il significato di un bug
Prima dei pagamenti potevo ancora considerare alcune imperfezioni come cose che avrei sistemato più avanti. Una volta attivati i pagamenti, quel modello mentale ha smesso di funzionare per me. Un prodotto a pagamento non deve essere privo di bug; non sarebbe realistico. Ma il costo di lasciare irrisolto un problema noto cambia quando un’altra persona ha già affidato denaro al prodotto.
Lo stesso vale per onboarding e moderazione. Durante lo sviluppo possono sembrare sistemi di supporto attorno alla funzionalità “vera”. In produzione fanno parte della funzionalità, perché l’utente li vive direttamente. La retention è simile: una buona prima sessione non dimostra che il prodotto dia una ragione per tornare.
I pagamenti non hanno dimostrato che fosse finito. Hanno mostrato quanto lavoro fosse nascosto dietro la parola “finito”.
Il lancio mi ha dato un tipo diverso di informazione
Dopo la release è arrivato il lavoro meno fotogenico: bug visibili solo dopo la pubblicazione, flussi rotti, problemi di moderazione che diventano reali quando arrivano gli utenti e domande sulla retention molto più difficili che creare una buona prima impressione.
Cerco di non sovrainterpretare questi segnali. Un bug dopo il rilascio non significa automaticamente che l’architettura sia sbagliata. Un problema di retention, da solo, non è una diagnosi di product-market fit. Un problema di moderazione non dimostra che l’intero sistema sia insicuro. Un sintomo mi indica dove investigare; non mi spiega automaticamente la causa.
Quello che cambia è la qualità delle prove. Prima del lancio posso testare ciò che mi aspetto che gli utenti facciano. Dopo il lancio devo confrontarmi con ciò che fanno davvero. Una release non è il momento in cui l’incertezza scompare. È il momento in cui una parte dell’incertezza più importante diventa finalmente osservabile.
Il ciclo post-lancio che uso adesso
Oggi mi interessa più il lavoro dopo il lancio che rendere perfetto il racconto del lancio: lezioni sui pagamenti, flussi rotti, sfide di moderazione, comportamento degli utenti, sorprese sulla retention e piccole correzioni che rendono il prodotto gradualmente più affidabile.
- Osservare il flusso reale. Non dare per scontato che il percorso che ho progettato sia quello che gli utenti seguono davvero.
- Separare sintomi e cause. Uno step che fallisce mostra dove è successo qualcosa, non automaticamente perché.
- Dare priorità ai fallimenti che toccano la fiducia. Pagamenti, accesso, onboarding e moderazione per me sono più urgenti delle imperfezioni cosmetiche, perché il costo dell’errore è maggiore.
- Correggere prima il problema verificato più piccolo. Preferisco eliminare una fonte di attrito confermata invece di ridisegnare un sistema attorno a un’ipotesi.
- Ricontrollare l’esperienza utente dopo la correzione. Una modifica al codice può essere corretta e comunque non risolvere il problema vissuto dall’utente.
Non è un framework universale. È semplicemente la disciplina che per me ha più senso da quando sono passato dal costruire al gestirlo.
Il lancio ha cambiato la mia fonte di verità
La distinzione che mi interessa di più oggi è tra aver costruito il prodotto ed essere pronti a gestirlo. Costruire significa chiedersi se il sistema fa ciò per cui l’ho progettato. Gestire significa chiedersi cosa succede quando persone reali lo usano, lo capiscono male, lo abbandonano, tornano, pagano o finiscono in un percorso che non avevo previsto.
Per questo non considero più il lancio come un traguardo. Prima del lancio, gran parte delle prove arriva dalle mie ipotesi e dai miei test. Dopo, il prodotto inizia a rispondere attraverso comportamento reale, errori e uso ripetuto.