Il backlog non è una discarica: è uno strumento d'azione

In molte organizzazioni di prodotto, il backlog è diventato un cestino pulito.

Arriva un'idea? Backlog.

Una richiesta cliente? Backlog.

Un bug non urgente? Backlog.

Una pista di discovery? Backlog.

Un'intuizione del Product Manager? Backlog.

Una frase sentita in una riunione commerciale? Backlog.

Ci si mette tutto «per non dimenticare». E qualche mese dopo ci si ritrova con 300, 500, a volte 1.000 righe che nessuno capisce più davvero.

Non è trasparenza.

È rumore.

Un backlog che contiene tutto non chiarisce nulla. Dà solo l'illusione che l'informazione esista da qualche parte, mentre è diventata inutilizzabile.

Il backlog non dovrebbe essere un deposito di idee. Non dovrebbe essere una base di richieste clienti. Non dovrebbe essere uno strumento di discovery. Non dovrebbe essere un archivio. Non dovrebbe essere il cimitero dei bug che non si è voluto risolvere.

Un backlog è uno strumento d'azione.

Serve a organizzare informazioni già sufficientemente mature da permettere a più persone di lavorare insieme.

La trasparenza non consiste nel mostrare tutto

L'argomento classico per mettere tutto nel backlog è quello della trasparenza.

«Almeno, tutto è visibile.»

In teoria è seducente. In pratica, è spesso falso.

Un backlog di 500 righe non è trasparente. È opaco. Nessuno sa davvero cosa conta. Nessuno sa cosa è ancora valido. Nessuno sa cosa è strategico, cosa è vecchio, cosa è stato rifiutato, cosa è solo un'idea, cosa viene da un cliente importante, cosa è già stato ridiscusso tre volte.

Tutto è visibile, quindi nulla è più leggibile.

La trasparenza utile non consiste nell'esporre tutto. Consiste nel rendere comprensibili le decisioni.

Perché questo tema è nella roadmap?

Perché quell'altro non c'è?

Perché questo bug viene risolto adesso?

Perché questa richiesta cliente rimane un segnale e non diventa lavoro?

Perché questo tema è stato rifiutato?

Un'idea immatura può restare fuori dal backlog senza essere nascosta. Semplicemente non è ancora pronta a diventare un oggetto collettivo.

Bisogna distinguere gli spazi:

• una memoria di prodotto;
• una base di segnali;
• note di riflessione;
• decisioni;
• rifiuti;
• un backlog.

Non tutto deve diventare backlog.

Prima del backlog: lo spazio personale del Product Manager

Prima che un tema entri nel backlog, può esistere altrove.

E quel altrove non ha bisogno di essere standardizzato.

Un Product Manager può lavorare in Obsidian. Un altro in Apple Notes. Un altro in Trello. Un altro in un taccuino. Un altro in una base più strutturata. Il nome ha poca importanza: giardino del PM, sala d'attesa, parcheggio, note personali — poco importa.

Finché il lavoro resta individuale, ognuno può usare lo strumento che gli riesce meglio.

È anzi preferibile.

Lo spazio personale del PM serve ad assorbire la tempesta di idee. Si raccoglie, si connette, si approfondisce, si lascia riposare, si elimina. Alcune idee matureranno. Altre spariranno. Molte non meritano mai di essere viste da qualcun altro.

È normale.

Un'idea di tre righe depositata «per non dimenticare» non ha posto in uno strumento collettivo. Non è ancora pronta a mobilitare l'attenzione di uno sviluppatore, di un designer, di un data analyst, di un sales o di un dirigente.

Finché un'idea resta un pensiero individuale, non ha bisogno di uno strumento collettivo.

Il backlog inizia quando il tema diventa collaborativo

La vera regola d'ingresso è semplice:

Il backlog inizia quando il tema smette di essere un pensiero individuale e diventa lavoro collettivo.

Se il Product Manager continua ad approfondire da solo, non è ancora backlog.

Se il tema richiede uno studio di fattibilità, bisogna parlare con gli sviluppatori. Lì il backlog può diventare utile.

Se il tema si basa su un'ipotesi d'uso o di valore, forse bisogna esplorare i dati di prodotto con un data analyst. Lì il backlog può diventare utile.

Se il tema richiede un design d'interfaccia, bisogna lavorare con il design. Lì il backlog può diventare utile.

Se il tema viene dal supporto, forse bisogna riunire supporto, prodotto, data e sviluppo. Lì il backlog può diventare utile.

Ma entrare nel backlog non significa depositare tre righe e chiedere agli altri di arrangiarsi.

Il Product Manager deve estrarre un minimo di quello che ha in testa:

• perché si guarda questo tema;
• quale target è coinvolto;
• quale dolore o opportunità si persegue;
• quale valore è atteso;
• quale domanda deve essere risolta;
• quali segnali esistono già;
• quale collaborazione è necessaria.

Non è una checklist burocratica. È il minimo per permettere ad altre persone di lavorare con te.

Una richiesta del tipo «fammi un'analisi dei dati su questo tema» non basta. Una richiesta del tipo «guarda se vale la pena» neanche.

Il backlog deve permettere una collaborazione strutturata. Non deve delegare un pensiero ancora nebuloso.

Il backlog non sostituisce la conversazione

C'è una trappola inversa: voler formalizzare tutto.

Creare template ovunque. Aggiungere campi. Imporre checklists. Trasformare ogni ticket in un mini-dossier. Scrivere per coprirsi invece di scrivere per lavorare.

Non è meglio.

Il livello di dettaglio necessario dipende dal team, dal tema e dal contesto condiviso.

Quando un Product Manager lavora da tre anni con lo stesso sviluppatore, non ha sempre bisogno di scrivere quanto quando uno sviluppatore è arrivato da tre mesi.

Quando il team si parla tutti i giorni, alcune cose possono restare orali.

Quando il team è nuovo, distribuito o su un tema rischioso, bisogna esplicitare di più.

I concetti di Definition of Ready e Definition of Done possono aiutare. Danno dei riferimenti. Ma devono restare vivi. Non devono diventare una burocrazia che sostituisce il giudizio.

Uno sviluppatore non dovrebbe accettare un ticket che non capisce.

Se mancano elementi per valutare la fattibilità, deve chiederli.

Se manca il contesto di business, deve chiederlo.

Se non capisce il valore, deve dirlo.

Una user story non è mai stata fatta per sostituire la conversazione. Serve ad avviarla.

Il backlog deve essere pensato allo stesso modo.

Struttura la conversazione. Non la sostituisce.

Un backlog deve essere limitato

Un backlog illimitato è contraddittorio con una roadmap limitata.

Se la roadmap NNL è pensata per proteggere l'azienda dalla dispersione, il backlog non può assorbire tutto ciò che la roadmap rifiuta.

In una roadmap Now / Next / Later, il Now dipende dalla capacità reale del team. Il Next deve restare limitato. Anche il Later, che dovrebbe rappresentare il campo dei possibili, non può contenere cinquanta direzioni diverse. Altrimenti diventa di nuovo un inventario.

Il backlog deve prolungare questo vincolo.

Non serve a nulla avere una roadmap chiara e un backlog che contiene tutto il resto.

Stessa logica per i bug.

Se si applica una policy zero bug, un difetto reale deve essere risolto. Se non è un difetto, può essere riqualificato. Se il tema non vale la pena di essere risolto, lo si assume e lo si scarta.

Ma accumulare bug nel backlog per dopo equivale a spazzare la polvere sotto il tappeto.

Si crede di conservare un'informazione. In realtà si conserva una decisione non presa.

Un backlog limitato protegge la capacità del team. Protegge anche l'energia mentale. Una lista infinita crea tensione permanente: tutto quello che non si è fatto, tutto quello che forse si farà, tutto quello che si tiene per ogni evenienza, tutto quello che aspetta senza una ragione chiara.

Non è neutro.

Un backlog che cresce affatica.

Se aggiungo questo, cosa tolgo?

La regola d'igiene dovrebbe essere semplice:

Se aggiungo questo, cosa tolgo?

Scegliere significa rinunciare.

Aggiungere senza togliere equivale a negare la capacità reale del team. È fare come se il tempo, l'attenzione al prodotto, la disponibilità degli sviluppatori, la capacità di design, l'analisi dei dati e il carico del supporto fossero estendibili.

Non lo sono.

Un tema può uscire dal backlog per vari motivi:

• il mondo è cambiato;
• il business è cambiato;
• la strategia di prodotto è cambiata;
• la conoscenza di prodotto è progredita;
• il tema non è più pertinente;
• il tema è troppo debole;
• il tema è fuori dalla roadmap;
• il tema non è mai maturato.

Bisogna poter scartare.

Il backlog non deve proteggere le vecchie idee dall'eliminazione. Deve proteggere la capacità del team di agire sui temi giusti.

I ticket vecchi marciscono

Si sottovaluta l'invecchiamento dei ticket.

Un'idea creata oggi e riletta sei mesi dopo non è necessariamente un buon ricordo. Spesso è scaduta.

Il prodotto è cambiato. I clienti sono cambiati. Il mercato è cambiato. Le priorità sono cambiate. Il team ha imparato. La tecnica si è evoluta. L'IA ha forse reso possibile ciò che non lo era, o reso inutile ciò che sembrava importante.

Riprendere un vecchio ticket può essere peggio che ripartire da zero.

Il pericolo viene anche dall'avversione alla perdita. Poiché il ticket esiste, si vuole conservarlo. Poiché qualcuno ha scritto qualcosa, si esita a scartarlo. Poiché una richiesta è stata catturata, si vuole darle una chance.

Ma un ticket non è un patrimonio perché esiste.

Un vecchio ticket non è necessariamente un ricordo. È spesso un'ipotesi ammuffita.

Se il tema torna a essere interessante, lo si può riaprire in modo pulito. Ma bisogna rivalutarlo nel contesto attuale, non riprendere meccanicamente una vecchia formulazione.

Un solo backlog per abbattere i silos

Non credo nei backlog separati per tipo di lavoro.

Un backlog di prodotto.

Un backlog tecnico.

Un backlog di bug.

Un backlog di supporto.

Un backlog di discovery.

In un unico team, questa frammentazione rompe la priorizzazione.

Certo, se più team lavorano su perimetri diversi, possono avere più backlog o più viste. Ma in un dato spazio di priorizzazione, serve un backlog unico.

Perché?

Perché non si priorizzano categorie. Si priorizzano dolori, rischi e valore.

Un tema che viene dal supporto può richiedere supporto, un data analyst e uno sviluppatore.

Un tema di prodotto può richiedere prodotto e design, senza grande implicazione tecnica.

Un tema di export può non richiedere design, ma una forte conoscenza di business e una validazione tecnica sui trattamenti dei dati.

Il ragionamento corretto non è: «in quale backlog va questo tema?»

Il ragionamento corretto è: «quale problema affrontiamo, e di quali persone abbiamo bisogno?»

È anche per questo che la distinzione bug / feature è spesso troppo povera. Il cliente sente un dolore. Non si chiede se appartiene al backlog bug, al backlog di prodotto o a quello tecnico.

La domanda è: quale dolore è prioritario rispetto alla strategia, ai clienti e alla capacità reale?

Una richiesta cliente non è un item di backlog

Catturare una richiesta cliente è importante.

Ma una richiesta cliente non è un item di backlog.

È un segnale.

I clienti sono spesso molto bravi a spiegare i loro problemi. Sanno descrivere un dolore, un vincolo, un contesto, una frustrazione, un obbligo di business.

Sono molto meno affidabili quando si tratta di proporre la soluzione giusta.

Bisogna prendere la richiesta come materiale di apprendimento, non come un'istruzione d'esecuzione.

Una richiesta cliente può alimentare il backlog. Ma non è automatico.

Può restare in una base di segnali.

Può essere connessa ad altre richieste.

Può riemergere più tardi.

Può non riemergere mai.

Può non corrispondere alla strategia di prodotto.

Può non rientrare nella roadmap.

Può riguardare un caso troppo isolato.

Può essere interessante, ma non abbastanza importante.

Il backlog non deve assorbire tutte le richieste clienti con il pretesto di non perderle.

Una richiesta cliente è materiale di apprendimento, non un'istruzione d'esecuzione.

Tracciare certi rifiuti senza ricreare un backlog nascosto

Bisogna tracciare i rifiuti?

A volte, sì.

Ma tracciare un rifiuto non significa tenere un tema come da fare.

Certi rifiuti meritano una traccia perché creano conoscenza storica. Oggi si rifiuta per una ragione data: costo, strategia, fattibilità, mancanza di competenza, bassa domanda, timing sbagliato.

Un anno dopo, la decisione può cambiare.

Il business può essersi evoluto.

La posizione di prodotto può essere cambiata.

L'IA può aver reso fattibile ciò che era troppo costoso.

Il team può aver assunto un data analyst.

La fattibilità tecnica può essersi evoluta.

In questi casi, è utile capire perché il tema era stato rifiutato.

Ma non tutti i rifiuti meritano una traccia. Molte idee deboli possono semplicemente sparire.

Se il rifiuto è strutturante, ricorrente o trasversale, può anche diventare un PDR. Si documenta allora la decisione, il suo contesto, le sue alternative e le condizioni che potrebbero farla evolvere.

La traccia del rifiuto deve servire la memoria. Non deve ricreare un backlog nascosto.

Nell'era dell'IA, il backlog non è più il luogo dove si pensa

Il punto più importante oggi è forse questo: il backlog non è più il posto giusto per pensare il prodotto.

Strumenti come Jira, Notion o i loro equivalenti restano spesso strumenti a schede. Elaboratori di testo migliorati. Spazi dove si organizzano item, stati, campi, commenti.

Possono essere utili per coordinare l'azione.

Ma sono molto deboli per costruire una riflessione di prodotto.

Gli agenti IA integrati in questi strumenti a volte migliorano un testo, riformulano un ticket, propongono un riassunto. È utile al margine. Ma non è un sistema di pensiero.

Il vero patrimonio è a monte.

Un contesto di prodotto ricco può contenere:

• fonti;
• interviste trascritte;
• note atomiche;
• note tematiche;
• glossari;
• decisioni;
• PDR;
• norme;
• dati di prodotto;
• query SQL;
• analisi;
• segnali clienti;
• connessioni tra feature esistenti e feature assenti.

Con l'IA, questo contesto diventa interrogabile.

Si possono chiedere i punti ciechi.

Confrontare opzioni.

Connettere interviste.

Identificare ricorrenze.

Generare una query SQL per verificare un comportamento nei dati.

Trasformare un'intervista in tematiche.

Connettere un dolore cliente a feature esistenti o assenti.

Costruire un ticket solo alla fine.

In questa logica, Jira o Notion diventano catene di output. Si spinge l'informazione lì quando è pronta a essere lavorata collettivamente.

Il ticket non è più il luogo dove si pensa.

È il luogo dove si spinge il risultato di un pensiero già strutturato.

Il backlog di discovery è un contenitore inadatto

Il «backlog di discovery» diventa quindi un concetto problematico.

La discovery maneggia segnali ricchi. Richiede di confrontare, connettere, analizzare, incrociare, riformulare, sintetizzare.

Un'intervista cliente non dovrebbe finire direttamente come una scheda.

Può essere trascritta. Suddivisa in temi. Connessa ai dolori. Connessa alle esigenze del cliente. Connessa alle esigenze di prodotto. Connessa alle feature esistenti. Connessa alle feature assenti. Incrociata con altre interviste. Verificata nei dati di prodotto.

Un backlog non sa fare bene tutto questo.

Una lista di schede è troppo povera per portare questo lavoro.

La discovery ha bisogno di un cervello.

Il backlog è solo uno strumento d'azione.

Certi risultati di discovery possono ovviamente finire nel backlog. Ma solo quando sono abbastanza maturi per una collaborazione strutturata.

Il backlog non deve essere il luogo dove la discovery si pensa.

Il backlog è usa e getta

Bisogna infine accettare un'idea scomoda: il backlog è usa e getta.

Un item di backlog serve fino alla consegna.

Dopo, perde gran parte del suo valore.

I ticket si desincronizzano. Le spec si desincronizzano. Le scelte cambiano durante la realizzazione. Il comportamento finale in produzione spesso differisce da quello che era stato scritto all'inizio.

L'unica realtà duratura è ciò che viene consegnato.

Il codice sorgente.

Il comportamento del prodotto.

La documentazione mantenuta a partire da quella realtà.

Questo non vuol dire che il backlog non serva a nulla. Serve a coordinare. Serve a far lavorare più persone insieme. Serve a passare da un'intenzione a un'azione.

Ma non va trattato come un archivio sacro.

Bisogna investirci il minimo di tempo utile.

Abbastanza per collaborare.

Abbastanza per agire.

Non abbastanza da produrre una documentazione che marcirà.

Il backlog non è una fonte di verità. È un supporto temporaneo di coordinamento.

Conclusione

Un buon backlog non contiene tutto ciò che l'azienda potrebbe fare.

Contiene ciò su cui è pronta a lavorare insieme.

Ciò che è immaturo resta fuori dal backlog.

Ciò che è segnale resta segnale.

Ciò che è stato rifiutato può a volte essere tracciato, ma altrove.

Ciò che appartiene alla discovery si lavora in un sistema di contesto.

Ciò che è un bug reale deve essere risolto, non immagazzinato.

Ciò che entra nel backlog deve poter avanzare verso l'azione.

Nell'era dell'IA, questa distinzione diventa ancora più importante. Il Product Manager può costruire a monte un contesto molto più ricco: fonti, interviste, note, glossari, decisioni, analisi, dati, sparring partner IA.

Il backlog resta utile.

Ma deve restare al suo posto.

Non è il cervello del prodotto.

Non è la memoria completa dell'azienda.

Non è un deposito di idee.

È uno strumento d'azione.

Per saperne di più

Zero bug: smettiamo di gestire scorte di difetti Roadmap NNL: allineare senza disperdere Perché le organizzazioni preferiscono le decisioni morbide