Lavorare con un opportunity backlog significa mantenere un elenco prioritizzato di opportunità: potenziali aree di sviluppo del prodotto che partono dalle esigenze degli utenti ancora da indirizzare. È uno strumento che, concettualmente, precede la roadmap. Serve a tenere traccia e a dare le giuste priorità ai futuri investimenti delle risorse del team di prodotto.
Differenza tra un opportunity backlog e una roadmap
Una roadmap è principalmente uno strumento utile a comunicare la strategia e gli obiettivi del team tramite una sequenza ordinata di esiti desiderabili. Benché siano dinamiche e includano iniziative che si trovano in fasi molto diverse di sviluppo, le roadmap tipicamente contengono esiti desiderabili su cui il team ha già deciso di investire. Cambi di contesto o l’emergere di nuove informazioni possono portare a modifiche, anche radicali: tuttavia, in un qualsiasi dato momento, la roadmap esplicita la strategia a medio o lungo termine per raggiungere la visione del prodotto.
Qualsiasi prodotto – che si tratti di una piattaforma complessa o di un servizio mirato – può tuttavia andare a risolvere una gamma di esigenze che è molto più ampia rispetto a quella contenuta nella roadmap. Una strategia d’altronde è anche questo: una definizione di ciò che riteniamo sia da affrontare, e ciò che invece non è attualmente rilevante. Dunque, dove tenere traccia di queste opportunità potenziali?
Ovviamente la risposta è: nell’opportunity backlog.
Quali iniziative popolano l’opportunity backlog e come organizzarlo?
Tipicamente, quando si lavora con un opportunity backlog ciascun elemento descrive un’esigenza dei nostri utenti che non è ancora stata esplorata abbastanza a fondo da poter essere correttamente inquadrata nella roadmap.
Ogni iniziativa è passibile, a un certo punto, di discovery o sperimentazione che serva a validarla ulteriormente, a stimarne meglio il potenziale o a chiarire gli assunti su cui poggia.
Come altri strumenti di product management, è fondamentale che l’opportunity backlog contenga elementi la cui priorità relativa è esplicitata. Queste priorità saranno naturalmente basate su stime preliminari e possono essere riviste con l’emergere di ulteriori informazioni. Quel che è conta rendere chiara la ragione della priorità così da poter riprendere future discussioni con il team e gli stakeholder.
Quali informazioni includere in un opportunity backlog
Non vi è una regola che dica come descrivere ogni attività. Quelli che seguono sono alcuni consigli su quali elementi possono essere utili, ma ciascun team di prodotto dovrebbe adattare lo strumento alle proprie esigenze.
- Titolo e descrizione: il titolo deve essere quanto più esplicito possibile ma sintetico abbastanza da renderlo utile come riferimento durante conversazioni o all’interno di documentazione accessoria. La descrizione è più estesa e, possibilmente, contiene anche una user story in modo da rendere esplicito il focus sull’utente.
- Obiettivi: gli obiettivi possono specificare ulteriormente come l’iniziativa impatterebbe gli utenti, e quali benefici porterebbe a livello business.
- Stima dell’impatto: qui vogliamo dare un’idea di quanto “grande” sia l’iniziativa. A questo stadio probabilmente le informazioni sono scarse, ma è necessario sforzarsi di articolare il potenziale in maniera oggettiva. Posso ache utilizzare quest’area per elencare quali sono i principali KPI che verranno impattati.
- Costo: il costo può essere suddiviso in “costi di sviluppo”, “dipendenze” e altri campi rilevanti. In questa fase un semplice t-shirt sizing è probabilmente più che sufficiente (small – medium – large). Quel che trovo particolarmente utile è dettagliare il perché ho attribuito determinate stime.
- Valore: anche il valore può essere suddiviso in vari elementi. Questi vengono determinati dalla propria strategia di prodotto e non possono dunque essere universali. Come per i costi, suggerisco stime approssimative e documentazione delle ragioni dietro alle stime.
- Fattibilità e certezza: questo campo può essere utilizzato per descrivere quanto certi siamo del valore dell’iniziativa, o se vi sono particolari aree che necessitano di approfondimento, o ancora rischi che devono essere evidenziati.
- “Perché ora”: infine, trovo utile avere un campo dove fornire un pitch sintetico sul perché l’iniziativa dovrebbe essere spostata nella roadmap. Ovviamente non tutte le iniziative devono avere un pitch, ma per quelle in cima alla lista può essere utile: è un modo per capire se le ragioni per cui queste opportunità hanno una priorità alta sono davvero chiare e facilmente spiegabili a un potenziale stakeholder.
Un esempio
Immaginiamo di essere responsabili per un sito che vende vinili online. Poiché ci focalizziamo su dischi usati, forniamo già una descrizione dello stato di usura del prodotto. Un’analisi dei competitor e di altre piattaforme suggerisce tuttavia che gli utenti potrebbero essere interessati a una separazione tra lo stato delle copertine e quello del disco in sé. Non abbiamo ancora abbastanza informazioni per sapere se valga la pena considerare questa iniziativa, dunque al momento risiede nel nostro opportunity backlog.
Il titolo è semplicemente: “Separazione informazioni usura copertina / vinile“. La descrizione è più estesa: “Attualmente ciascun articolo ha un punteggio qualità globale. Questo può essere suddiviso per descrivere separatamente la qualità della copertina e del supporto“. La descrizione può anche includere una user story: “Come utente voglio conoscere separatamente lo stato di usura della copertina e del disco così da poter acquistare in base ai criteri che mi interessano“.
Gli obiettivi: “(1) Diminuzione del tasso di reso per i prodotti con punteggio qualità basso (2) Aumento del tasso di conversione per prodotti con buona qualità del supporto ma bassa qualità delle copertine“. Nell’impatto posso fornire una prima approssimazione con le mie stime: “Il 10% dei resi è dovuto a livelli di qualità non in linea con le aspettative dell’acquirente. Quasi sempre la ragione del reso riportata è il degrado del supporto. Immaginiamo di poter ridurre l’80% di questi resi, per un calo complessivo del tasso di reso dell’8%“. Una stima simile può essere fatta per il secondo obiettivo.
Per descrivere il costo in questo suddivido in costo di sviluppo e costo di operations: “Sviluppo: M (medium) – La soluzione presumibilmente comporterà cambi relativamente semplici al database e all’interfaccia. Tuttavia l’interfaccia sarà oggetto di ricerca e la difficoltà non è facilmente stimabile a priori. Operations: M – Occorre capire se sarà necessario allineare le informazioni per tutto l’inventario esistente. Se sì, i costi di operations potrebbero salire“.
La nostra strategia prevede che ciascuna iniziativa sia valutata secondo tre criteri: (1) fidelizzazione del cliente; (2) tasso di conversione; (3) abbattimento dei costi di operations. Come per i costi, dovrò valutare ciascun area ed esplicitare perché – con le informazioni attualmente disponibili – ho assegnato quel valore. L’utilità di esplicitare le ragioni è che in tal modo si tiene traccia delle discussioni avvenute con stakeholder e resto del team, e il documento diventa più trasparente per chiunque lo utilizzi.
Quanto a fattibilità e certezza posso immaginare qualcosa lungo queste linee: “Una survey preliminare ha evidenziato che la distinzione tra qualità di copertina e disco sia tra le 3 principali priorità dei nostri clienti. Un’analisi manuale delle ragioni di contatto al servizio clienti sembra indicare altrettanto“.
Date tutte le informazioni di cui sopra, è infine possibile abbozzare un pitch di accompagnamento all’iniziativa che può essere aggiornato con il tempo. Di nuovo: è facoltativo, ma può servire come stress test per capire se le ragioni per prioritizzare l’attività siano davvero convincenti.
Da dove arrivano le iniziative da tracciare?
Le iniziative descrivono delle presunte esigenze dei clienti, in attesa di ulteriore validazione. Pertanto, molte derivano da insight raccolti in fasi di discovery precedenti, o da dati di mercato, o ancora da dati interni.
Le attività qui raccolte possono arrivare dalle fonti più disparate: ciò che è importante è rendere espliciti gli assunti sottostanti e passare sotto adeguato scrutinio le iniziative prima di spostarle nella roadmap.
Dove vanno a finire le iniziative che escono dall’opportunity backlog?
Dipende. Alcune vengono spostate sempre più in basso nella lista, e magari eliminate perché il contesto cambia o si riconosce il problema come inessenziale per la visione del nostro prodotto. Altre invece vengono trasportate nella roadmap.
Tipicamente il passaggio successivo è un’ulteriore fase di definizione del problema all’interno della quale voglio validare ulteriormente l’opportunità e, in alcuni casi, specificarla ulteriormente. Dunque spesso vi sarà un’ulteriore fase di discovery che mi permetterà di riempire i vuoti informativi che ancora caratterizzano l’iniziativa.
Devo per forza gestire un opportunity backlog?
Non è obbligatorio lavorare con un opportunity backlog. Tuttavia la domanda che resta è: dove terrai traccia degli spunti e delle opportunità non ancora pronte per essere esplorate?
Per questo scopo molti utilizzano la roadmap. Un’idea potenziale viene aggiunta da qualche parte in fondo, e lì resta – sempre scalzata da qualcosa di nuovo. Questo approccio ha vari problemi.
Innanzitutto, comunica qualcosa di impreciso. Le roadmap tendono a essere viste come un impegno che il team si è assunto verso certe iniziative. Per quanto non sia strettamente così, aggiungere opportunità ancora vaghe a una roadmap può mandare il segnale sbagliato agli stakeholder e al team.
Inoltre la revisione di una roadmap e la revisione di un opportunity backlog non procedono nello stesso modo. Le cose a cui si guarda sono di natura diversa, perché il livello di comprensione per le singole iniziative è diverso. È perfettamente legittimo che un’opportunità sia aggiornata e discussa solo saltuariamente, col sopraggiungere di informazione adeguata, se si trova in un opportunity backlog. Ma un’iniziativa in una roadmap va trattata diversamente, perché un cambio di priorità ha un impatto diretto su quel che il nostro team andrà a fare nelle settimane a venire.
L’opportunity backlog permette di gestire in maniera genuina le conversazioni con il team e gli stakeholder rispetto a quelle potenziali iniziative su cui ancora non vi è molta chiarezza, e consente di fare “intake” di richieste esterne senza aver l’immediata pressione di fornire date, priorità e risorse. Consente dunque un modo di lavorare con gli stakeholder più produttivo e intelligente rispetto allo stereotipo che voglia il product manager come quella persona che “sa dire di no”.
