Prioritizzare: framework e principi generali

Prioritizzare è fondamentale, in product management così come in ogni altro ambito lavorativo. In questo post mi limito a introdurre alcuni framework (supportati da template) e dei principi generali per la loro applicazione. Lo scopo è facilitare la prioritizzazione di feature, servizi o altre iniziative all’interno di una roadmap e di un backlog: in sintesi, definire su quali aspetti il team di developer si dovrebbe focalizzare nelle settimane o mesi a venire.

Lavorando in un team di prodotto è frequente osservare alcuni sintomi di una mancata o errata prioritizzazione, tra cui:

• Il team è impegnato contemporaneamente su troppi fronti diversi, apparentemente scollegati.
• La prioritizzazione viene completamente rivista di settimana in settimana.
• È difficile comunicare con chiarezza la logica che ha portato a lavorare su un determinato tema piuttosto che un altro.
• Vi è una sensazione diffusa di aver rilasciato molto codice ma non aver ottenuto nessun progresso concreto.

Non esiste una cura magica che possa essere riassunta in un post. Prioritizzare è complesso: ho lavorato con persone con decenni di esperienza alle spalle che, per loro stessa ammissione, non avevano una risposta semplice e univoca.

Da dove iniziare, dunque? A seguire introdurrò alcuni framework e in chiusura dei principi generali per la loro applicazione. I principi sono, a mio avviso, più importanti: partirò tuttavia dai framework perché aiutano ad ancorare il discorso su esempi concreti.

Framework

Un framework va pensato come un supporto metodologico. Le ragioni per utilizzare un framework sono varie:

• Limitare i bias: i framework aiutano a separare considerazioni oggettive e soggettive. Non rendono completamente oggettiva la prioritizzazione (un miraggio) ma aiutano a vedere più chiaramente le ragioni e i nostri bias.
• Stimolare l’approfondimento: in particolare con framework quantitativi, bisogna saper stimare i valori di determinate dimensioni. Il framework può far emergere che questi valori non sono disponibili o non sono sufficientemente affidabili.
• Facilitare la discussione: una prioritizzazione che non sia discussa e supportata da team e stakeholder può portare al disastro. I framework possono diventare un potente strumento di supporto a una discussione che, svolta in libertà, sarebbe difficile da gestire e poco produttiva.

Esistono svariati framework, ciascuno adatto in ambiti diversi. Ne introdurrò alcuni comuni e di facile applicazione. Rimando agli approfondimenti per ulteriori spunti.

---

RICE

RICE è acronimo di Reach – Impact – Confidence – Effort. È un metodo interno, ossia la cui applicazione non richiede la consultazione di esterni – ad esempio clienti – ed è tendenzialmente quantitativo. Il principio su cui si basa è l’idea di assegnare a ciascun pacchetto di lavoro un punteggio basato sul valore che produce, sul suo costo, e sulla certezza che abbiamo rispetto a questi valori. Il punteggio è calcolato come:

Le variabili da considerare sono:

• Reach: la stima del numero di utenti che saranno impattati.
• Impact: la stima dell’impatto su ciascun utente.
• Confidence: l’affidabilità delle stime.
• Effort: il numero di risorse richieste.

È importante capire come assegnare i corretti valori a ciascuna dimensione.

Reach

Voglio innanzitutto stimare quanti clienti saranno impattati dalla feature o servizio che sto valutando. Le stime devono essere compatibili: occorre dunque utilizzare un intervallo di tempo prestabilito – ad esempio un mese.

Prendiamo come esempio l’aggiunta di un teaser nella parte superiore di una home page: in questo caso il reach equivale al traffico complessivo in home page nell’arco di un mese. Infatti, ogni utente che arriva in home sarà esposto al teaser.

Se voglio invece stimare il reach di un filtro posizionato in fondo a una pagina catalogo, dovrò partire dal traffico medio mensile della pagina in questione. Essendo il filtro posizionato alla fine della pagina, devo ora stimare la percentuale di utenti che scrollano fino a visualizzarlo.

Impact

Voglio ora stimare quanto alto sarà l’impatto della feature o servizio su ciascun utente che vi è esposto. Fornire una stima precisa è estremamente difficile: è dunque una pratica comune quella di assegnare valori su una scala arbitraria e assegnarli in maniera relativa.

Ad esempio, posso scegliere una scala lineare che vada da 1 a 5, dove 1 è assegnato là dove prevedo un bassissimo impatto e 5 dove prevedo un altissimo impatto. Il limite di questa impostazione è che spesso dovrò ricorrere ad approssimazioni e gut feeling (meglio ancora: a discussioni fruttuose, come discusso più tardi nei principi generali).

Come esempio, prendo ora due cambiamenti nel checkout del mio sito. La prima feature consiste nel cambiare il colore dei call-to-action per renderli più visibili, ed evitare che gli utenti abbandonino il carrello perché frustrati dal non capire come procedere nei vari passaggi. Nella mia stima questa feature avrà un impatto molto modesto, un 1 o forse un 2 (se l’usabilità precedente era davvero terribile).

La seconda feature che valuto è l’introduzione del pagamento in PayPal. Da precedenti analisi ho visto che molti utenti abbandonano giunti alla pagina con le opzioni di pagamento; inoltre, ho varie survey a supporto della necessità di introdurre PayPal (ad esempio, mostrano che l’adoption rate di PayPal per l’utente medio del mio sito è particolarmente alta). Nella mia stima, questo è un chiaro 5.

Per limitare l’arbitrarietà di queste stime vi sono alcune buone pratiche:

• Documentare esempi di cosa si considera essere un 1 e un 5 (possibilmente anche gli intermedi) e rifarsi a questa documentazione durante le discussioni. Immaginiamo di dover stimare l’impatto di una funzione di auto-completamento dell’indirizzo di fatturazione durante il checkout. Dalla mia documentazione so di aver assegnato 5 all’introduzione di un nuovo metodo di pagamento; 1 al cambio di colore di una call-to-action; 2 all’opzione per usare l’indirizzo di fatturazione anche come indirizzo di consegna (senza doverlo inserire due volte). La feature che sto stimando è indicativamente simile, come impatto sull’usabilità, a quella precedentemente valutata 2: di conseguenza 2 potrebbe essere una buona stima.
• Individuare i casi limite: una volta che è chiaro qual è un chiaro esempio di basso impatto (1) e uno di alto impatto (5) diventa più facile stimare tutti gli altri casi in maniera relativa rispetto a questi.
• Don’t to it yourself: l’assegnazione dell’impatto è l’esempio perfetto di elemento da discutere con il team e/o con gli stakeholder. Il product manager può avere più peso (specialmente là dove ha ampia ricerca documentabile con cui sostenere una stima) ma è importante cercare di raggiungere una comprensione coerente dell’impatto di una feature. Se il product manager stima un 1, la controparte commerciale un 3 e il nostro principale stakeholder un 5… ottimo: state per iniziare la conversazione più fruttuosa della vostra giornata.
• Andare a caccia di dati: riprendo ora l’esempio del cambio di colore di un pulsante. È stato fatto qualcosa di analogo in passato? Vi sono A/B test al riguardo? Di quanto è cambiata la click through rate in quei casi? Questo potrebbe essere un buon punto di partenza. Se voglio introdurre un nuovo metodo di pagamento, dati sul suo utilizzo nel mercato dovrebbero essere ampiamente disponibili, e user interview o survey con il mio target forniranno altri dati utili.

Confidence

È inevitabile che le nostre stime non siano perfette. In particolare, come ho descritto appena sopra, l’impatto è una variabile che si presta ad approssimazioni.

Per questa ragione, RICE utilizza il livello di attendibilità all’interno della formula: l’attendibilità sarà più bassa là dove non ho molti dati per sostenere le mie valutazioni, e di conseguenza il punteggio finale sarà più basso.

L’attendibilità può essere espressa come percentuale: per semplificare tendo ad utilizzare scale come 25% (bassissima confidenza) – 50% (alta incertezza nei dati) – 75% (alcuni insight mancano ma la stima è buona) – 100% (totale fiducia nelle stime).

Se ho eccellenti dati di traffico per stimare il Reach di una feature, e conosco bene il potenziale impatto perché supportato da survey, user interview e altre feature simili rilasciate in passato, posso chiaramente assegnare un 100%. Se sto proponendo un cambiamento radicale – ad esempio l’introduzione di un nuovo onboarding per gli utenti che si sono appena registrati – ma non ho ancora fatto sufficiente ricerca, potrei immaginare di assegnare un forte Impact ma una Confidence del 25%.

Effort

Qual è il costo in termini di risorse umane per sviluppare la feature o il servizio in questione? Vi sono altri “costi nascosti”, quali ad esempio lunghe contrattazioni con un team dal quale dipendo per poter procedere?

Anche in questo caso è utile procedere per t-shirt sizing o simili: 1 per un costo molto basso e 5 per un costo alto. A differenza dell’impatto, posso ancorare questi numeri a dati più concreti: ad esempio, posso chiedere al team di developer di assegnare una stima in termini di risorse per lo sviluppo. Una feature che, si stima, impiega 3 giorni di un developer potrebbe essere un 1; una feature che ne impiega 28 (o due settimane di due developer) potrebbe essere un 5.

Queste stime possono essere riviste nel corso del tempo, man mano che il team di sviluppatori passa dalle varie fasi di refinement e capisce meglio quali sono le difficoltà dei task sottostanti.

Per semplificare si può limitare questa stima ai costi di risorse per lo sviluppo. Il mio consiglio è di considerare qualsiasi effort accessorio solo se chiaro e rilevante.

Calcolo dei punteggi

Come accennato, una volta che ho le mie stime sottomano il punteggio finale è dato dalla semplicissima equazione espressa sopra (moltiplico R, I e C, infine divido per E). La tabella finale potrebbe essere qualcosa come quella che segue:

In questo caso, il modello suggerisce che il teaser in home page è il pacchetto di lavoro a cui dare priorità. Nonostante l’introduzione di un nuovo metodo di pagamento potrebbe avere un impatto molto maggiore, e sebbene sia più certo dei dati a disposizione, il teaser in HP avrebbe molta più esposizione e potrebbe avere un impatto complessivo maggiore a fronte di un costo di sviluppo molto minore.

Come spiegherò dettagliatamente nei principi generali, questo non mi porterà automaticamente a prioritizzare la feature ma sarà una delle indicazioni principali da utilizzare in fase decisionale.

Vantaggi e svantaggi del modello RICE

RICE ha dei limiti:

• Può portare a un’eccessiva semplificazione. Per questo tendo, in generale, a preferire un metodo più complesso – weighted scoring o scorecards – di cui parlerò dettagliatamente in un post differente.
• Come tutti i metodi quantitativi, può generare un eccessivo senso di fiducia nella presunta oggettività delle conclusioni. Occorre sempre maneggiare le stime per ciò che sono e ricordarsi che i numeri possono diventare uno strumento in cui proiettiamo i nostri bias.
• Non si presta a comparare iniziative dal carattere molto differente. Se dovessi trovarmi a prioritizzare risorse per progetti di natura e target molto diversi fra loro propenderei per framework più flessibili.

Di converso, il modello RICE è un eccellente supporto per svariati usi. Grazie alla sua semplicità non ci si perde nei meandri delle stime, ed è di immediata applicazione per backlog molto omogenei (ad esempio: le feature di un unico prodotto) dove vi è abbondanza di disponibilità di dati sul traffico (storico o potenziale).

---

Opportunity Scoring

Opportunity scoring è un metodo derivato dall’approccio ODI – Outcome Driven Innovation. A differenza di RICE richiede un contributo esterno: nello specifico, si basa su input forniti dagli utilizzatori o clienti del prodotto. Il metodo ha un fondamento quantitativo – dei punteggi che i clienti interpellati attribuiscono a determinati outcome – ma in un ideale spettro che va dal puramente qualitativo al puramente quantitativo si colloca nel mezzo.

Si basa su un’idea: benché l’utente non sia una buona fonte di soluzioni (mantra del Product Management), può tuttavia fornire indicazioni preziose rispetto agli esiti (sopra definiti outcome) che si aspetta. Prima di proseguire nella descrizione del framework è importante capire concretamente questa distinzione.

Esiti e soluzioni

Un trapano è una soluzione: un buco nel muro è un esito intermedio. Una mensola sul muro è un esito. Chi desidera un buco nel muro per appendervi una mensola non deve necessariamente acquistare un trapano e potrebbe avere a disposizione altre soluzioni. Ad esempio, pagare un professionista per provvedere a montare la mensola.

In maniera analoga, introdurre PayPal come metodo di pagamento è una soluzione. Un esito desiderabile è, ad esempio, essere in grado di effettuare un acquisto online senza dover avere i dati della carta di credito sottomano.

Nell’applicare opportunity scoring partirò da una lista di esiti: questi tipicamente sono definiti in una fase di product discovery – non oggetto di questo post. In breve, so che gli esiti che ho mappato sono esiti desiderabili per il mio target, ma voglio stabilire quali hanno una maggiore rilevanza.

Per l’esempio che segue immagino lo sviluppo di un’applicazione che permette agli utenti di pianificare le proprie vacanze. Gli esiti mappati durante la fase di discovery sono i seguenti:

• Possibilità di archiviare in un unico spazio virtuale tutti i biglietti, conferme di prenotazione e altri documenti rilevanti per il viaggio.
• Semplicità nel comparare prezzi e servizi tra assicurazioni di viaggio disponibili per la meta desiderata.
• Possibilità di scambiare esperienze con altri utenti che abbiano già trascorso vacanze nella meta desiderata.

Ora che ho la lista di esiti, posso passare alla fase di assegnazione del punteggio.

Scoring

Opportunity scoring significa ridurre ogni esito a un punteggio (opportunità) che ne riassume l’importanza e il livello di soddisfazione attuale dal punto di vista del cliente.

Il primo passo è mettere insieme un campione di clienti per poi raccoglierne i riscontri tramite un questionario. Per ciascun esito queste sono le due domande a cui ciascun cliente deve dare una risposta:

• Importanza: quanto è importante [l’esito in questione]? (1: per nulla; 5: molto)
• Soddisfazione: quanto sei soddisfatta [di come il servizio / prodotto attualmente soddisfa questa necessità]? (1: per nulla; 5: molto)

Supponendo di aver ottenuto 200 risposte al mio questionario, proseguo con il contare il numero di punteggi attribuiti per entrambe le dimensioni e a calcolare i due valori che utilizzerò nella formula finale:

In questo caso, ad esempio, il terzo esito considerato (scambiare opinioni con altri utenti) ha un’importanza piuttosto alta (58) ma un livello di soddisfazione molto basso (8). Come sono arrivato a questi due numeri? Il punteggio finale è il rapporto tra rispondenti ad avere attributo una valutazione di 4 o 5 all’esito in questione (sopra in blu) e il totale dei clienti che hanno fornito una risposta. Nel caso dell’importanza del terzo esito, 116 rispondenti (62+54) su un totale di 200.

Finalmente è il momento di calcolare l’opportunity score per ciascun esito. La formlua è semplice:

Opportunity score = Importanza + (Importanza – Soddisfazione)

Cosa dice questa formula? In sintesi, che le nostre priorità devono essere centrate là dove gli utenti percepiscono un alto valore e un alto gap (lacuna) tra il valore percepito e l’attuale offerta. Questo è il risultato:

Posso facilmente interpretare i valori ottenuti. Il secondo esito ottiene il punteggio più basso: non è di particolare importanza per gli utenti, a fronte di un’offerta discreta. Non occorre dunque investire ulteriormente nello sviluppo di soluzioni mirate. Di converso, il terzo esito ha un alto valore percepito ma al momento il mio prodotto non offre soluzioni sufficientemente soddisfacenti. È qui che dovrò concentrare gli sforzi del team. Il primo esito ha infatti un valore percepito più alto ma è al contempo ben servito dalle attuali soluzioni.

Tipicamente è possibile visualizzare graficamente lo stato del prodotto tramite un grafico a dispersione delle due variabili Importanza / Soddisfazione:

Il grafico è diviso in tre aree. L’area evidenziata in verde è quella dove ricadono gli esiti che sono appropriatamente serviti dal prodotto. L’area in alto a sinistra contiene gli esiti che eccessivamente serviti rispetto al valore percepito (aree dunque dove potenzialmente possono identificare opportunità di taglio dei costi). Infine, l’area in basso a destra è quella dove voglio focalizzarmi: esiti il cui valore percepito è alto e il livello di soddisfazione non sufficiente.

Vantaggi e svantaggi dell’Opportunity Scoring

Partendo dai limiti del metodo:

• Come tutti i metodi che richiedano un contributo esterno, è dispendioso in termini di risorse: preparare i questionari, trovare il panel di clienti, gestire la comunicazione e la raccolta dati sono tutte operazioni che richiedono tempo. Inoltre, considero i feedback dei clienti una risorsa essenziale ma spesso scarsa (nel senso di poco disponibile): voglio dunque sempre essere sicuro che, avendo l’opportunità di raccogliere un riscontro, lo sto facendo per l’attività più utile.
• È fondamentale separare bene esiti e soluzioni. Non chiedere agli utenti di valutare soluzioni (o meglio: non in questa modalità). Concentrati sugli esiti e rimanda in seguito il processo per identificare le soluzioni da adottare per ottenerli.

Quest’ultimo è l’aspetto che può trasformare il modello in uno strumento importante nella gestione di un prodotto: viene reiterata l’idea che i prodotti creano valore per l’utente in quanto le permettono di raggiungere i propri obiettivi, e non in quanto somma di funzionalità da valutare in maniera decontestualizzata.

Se questa è una direzione utile per la gestione del tuo prodotto, un altro modello interessante da considerare è KANO, di cui scriverò in futuro.

---

Buy a feature

Il terzo e ultimo supporto alla prioritizzazione che voglio descrivere è noto come Buy a feature (acquista una funzionalità). Anche in questo caso è richiesto il contributo del cliente / utente / stakeholder, e l’approccio è meno quantitativo dei precedenti.

Tuttavia, è il metodo più coinvolgente tra quelli descritti, e può costituire lo spunto per delle conversazioni da cui possono emergere insight qualitativi essenziali.

Le regole

Buy a feature può essere pensato come un vero e proprio gioco. Può essere svolto da ciascun utente in maniera individuale, oppure a gruppi in maniera collaborativa. I passi sono i seguenti:

• Innanzitutto devo raccogliere una lista di funzionalità che voglio presentare agli utenti. La metodologia si presta bene a far valutare vere e proprie soluzioni, ma anche in questo caso è possibile presentare invece degli esiti desiderabili.
• Ogni acquirente ha un budget spendibile per acquistare una o più funzionalità. Il budget di ciascun utente deve essere compreso tra un terzo e metà del costo complessivo di tutte le funzionalità.
• Ogni volta che un acquirente decide di acquistare una funzionalità, raccolgo l’equivalente del costo e chiedo di spiegare le ragioni dell’acquisto.
• Se l’acquirente ha speso tutti i soldi, o se ha comprato tutte le funzionalità a cui è interessato, il gioco finisce. Non è necessario che l’acquirente spenda tutti i soldi a disposizione.

Modalità individuale o modalità collaborativa

Entrambe le modalità sono utili. La modalità individuale permette di raccogliere un maggior numero di riscontri con un minore sforzo. Consente inoltre di raccogliere le prime impressioni dell’utente, senza condizionamenti da altri partecipanti.

La modalità collaborativa prevede che vanga impostata una lista di prezzi tale che i partecipanti debbano mettere insieme i propri budget per poter acquistare determinate funzionalità. Limita il numero di riscontri che posso raccogliere ma obbliga gli utenti a negoziare tra loro. Questo è estremamente importante perché forza il dibattito tra i partecipanti e può fare emergere nuovi insight.

Vantaggi e svantaggi di Buy a feature

Partendo dai limiti:

• Si tratta di un approccio qualitativo. Non vi è nulla di male né di sbagliato negli approcci puramente qualitativi: tuttavia, in ambito di prioritizzazione è importante contestualizzarne correttamente i risultati quando vengono presentati a chi ne ha poca familiarità.
• Richiede buone capacità di moderazione. I partecipanti devono capire esattamente cosa viene loro richiesto ed è importante che chi modera sappia facilitare e incoraggiare la riflessione, la spiegazione delle ragioni dietro alle varie scelte, e la negoziazione nel caso di modalità collaborativa.

Buy a feature è un ottimo modo per ottenere degli insight qualitativi rispetto alle soluzioni che vogliamo implementare (o agli esiti che vogliamo rendere possibili): trovo che questo sia il valore principale della metodologia, ben al di sopra dell’enumerare le funzionalità più scelte. Ovviamente anche questo ha una sua importanza, ma in ultima analisi vi troverete a dover motivare le scelte della vostra prioritizzazione: comprendere le motivazioni dell’utente è ciò che davvero permette di creare prodotti che generino valore.

Naturalmente, il fatto che il metodo abbia un elemento di gioco è utile a renderlo più coinvolgente e a ottenere migliori risultati.

Se l’approccio è valido per il tipo di prioritizzazione che volete svolgere, suggerisco di considerare un metodo simile noto come Speed Boat: anche in questo caso il metodo è coinvolgente per i partecipanti e permette di ottenere insight qualitativi. La sua peculiarità è che viene tipicamente utilizzato per capire quali sono le funzionalità meno utili o meno apprezzate in un prodotto.

---

Principi generali per l’applicazione di un framework

Un framework è un supporto. Non è una soluzione magica. Prioritizzare è estremamente complesso e non è un’attività riducibile a pochi passaggi automatici. Per poter realmente estrarre del valore dall’applicazione di un framework occorre applicarlo tenendo presenti dei principi generali.

Rifletti su come misurare l’impatto

Metodologie quantitative, ma in certa misura anche qualitative, richiedono quasi sempre di fornire una qualche forma di stima dell’impatto di un esito o di una soluzione. Nell’esempio che ho presentato sopra mi chiedevo: quanto alto sarebbe l’impatto di introdurre un nuovo metodo di pagamento?

Il problema è che impatto vuol dire tutto e niente finché non sono in grado di rispondere alla domanda: qual è una buona misura dell’impatto? Spesso questo si può tradurre in: quali KPI (Key Performance Indicator – indicatori di performance) mi aspetto che siano impattati da una determinata soluzione?

La scelta dei KPI corretti è a sua volta un tema complesso che richiede una trattazione separata. Tuttavia, si può dire che in linea di principio mi aspetto che:

• I KPI che misuro nel mio prodotto siano coerenti tra di loro.
• So individuare dei KPI fondanti che si collegano alla mia strategia: ad esempio, nel perseguire una strategia che punta ad avere acquisti ripetuti dei clienti potrei guardare alla crescita nel numero di clienti che visitano il mio sito due o più volte alla settimana.
• So individuare dei KPI specifici per le funzionalità che sto analizzando e che al contempo contribuiscano ai KPI fondanti di cui sopra.

Prendi decisioni data informed, non data driven

Vi sono svariate ragioni per cui nessun metodo quantitativo può esaurire completamente tutto quel che vi è da dire sulla prioritizzazione di un backlog: dipendenze, importanza di ripagare il debito tecnico, imperfezioni del modello applicato, considerazioni strategiche, …

Questo tuttavia non vuol dire che gli esiti dell’applicazione di un framework vadano ignorati. Sono un punto di partenza importante (e in certi casi possono essere il punto di arrivo).

I dati devono informare il processo di prioritizzazione e rendere più solide le tue scelte. Non possono però sostituirsi alla discussione e a una visione olistica del prodotto.

La domanda “perché avete scelto di allocare le vostre risorse su questa funzionalità” non può avere come risposta “perché nel modello RICE è quella con il punteggio più alto”. Bisogna saper spiegare come cambierà l’esperienza del prodotto per il cliente, perché questo è importante sulla scorta di quel che sappiamo del nostro target, come si collega alla visione e strategia complessive, perché non è in contraddizione con lo stato tecnico del prodotto o con le aspettative dei nostri stakeholder. Prioritizzare è complesso.

Convolgi gli stakeholder

Immagina questo scenario: a un meeting con gli stakeholder viene presentata una roadmap di breve termine. Gli stakeholder sono colti di sorpresa e hanno molte riserve sulle scelte fatte. Il product manager orgogliosamente invita a non preoccuparsi e mostra la tabella RICE dalla quale sono state derivate le priorità illustrate nella roadmap.

Vi sono mille problemi con questo scenario, tutti risolvibili partendo da un altro approccio: gli stakeholder devono essere coinvolti nel processo di prioritizzazione. Non saranno loro a stabilire le priorità, non è questo il punto: al di là di mere ragioni di gestione degli stakeholder, il punto principale è il valore intrinseco nel raccogliere i loro spunti e dubbi.

Se stiamo pensando di introdurre un nuovo metodo di pagamento, il dipartimento frodi potrebbe avere parecchio da dire sulla nostra stima dell’impatto. Ha senso, ad esempio, introdurre le loro stime sull’aumento dei costi nell’equazione. Il modo migliore per non scoprirlo all’ultimo? Coinvolgerli nel processo.

Un processo di prioritizzazione ha senso solo se è costruito intorno a una discussione (vedi sotto) e questa discussione deve necessariamente coinvolgere gli stakeholder.

Non tralasciare il debito tecnico

O meglio: non tralasciare gli aspetti essenziali dello sviluppo di un prodotto che non sono direttamente mappati nel backlog.

Una delle principali ragioni di frustrazione di un team di sviluppatori è spesso la noncuranza dei product manager verso temi quali lo sviluppo dell’infrastruttura o il colmare debito tecnico accumulato in precedenza. E hanno ragione da vendere a essere frustrati.

Mappare queste attività in una lista di prioritizzazione è difficile perché sono eterogenee e difficilmente comparabili con attività volte a creare un impatto diretto sul cliente. Una pratica comune è destinarvi una quota fissa di risorse (ad esempio, 20% del tempo di sviluppo in ogni sprint / ciclo): non è la soluzione che trovo migliore, ma è semplice e previene il rischio di ignorare questi temi.

In generale, se occorre destinare risorse a un’attività prettamente tecnica si deve essere in grado di motivare il perché, così come per ogni altra attività. Spiegare il contesto, il valore che l’attività crea (tagliare i tempi di sviluppo, ridurre rischi generali o di sicurezza, preparare il terreno per future migrazioni, …), le conseguenze del non lavorarci ora.

Ignorare debito tecnico o altre necessità infrastrutturali può avere conseguenze severe nel medio e lungo termine. Per gli sviluppatori, saper articolare il perché non è sempre semplice. Ritengo sia responsabilità del product manager essere in grado di capire il (giusto) valore di queste attività e fare da ambasciatore perché vengano correttamente posizionate all’interno della roadmap.

Facilita una discussione aperta

Un product manager sa facilitare la comunicazione tra programmatori, stakeholder, controparte commerciale e altri team di prodotto.

Le conversazioni che sorgono intorno a un processo di prioritizzazione sono tra le più importanti e fruttuose che si possono avere intorno al prodotto. Gli elementi intorno a cui ruota la prioritizzazione sono infatti anche gli elementi cardine di un ciclo di sviluppo del prodotto: nel momento in cui ne viene discussa l’importanza, è naturale che emergano dei punti di discordanza che sarebbero altrimenti rimasti sommersi fino ad arrivare a una fase molto più avanzata di sviluppo.

Tutto ruota intorno a una domanda: perché?

Un backlog e una roadmap non sono statici. Le priorità vanno ristabilite ogni volta che emergononuovi elementi rilevanti – si tratti di nuovi dati, nuovi competitor, cambi di direzione strategica o altro ancora. Una buona prioritizzazione aiuta a stabilire quali siano gli elementi più importanti su cui focalizzarsi alla luce di quanto è dato conoscere al momento: se vi è una ragione per un cambio improvviso nelle priorità, è importante avere la lucidità di richiedere tale cambiamento.

Un framework non ti proteggerà dalle mille domande che pioveranno nel caso di un cambiamento nelle priorità, ma potrebbe aiutarti a contestualizzare la risposta alla domanda più importante: perché? Saper articolare con precisione le ragioni di tali scelte è essenziale: il ruolo di un framework, spesso, è quello di aiutare a delimitare cosa è rilevante e cosa non lo è. E se a volte le tue ragioni non sono direttamente riconducibili a ciò che il framework suggerisce, è perché lo stai utilizzando correttamente: come un supporto, e non come una tavola della verità.