Architecture · 2026-07-14
Decision Memory: perché il tuo prodotto non dovrebbe dimenticare le sue stesse decisioni
Ogni founder ha rispiegato la stessa decisione a un tool diverso almeno dieci volte. Decision Memory è la risposta architetturale a un problema che nessuno chiama con il suo vero nome.
Un founder decide il nome del prodotto martedì. Mercoledì lo cambia, per un motivo preciso -- un dominio non disponibile, un feedback di un utente, un'intuizione più chiara. Giovedì, aprendo lo stesso tool per aggiornare il pitch deck, deve rispiegare da capo qual è il nome attuale, perché è cambiato, e se il cambiamento ha effetti a valle (sito, materiali di marketing, contratti). La maggior parte degli strumenti non ha un posto dove vive quella storia -- ha solo l'ultimo valore, senza il perché.
Decision Memory registra ogni decisione reale con una forma fissa: soggetto, chi, quando, perché, il trigger che l'ha causata, il contenuto prima e dopo, e l'impatto a catena. Non è un changelog generico -- è progettato perché una domanda come "perché abbiamo cambiato il pricing a marzo?" abbia sempre una risposta reale, verificabile, non ricostruita a memoria da qualcuno che magari non era nella stanza.
La parte meno ovvia è il rollback onesto: se una decisione viene ripensata, il sistema sa esattamente cosa ripristinare, perché ha tenuto il contenuto "prima" -- non solo il "dopo". Questo trasforma ogni decisione da un evento irreversibile in un esperimento che si può davvero disfare, il che cambia il calcolo del rischio per qualunque scelta rapida che un founder deve prendere sotto pressione.