Lo scope è il vero prodotto
17 marzo 2026
C'è un tipo specifico di produttività che sembra andare bene e invece fa danni. Sei in flow, stai spedendo feature, chiudi ticket. L'app cresce. Il backlog si svuota. Tutto sembra progresso.
Poi mostri il prodotto a un nuovo utente e lo guardi confondersi davanti a un'opzione che non aveva chiesto, un'impostazione che non capisce, un flusso che ha senso solo se già sai perché esiste. Le feature sono singolarmente difendibili. Insieme, hanno reso il prodotto più difficile da usare del necessario.
Questo è lo scope. Non un problema di pianificazione — un problema che si accumula.
L'attrazione del "sì"
Quando sei l'unico sviluppatore, ogni richiesta è tecnicamente realizzabile. Non c'è nessuno che frena, nessuna riunione di roadmap da sopravvivere. L'unica persona che può dire no sei tu — e sei anche la persona che ci ha pensato, o che ha sentito un utente chiederlo, o che ci ragiona da due settimane ed è abbastanza convinta che sarebbe una buona idea.
Questa è la vulnerabilità peculiare del lavoro da soli. I team hanno attriti che filtrano le idee cattive prima che raggiungano il codebase. Chi lavora da solo deve costruire quell'attrito da solo, deliberatamente, come pratica.
La disciplina non viene naturale. Va contro l'istinto di costruire, di aiutare, di migliorare. La maggior parte delle idee nel backlog sono genuinamente buone idee. Ed è esattamente questo che le rende pericolose.
Cosa costa davvero lo scope
Il costo di costruzione è la parte che si vede. Una nuova feature richiede una settimana, la rilasci, fatto. Quello che non vedi è ciò che hai aggiunto permanentemente al sistema.
Ogni feature è una nuova superficie da mantenere. Edge case che non avevi anticipato. Interazioni con le feature che verranno dopo. Bug che risalgono a due feature che funzionano correttamente in isolamento e in modo scorretto in combinazione. Domande di supporto da utenti che hanno trovato l'opzione e non sanno cosa fa.
La versione più chiara che ho vissuto: un flag "priorità" sui messaggi in un prodotto che stavo costruendo. Una richiesta ragionevole — alcuni messaggi sono più importanti di altri. L'ho costruito. Funzionava. Significava anche che ogni superficie che mostrava messaggi doveva decidere come renderizzare la priorità: la inbox, la notifica, i risultati di ricerca, l'export. Un flag secondario era diventato un concern trasversale che toccava più parti del sistema di quanto qualsiasi singola feature avesse il diritto di fare.
Gli utenti che l'avevano chiesto lo usavano occasionalmente. La complessità era invisibile per loro ma presente ovunque nel codice — non come un peso che potevi indicare, solo come motivo per cui ogni modifica ai messaggi richiedeva leggermente più tempo del necessario.
Il test prima di costruire
Prima di aggiungere qualcosa a un prodotto adesso, faccio due domande.
La prima: riesco a descrivere questa feature a un utente in una frase, e capirà immediatamente perché la vorrebbe? Se la spiegazione richiede contesto, o una premessa, o "è come X ma per il caso in cui Y" — è un segnale che la feature sta risolvendo un problema che non è ancora stato definito bene.
La seconda: cosa fa l'utente oggi senza questa cosa? Se la risposta è "ci aggira in un modo che richiede trenta secondi," la feature probabilmente non vale la pena di essere costruita. Se la risposta è "non riesce a fare la cosa per niente," potrebbe valerne la pena.
Non sono filtri perfetti. Ma rallentano la decisione, e di solito è sufficiente. La maggior parte delle feature non sopravvive a una settimana di riflessione seria.
Il backlog non è una lista di cose da fare
Il reframe più utile che ho trovato: il backlog è un segnale, non una coda.
Un backlog in crescita non significa essere in ritardo. Significa che gli utenti si preoccupano abbastanza da dirti cosa vogliono, il che è un'informazione preziosa su chi sono e cosa stanno cercando di fare. L'obiettivo non è svuotarlo. L'obiettivo è capirlo abbastanza bene da prendere decisioni deliberate su cosa tenere fuori.
Le feature che non costruisci sono parte del prodotto quanto quelle che costruisci. Un prodotto che fa una cosa bene e si ferma lì è più facile da imparare, più facile da supportare, e più facile da estendere in seguito quando capisci meglio il problema. Un prodotto che fa tutto finisce per non fare nulla particolarmente bene.
Il prodotto che hai rilasciato è quello che hai tenuto abbastanza piccolo da poter rilasciare. La versione che aveva tutto dentro è ancora nel backlog.