02 - Lancio side project: pre-mortem checklist

Il costo di scoprire i rischi dopo il lancio

Lanciare un side project senza aver cercato i modi in cui può fallire significa scoprirli uno alla volta, con i clienti a guardare e con la tua energia già spesa. Una pre-mortem rovescia l'ordine: prima del lancio ti metti nel futuro in cui il progetto è andato male, scrivi perché, e trasformi quella storia in poche azioni con una data. Richiede poche ore, si fa da soli e cambia davvero le decisioni, perché sposta l'attenzione da «come va bene» a «dove cede».

La tecnica ha una fonte precisa: la descrive Gary Klein nell'articolo «Performing a Project Premortem», pubblicato su Harvard Business Review a settembre 2007. Nella sintesi della rivista, i membri del gruppo assumono che il progetto che stanno pianificando sia appena fallito, come tanti progetti, e poi generano motivazioni plausibili del fallimento. Non è pessimismo: è un modo di dare agli altri e a te stesso il permesso di dire ciò che altrimenti taci per non sembrare quello che frena.

Come si svolge, passo per passo

La sequenza conta, perché ogni passo dipende dal precedente: se salti la scrittura della storia, i rischi che elenchi sono quelli che avevi già in testa. Per questo i passi vanno fatti nell'ordine.

1. Fissa la data del fallimento. «Siamo a giugno, il prodotto è online da sei mesi e non ha clienti paganti».
2. Scrivi la storia in prima persona, in due o tre paragrafi, con cause specifiche e non «non interessava a nessuno».
3. Estrai i rischi da quella storia, uno per riga, senza giudicarli.
4. Dai a ciascun rischio probabilità e impatto, poi ordina per prodotto dei due.
5. Per i primi tre scrivi un'azione e una data. Gli altri restano sotto osservazione.

Il passo che la maggior parte salta è il secondo: scrivere la storia costringe a scegliere una causa, e quando scegli ti accorgi di che cosa conosci davvero. Il quarto passo evita la lista infinita: con una scala da 1 a 5 e un prodotto, ottieni un ordine, e un ordine è già una decisione. L'ultimo passo è quello che decide se la pre-mortem serve: un rischio senza azione e data è un'opinione.

Un esempio di storia, dichiarato inventato

Per capire la differenza tra una causa vaga e una specifica, ecco un esempio costruito apposta, senza fonti né persone reali. Versione vaga: «Il prodotto non ha funzionato perché il mercato non era pronto». Versione specifica: «Ho costruito per quattro mesi uno strumento per commercialisti, ho parlato con tre di loro e tutti hanno detto che era utile, ma nessuno aveva un budget e il prezzo di 29 euro al mese era stato scelto a caso; alla fine delle beta nessuno ha inserito una carta». La seconda storia nomina tre cose che puoi controllare prima: il numero di interviste, la domanda sul budget e la prova del pagamento. La prima non nomina niente.

Sei scenari che meritano una riga nel registro

Non esiste una lista universale di cause di fallimento, e le percentuali che circolano in rete senza fonte non vanno ripetute. Quello che segue sono sei scenari frequenti nei progetti piccoli, scelti perché hanno ciascuno un controllo che puoi fare in una sera.

Nessuno paga

Il segnale di mercato più forte è un pagamento, anche piccolo e anticipato. Un elogio costa a chi lo fa meno di un euro e non dice nulla sul prezzo. Una soglia pratica è chiedere un pagamento a cinque persone della beta; è una regola di lavoro, non uno standard, e se nessuna paga hai informazione preziosa prima di spendere altri mesi.

Il servizio si ferma senza che tu lo sappia

Un controllo esterno che richiama il sito ogni minuto e ti avvisa sul telefono costa pochi minuti di configurazione e rimuove un'intera categoria di sorprese. Senza, scopri il guasto da una email di un cliente arrabbiato, di solito la mattina dopo.

Perdi i dati

Un backup che non hai mai ripristinato è una speranza. Scrivi una prova di ripristino sulla lista delle azioni, e tienila come primo punto della lista tecnica: lo spiega l'articolo sull'hosting low-cost.

Sbagli il fisco o l'IVA

È il rischio con il danno più difficile da vedere in anticipo: un errore sulle regole fiscali si scopre dopo mesi. L'azione è parlare con un commercialista prima di vendere, portando domande scritte. Nell'articolo sul regime forfetario trovi le regole e le fonti ufficiali.

Il supporto ti consuma

Ogni cliente scrive, e una risposta di venti minuti ripetuta cinquanta volte sono quasi diciassette ore. Cinque risposte-tipo scritte prima del lancio riducono molto il tempo; l'articolo sul supporto da solo mostra come organizzarle.

Perdi interesse

Il rischio più umano: dopo qualche mese senza risultati smetti di lavorarci. L'azione efficace è una scadenza pubblica o condivisa con una persona che ti chiederà conto, e una dimensione del progetto così piccola da poter fare progressi visibili ogni settimana.

Il registro dei rischi, in un programma

Il quarto passo (probabilità per impatto, poi ordinamento) è meccanico e conviene lasciarlo a un programma, così lo riesegui quando cambia un numero. Il listato seguente è un esempio dichiarato: i cinque rischi e i punteggi sono inventati per mostrare il meccanismo, sostituiscili con i tuoi. La funzione punteggio moltiplica probabilità e impatto, sorted ordina in modo decrescente e, essendo stabile, a parità di punteggio rispetta l'ordine in cui hai scritto i rischi. Solo i primi tre ricevono una scadenza, perché più di tre azioni aperte non si fanno.

# Registro dei rischi di una pre-mortem: probabilita' e impatto da 1 a 5,
# scelti da te DOPO aver scritto la storia del fallimento.
# I rischi qui sotto sono un esempio dichiarato, non dati di mercato.
rischi = [
    # (rischio, probabilita', impatto, azione concreta, entro quando)
    ("nessuno paga dopo la beta", 4, 5, "chiedere un pagamento anticipato a 5 beta tester", "2027-02-15"),
    ("il server si ferma di notte senza che io lo sappia", 3, 3, "attivare un controllo esterno con avviso sul telefono", "2027-01-31"),
    ("sbaglio l'IVA su un cliente di un altro Paese", 3, 4, "chiedere al commercialista come trattare le vendite UE", "2027-01-20"),
    ("le email di supporto mi divorano le sere", 3, 3, "scrivere 5 risposte-tipo prima del lancio", "2027-02-01"),
    ("perdo il database senza un backup recente", 2, 5, "backup notturno fuori dal server e un ripristino provato", "2027-01-25"),
]

def punteggio(r):
    return r[1] * r[2]

# sorted e' stabile: a parita' di punteggio resta l'ordine con cui li hai scritti
ordinati = sorted(rischi, key=punteggio, reverse=True)
for posizione, r in enumerate(ordinati, start=1):
    marcatore = "AZIONE ENTRO %s" % r[4] if posizione <= 3 else "monitorare"
    print(f"{posizione}. [{punteggio(r):>2}] {r[0]} -> {marcatore}: {r[3]}")

# Output:
# 1. [20] nessuno paga dopo la beta -> AZIONE ENTRO 2027-02-15: chiedere un pagamento anticipato a 5 beta tester
# 2. [12] sbaglio l'IVA su un cliente di un altro Paese -> AZIONE ENTRO 2027-01-20: chiedere al commercialista come trattare le vendite UE
# 3. [10] perdo il database senza un backup recente -> AZIONE ENTRO 2027-01-25: backup notturno fuori dal server e un ripristino provato
# 4. [ 9] il server si ferma di notte senza che io lo sappia -> monitorare: attivare un controllo esterno con avviso sul telefono
# 5. [ 9] le email di supporto mi divorano le sere -> monitorare: scrivere 5 risposte-tipo prima del lancio

Guarda l'uscita: il rischio «nessuno paga» vale 20 su 25 ed è in cima, mentre il fermo del server, che sembra il più «tecnico», vale 9 ed è in quarta posizione. È proprio il motivo per cui si fa l'esercizio: la sera successiva tenderesti a sistemare il server, perché è più divertente, e il punteggio ti dice che la cosa urgente è chiedere un pagamento. Il listato non dipende da data, caso o ordine di insiemi, e il risultato è identico a ogni esecuzione. Il limite è che i numeri restano soggettivi: il programma ordina le tue stime, non le corregge.

Controlli prima del lancio che hanno una norma dietro

Alcune voci della checklist non sono opinioni, e conviene riconoscerle perché la dimenticanza ha conseguenze. Tre le trovi nei testi ufficiali che ho consultato il 2026-11-13, e le riporto con il riferimento esatto, senza trasformarle in consulenza legale.

• Informativa privacy. L'articolo 13 del regolamento (UE) 2016/679 prevede che il titolare del trattamento fornisca all'interessato, nel momento in cui i dati sono ottenuti, tra l'altro la sua identità e i suoi contatti, le finalità e la base giuridica del trattamento.
• Violazione dei dati. L'articolo 33 dello stesso regolamento prevede la notifica all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando ne sei venuto a conoscenza, salvo rischio improbabile.
• Recesso del consumatore. Il Codice del consumo (d.lgs. 206/2005) all'articolo 52 dà ai consumatori quattordici giorni per recedere dai contratti a distanza, e l'articolo 59, lettera o), prevede un'eccezione per i contenuti digitali su supporto non materiale a condizioni precise, tra cui il consenso espresso all'avvio dell'esecuzione e il riconoscimento della perdita del diritto di recesso.

Sono tre obblighi diversi con la stessa conseguenza pratica: vanno costruiti nel prodotto prima del lancio, non aggiunti dopo la prima segnalazione. L'informativa è una pagina, la notifica una procedura scritta che ti serve sapere dove sta, e il recesso richiede una casella da spuntare nel pagamento. Per il resto dei casi ti serve un professionista: questo articolo ti dice dove guardare, non cosa fare nel tuo caso. Per i dettagli sul checkout vai all'articolo sui pagamenti con Stripe.

Tre errori che rovinano la pre-mortem

L'errore più comune è difendere il progetto mentre si finge di attaccarlo: se ti sorprendi a scrivere «ma il mio prodotto è diverso», cambia prospettiva e immagina di dover spiegare il fallimento a un amico che ti ha dato soldi. Il secondo è elencare rischi generali: «il marketing non funziona» non porta ad alcuna azione, mentre «dopo tre articoli nessuno cerca la parola che ho scelto» sì. Il terzo è scrivere azioni senza data né misura di completamento: «fare marketing» non si completa mai, «pubblicare tre articoli entro il 20 marzo e controllare le impressioni» sì.

Per ordine di lettura, dopo la pre-mortem ha senso passare al regime forfetario e poi a come leggere i casi di successo senza farsi guidare dal bias del sopravvissuto. Lo stack di partenza è nel primo articolo della serie.

Domande frequenti

Una pre-mortem funziona anche se lavoro da solo?

Sì, perde il vantaggio del gruppo ma tiene quello della scrittura. Dopo aver scritto la storia, falla leggere a una o due persone di cui ti fidi e chiedi loro un rischio che hai tralasciato: la lettura da fuori trova ciò che tu hai dato per scontato.

Quanto tempo richiede?

Una stima ragionevole, non misurata, è un paio d'ore per la prima sessione tra storia, elenco dei rischi e punteggio. Il tempo dipende dal progetto: uno strumento con pagamenti e dati personali ne richiede di più di una pagina statica.

Se la pre-mortem mi dice di non lanciare?

Hai guadagnato mesi. Un rischio molto probabile e molto grave senza un'azione credibile è un motivo valido per ridurre il progetto, cambiare pubblico o fermarsi. Il fallimento già scritto sulla carta costa una sera, quello vero costa il tuo tempo.

Che cosa sai fare adesso

Sai condurre una pre-mortem in cinque passi, scrivere una storia di fallimento con cause specifiche, trasformarla in un registro ordinato per probabilità e impatto, e distinguere i controlli che hanno una norma (privacy, notifica di violazione, recesso) da quelli che sono scelte tue.