La Feature che Nessuno Voleva
Nel 2019, il team di Notion era ossessionato da un problema: i loro utenti non riuscivano a collaborare in tempo reale su documenti complessi. Così hanno deciso di investire 18 mesi nello sviluppo di un sistema di collaborative editing avanzatissimo, con conflitto resolution intelligente, versioning distribuito e sincronizzazione su più dispositivi contemporaneamente.
Il codice era bellissimo. L'architettura era impeccabile. I test passavano tutti. Era perfetto.
Ci fu solo un piccolo problema: quando lo rilasciarono, scoprirono che il 94% dei loro utenti non aveva mai usato il collaborative editing.
Cosa Era Successo Davvero
Mentre il team si stava facendo il mazzo su quella feature, nessuno aveva mai chiesto veramente agli utenti cosa significasse "collaborare" per loro. Il problema reale non era la sincronizzazione in tempo reale—era ben più banale e invisibile: gli utenti volevano semplicemente sapere chi aveva modificato cosa e quando.
Volevano un changelog. Una roba che richiedeva 2 settimane di sviluppo, non 18 mesi.
Un ingegnere di Notion raccontò poi che avevano testato la feature con 5 clienti enterprise prima del lancio. Quattro dissero "bello, ma non lo userò". Il quinto disse "perfetto!", poi non lo usò mai.
Ma il team continuò comunque.
Perché Succede Sempre
Questo non è un problema di incompetenza. Notion è guidata da gente intelligentissima. Il problema è psicologico: quando inizi a costruire una feature complessa, ogni linea di codice è una conferma che hai scelto bene. Invertire rotta è ammettere di esserti sbagliato. Così continui.
Plus, c'è la trappola del "stakeholder feedback": se hai 3 enterprise clienti che dicono "sì, servirebbe il collaborative editing", senti il dovere di accontentarli. Non realizzi che stanno dicendo sì a una soluzione, non a un problema.
Nessuno si mette a urlare: "Io voglio un sistema di sincronizzazione con OT (Operational Transformation)!". Dicono: "A volte il mio team non sa chi ha scritto questa roba".
Come Notion l'Ha Fatta Franca
La fortuna di Notion è che aveva un prodotto core abbastanza forte da sopportare uno "spreco" di 18 mesi di engineering. Non è andata male male: la feature è comunque utile per il 6% che la usa, e quando la gente non sa come usarla, almeno è lì, bella da vedere.
Ma se fossero stati a 30 dipendenti invece che a 150? Quella sarebbero state le 18 linee vitali del loro cash runway.
La Lezione che Non Cambia Mai
Quando scegli di costruire una feature complessa, la tua unica difesa contro il self-deception è questo:
Non chiedi agli utenti "Ti piacerebbe X?" o "Usi il collaborative editing?"
Chiedi: "Mostrami l'ultimo momento in cui hai avuto il problema che X dovrebbe risolvere. Che ora era? Chi era presente? Come hai risolto prima di avere X?"
Se non riescono a raccontartelo negli ultimi 30 giorni, la feature può aspettare.
Notion l'ha imparato dopo 18 mesi. Tu puoi impararlo oggi.
La prossima volta che il tuo team dice "abbiamo una feature bellissima in arrivo", chiediti: l'hanno veramente vista usare qualcuno? O stanno solo dicendo sì a una soluzione che nessuno ha mai gridato di aver bisogno?
Perché la differenza tra una feature utilizzata dal 94% e una utilizzata dal 6% non è nel codice.
È nelle conversazioni che non hai avuto quando era ancora tempo di cambiar rotta.