Decision Log per Startup
I startup prendono centinaia di decisioni a settimana, ma la maggior parte svanisce in Slack. Ecco come creare un decision log che funzioni.
By Ellis Keane · 2026-03-16
Nel 1986, lo Space Shuttle Challenger si disintegrò 73 secondi dopo il lancio. L'indagine successiva scoprì che gli ingegneri della Morton Thiokol avevano sollevato preoccupazioni riguardo alle guarnizioni degli O-ring la sera prima, sostenendo che il freddo rendeva il lancio pericoloso. La dirigenza li ignorò. La decisione fu presa in una teleconferenza e, sebbene esistessero grafici e testimonianze, il ragionamento critico alla base di quella scelta era frammentato tra i partecipanti e non fu mai trasmesso in modo affidabile lungo la catena di comando.
Non sto paragonando le decisioni di prodotto del vostro startup a un disastro dello Space Shuttle (beh, non la maggior parte di esse). Ma il pattern di fallimento sottostante è lo stesso che vedo ripetersi ogni settimana negli startup, solo con meno in gioco: una decisione viene presa, il ragionamento che la supporta vive nella testa di qualcuno o in un thread Slack che sta per scomparire dallo schermo, e tre mesi dopo nessuno riesce a ricostruire perché abbiamo scelto l'approccio A invece dell'approccio B. Non perché la decisione fosse sbagliata – a volte era ottima –, ma perché il contesto che la rendeva giusta si è volatilizzato.
"Una decisione viene presa, il ragionamento che la supporta vive nella testa di qualcuno o in un thread Slack che sta per scomparire dallo schermo, e tre mesi dopo nessuno riesce a ricostruire perché abbiamo scelto l'approccio A invece dell'approccio B." – Ellis Keane
Un decision log per startup non è un esercizio burocratico. È la differenza tra «abbiamo provato quello e non ha funzionato» (utile) e «credo ne abbiamo parlato una volta?» (inutile).
L'anatomia di una decisione perduta
Permettetemi di tracciare una decisione specifica attraverso il suo ciclo di vita, perché la versione astratta di questo problema è meno convincente di quella concreta.
È un martedì di febbraio. Il vostro responsabile tecnico e il PM sono in un thread Slack a dibattere se costruire un sistema di notifiche personalizzato o usare un servizio di terze parti. Il thread ha 47 messaggi (lo so, ma è così che va), e al messaggio 38 si sono già orientati sull'opzione esterna perché la soluzione interna richiederebbe tre sprint e la scadenza del lancio è tra due settimane.
Il PM crea un ticket Linear: «Integrare [Servizio X] per le notifiche.» Un ingegnere lo prende in carico e inizia a sviluppare. Il thread Slack è ancora lì, tecnicamente, ma nessuno lo salva nei preferiti né lo collega dal ticket Linear.
Saltiamo a maggio. Il servizio di terze parti ha un problema di affidabilità. Qualcuno chiede: «Perché non l'abbiamo costruito noi stessi?» Il PM ricorda la conversazione ma non i dettagli. Il responsabile tecnico è in congedo parentale. Il thread Slack si trova da qualche parte nel canale #engineering di febbraio, ma nessuno ricorda la data esatta, e la ricerca su Slack restituisce 200 risultati per «notifica» – perché, ovviamente, ogni team discute costantemente di notifiche.
Il team trascorre 45 minuti in riunione a ricostruire il ragionamento originale. Alla fine arriva alla stessa conclusione – il vincolo di tempo era ancora valido –, ma i 45 minuti sono andati e il dubbio persiste. Moltiplicate questo per le decine di decisioni che uno startup prende ogni mese, e avete una quota significativa di tempo speso a ridiscutere scelte già prese con cura.
Perché gli startup sono particolarmente scarsi in questo
Le grandi aziende (con tutti i loro difetti, e sono molti) tendono a codificare la memoria istituzionale nei processi: architecture decision records, RFC, documenti di design che passano attraverso cicli formali di revisione. Le decisioni potrebbero essere sepolte in Confluence, ma almeno sono scritte da qualche parte dove possono essere trovate.
Gli startup non hanno questa infrastruttura, e costruirla sembra esattamente il tipo di overhead che si dovrebbe evitare quando si è piccoli e veloci. C'è un argomento ragionevole secondo cui «ce lo ricordiamo» funziona con quattro persone – ed è vero –, fino a quando non arriva la quinta persona che non ha alcun contesto sul perché le cose siano come sono.
L'altra cosa che rende il tracciamento delle decisioni negli startup particolarmente difficile è la frammentazione degli strumenti. Le decisioni avvengono ovunque: thread Slack, chiamate Zoom, commenti Notion, discussioni Linear, revisioni di PR GitHub, e – sempre più spesso – in messaggi diretti che non raggiungono mai un canale condiviso. Ogni strumento cattura un pezzo della decisione, ma nessuno cattura il tutto, e i collegamenti tra di essi sono mantenuti dalla memoria umana, che – detto con affetto – è il database meno affidabile a cui abbiamo accesso.
Cosa ha davvero bisogno un decision log
C'è la tentazione di ingegnerizzare eccessivamente tutto ciò. Ho visto team costruire elaborati database Notion con 15 proprietà per voce – tipo di decisione, livello di impatto, stato della revisione, stakeholder, OKR correlati – per poi non usarli mai perché l'onere di compilare tutti quei campi per ogni decisione è superiore al valore percepito.
Un decision log per startup deve essere abbastanza leggero da essere effettivamente usato. Ecco cosa conta:
La decisione stessa. Una frase. «Utilizziamo il Servizio X per le notifiche invece di costruire una soluzione personalizzata.» Non un paragrafo – una frase.
Chi l'ha presa e quando. Nome e data. Sembra ovvio, ma è la parte che conta di più quando qualcuno mette in discussione la decisione sei mesi dopo. Non si tratta di trovare un colpevole (beh, per lo più no) – si tratta di sapere a chi rivolgersi per il ragionamento originale.
Quali alternative sono state considerate. Due o tre punti elenco. «Considerata la soluzione interna (stima 3 sprint, scadenza troppo stretta)» e «Considerato il Servizio Y (il prezzo non scala oltre i 10.000 utenti).» Questa è la parte che previene le discussioni ripetute – se le alternative e i loro compromessi sono documentati, il team non deve riscoprirli.
Dove si è svolta la discussione. Un link al thread Slack, al ticket Linear, al commento Notion – ovunque si sia svolto il vero dibattito. Questo è il campo più sottovalutato. Senza di esso, la voce del log è un'affermazione senza prove. Con esso, chiunque voglia il contesto completo può leggere la conversazione originale.
Cosa cambierebbe la decisione. Questo è facoltativo ma incredibilmente utile per gli startup dove il contesto cambia rapidamente. «Riesamineremmo questo se la scadenza del lancio si spostasse di più di 4 settimane» o «Questo presuppone che rimaniamo sotto le 10.000 notifiche mensili.» Trasforma un registro statico in uno vivo.
Il miglior decision log per startup è quello che il vostro team compila davvero. Cinque campi, una frase ciascuno. Se ci vogliono più di 90 secondi per registrare una decisione, il sistema morirà entro un mese.
Dove tenerlo
Ho visto team provare tre approcci, e tutti hanno i loro compromessi.
Un database Notion. È il più comune e funziona ragionevolmente bene. Create un database con i cinque campi sopra, aggiungete un modello per velocizzare la compilazione e collegate ogni voce alla pagina di progetto pertinente. Lo svantaggio: Notion è il posto dove vivono le specifiche, non dove si prendono le decisioni, quindi dipendete dal fatto che qualcuno vada su Notion dopo che la decisione è stata presa altrove. Quel passaggio «dopo» è dove si verifica l'abbandono.
Direttamente in Slack. Alcuni team usano un canale dedicato #decisioni e pubblicano un messaggio formattato per ogni decisione. Ha meno attrito (la decisione è probabilmente stata presa in Slack comunque), ma la ricerca di Slack rende difficile trovare le decisioni per progetto o intervallo di date, e l'assenza di campi strutturati significa che la coerenza degrada nel tempo.
Direttamente in Linear. Se la decisione riguarda un flusso di lavoro specifico, registrarla come commento sul ticket Linear pertinente mantiene la decisione vicina al lavoro che influenza. Lo svantaggio è che le decisioni che coprono più ticket o progetti non hanno una sede naturale.
Nessuno di questi è ideale, a essere onesti. Il problema fondamentale è che le decisioni avvengono su più strumenti, ma i log vivono in un solo strumento, quindi c'è sempre un passaggio manuale per colmare il divario. Quel passaggio manuale è l'unico punto di fallimento di ogni decision log che ho visto.
Cosa stiamo costruendo in Sugarbug
L'approccio che stiamo adottando con Sugarbug è rilevare le decisioni nel momento in cui avvengono attraverso gli strumenti, piuttosto che richiedere a qualcuno di registrarle manualmente.
Quando un thread Slack raggiunge una conclusione («OK, andiamo con il Servizio X»), quando una discussione su un ticket Linear si risolve, quando una revisione di PR GitHub si conclude con un'approvazione – questi sono tutti segnali che una decisione è stata presa. Sugarbug acquisisce questi segnali, li classifica e li collega ai compiti e alle persone rilevanti nel grafo della conoscenza. Il «decision log» non è un database separato che qualcuno deve mantenere – è una vista sulle decisioni già incorporate nei vostri strumenti esistenti.
Stiamo ancora lavorando sulla precisione della classificazione (capire la differenza tra «una decisione» e «solo una conversazione» è più difficile di quanto sembri), ma la scommessa direzionale è che catturare le decisioni alla fonte, dove avvengono effettivamente, è più affidabile che chiedere alle persone di duplicarle in un sistema separato.
Se vi interessa, sugarbug.ai ha ulteriori dettagli. Ma il sistema manuale descritto sopra servirà bene la maggior parte degli startup fino a quando il team non sarà abbastanza grande da rendere il tasso di abbandono della registrazione manuale un problema reale – di solito intorno alle 8–12 persone, nella nostra esperienza.
Smetti di perdere decisioni nello scroll di Slack. Sugarbug le cattura automaticamente dagli strumenti dove avvengono davvero.
Q: Cosa dovrebbe contenere il decision log di uno startup? A: Come minimo: la decisione stessa (una frase), chi l'ha presa, quando, quali alternative sono state considerate e dove si è svolta la discussione. Quest'ultimo campo è il più importante – senza un link alla conversazione originale, la voce del log diventa un'affermazione priva di prove, e quando qualcuno la mette in discussione sei mesi dopo vi ritrovate a ricostruire tutto dalla memoria.
Q: Sugarbug costruisce automaticamente un decision log dagli strumenti esistenti? A: È la direzione che stiamo prendendo. Sugarbug acquisisce segnali da Slack, Linear, GitHub, Notion e altri strumenti, classificandoli in un grafo della conoscenza. Quando rileva una decisione – una PR approvata, una discussione Linear risolta, un thread Slack che si conclude con un passo successivo chiaro –, collega automaticamente quella decisione al compito e alle persone rilevanti. Stiamo ancora affinando la classificazione (distinguere «decisione» da «conversazione» è genuinamente complicato), ma l'acquisizione e il collegamento dei segnali funzionano.
Q: Con quale frequenza uno startup dovrebbe aggiornare il suo decision log? A: Idealmente, le decisioni vengono registrate nel momento in cui vengono prese, non accumulate settimanalmente. Il venerdì, il ragionamento dietro la decisione del martedì è già sfumato, e la probabilità che qualcuno compili accuratamente il campo «alternative considerate» scende rapidamente. Se la registrazione è manuale, fatela diventare un'abitudine di 90 secondi subito dopo la decisione. Se usate uno strumento come Sugarbug, l'obiettivo è la cattura in tempo reale dagli strumenti dove le decisioni avvengono effettivamente.
Q: Sugarbug può tracciare le decisioni su Slack, Linear e GitHub? A: Sugarbug si connette a tutti e tre (e a Notion e Figma) e mantiene un grafo della conoscenza delle relazioni tra conversazioni, attività e modifiche al codice. Quando una decisione emerge in un thread Slack, porta a un ticket Linear e genera una PR GitHub, Sugarbug collega l'intera catena in modo che possiate tracciare la decisione dall'origine all'implementazione senza che nessuno debba creare manualmente quei collegamenti.
Q: Qual è la differenza tra un decision log e un Architecture Decision Record (ADR)? A: Gli ADR sono tipicamente documenti formali per scelte tecniche significative – «usiamo PostgreSQL invece di MongoDB» – con sezioni strutturate per contesto, decisione e conseguenze. Un decision log per startup è più ampio e più leggero: cattura le decisioni operative quotidiane (quale fornitore, quale scadenza, quale funzionalità tagliare) che gli ADR considererebbero troppo piccole per essere documentate. Entrambi sono preziosi; il decision log copre il 95% delle decisioni che non giustificano un ADR formale ma che devono comunque essere tracciabili.