6 Modi per Dare Priorità alle Funzionalità di Prodotto (+ Consigli ed Esempi)
Se mi chiedete, due delle competenze più importanti nella gestione dei prodotti sono conoscere le proprie priorità e dire "No."
Oggi ci concentreremo in profondità sul primo punto (il secondo merita una guida a parte) e vi aiuteremo a dare priorità al vostro lavoro mantenendo tutti allineati con le vostre priorità.
Una Nota Importante sui Framework di Prioritizzazione delle Caratteristiche di Prodotto
Prima di iniziare a esplorare i modi per dare priorità al vostro backlog, c'è un consiglio importante che devo condividere con voi.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
I framework di prioritizzazione non devono essere presi alla lettera.
No, non è necessario utilizzarlo esattamente come è scritto nel libro (o in questa guida). Il prodotto che gestite potrebbe essere completamente diverso da quelli dei quali l'autore si occupava quando ha scritto il suo libro. Prodotti diversi significano realtà ed esigenze diverse. Quindi, è assolutamente normale adattare il framework alle proprie necessità. Dopotutto, un buon framework è quello che funziona per voi.
Framework di Prioritizzazione del Prodotto da Provare
Sapevate che esiste un framework di prioritizzazione Thanos? Basta eliminare casualmente metà di tutte le funzionalità nel vostro backlog!
Bene, l'ho inventato io. Ma avete capito il mio punto di vista. Ci sono davvero troppi framework là fuori. Così tanti che sicuramente non riuscirò a coprirli tutti in questa guida. Per essere sinceri, non credo neanche che siate qui per memorizzare un milione di framework.
Quindi, invece, vi illustrerò quelli che ho usato personalmente nel mio lavoro quotidiano di gestione del prodotto e vi condividerò alcuni consigli pratici per ciascuno. Vale anche la pena considerare come si potrebbe utilizzare l'IA nella prioritizzazione delle funzionalità insieme a questi framework.
1. Modello Kano
Questo metodo di prioritizzazione prende il nome dal talentuoso scrittore e consulente gestionale giapponese Noriaki Kano. La bellezza del suo approccio sta nella semplicità.
Quello che Kano suggeriva di fare è classificare le funzionalità in questi gruppi:
- Must-be: Queste sono le caratteristiche di base del vostro prodotto e la loro assenza creerà una cattiva esperienza per il cliente (cattiva retention e abbandono sono assicurati). Un buon esempio è la chat in Intercom o la ricerca del feedback clienti in G2.
- Performance: Queste funzionalità creano valore per l’utente in base alla loro quantità. Più ce ne sono, più valore si genera. Pensate ad esempio alla capacità/autonomia della batteria di un’auto elettrica moderna. Una migliore autonomia (generalmente) crea più valore per i conducenti. Un altro esempio è il numero di integrazioni in Zapier.
- Attractive: Invece di aggiungere valore diretto o risolvere dolori degli utenti, queste funzioni puntano a migliorare l’attrattività dei vostri prodotti. Ad esempio sezioni di visione di prodotto ben progettate in uno strumento di project management o i sedili in pelle in una vettura.
Se dovessimo visualizzare la relazione tra prevalenza di questi tipi di funzionalità e la soddisfazione dei clienti che creano, sembrerebbe qualcosa del genere.
Qui possiamo vedere che le funzionalità di tipo "performance" sono lineari nella loro natura (di conseguenza, più ne hai più valore ottieni). Le funzionalità "must-be", invece, non generano molto valore aggiuntivo. Sono pensate piuttosto per eliminare l’insoddisfazione degli utenti.
Infine, la categoria "attractive" serve a dare una spinta aggiuntiva alla soddisfazione. Ma avrà effetto zero se avete sbagliato con una delle vostre "must-be".
Kano nella pratica
Come si applica il modello Kano nella vita reale? Dalla mia esperienza, il modello Kano viene raramente utilizzato in incontri di prioritizzazione o brainstorming. Il motivo è che si tratta di qualcosa di molto intuitivo e non è necessario disegnarlo sulla lavagna e chiedere alle persone di classificare le funzionalità in base a queste tre categorie.
Piuttosto, il più delle volte si insegna agli stakeholder a pensare secondo la logica Kano. Così, prima di venire da voi con una nuova richiesta di funzionalità, la passeranno mentalmente attraverso questo schema e decideranno se vale la pena approfondirla o meno.
In questo modo, delegherete parte del lavoro di prioritizzazione delle funzionalità ai vostri stakeholder e risparmierete tantissimo tempo su lunghe sessioni di brainstorming.
2. Metodo MoSCoW
Il metodo MoSCoW è tra i metodi più popolari per prioritizzare le funzionalità. La sua diffusione è data da due fattori: semplicità ed efficacia.
Per applicare questo metodo, tutto ciò che dovete fare è osservare ciascuna funzionalità della vostra lista e attribuirle una di queste quattro priorità:
- Da avere assolutamente
- Da avere preferibilmente
- Potrebbe avere
- Non avrà
Di solito assegni queste priorità in base a una combinazione di fattori, tra cui il valore creato per gli utenti, il valore di business, l’allineamento strategico, la complessità di implementazione e altri.
Ecco come apparirà una tipica lista di funzionalità per un servizio di streaming musicale applicando il metodo MoSCoW.
- Qui, abbiamo assegnato alla modalità offline la priorità “da avere assolutamente” considerando che molti dei nostri utenti ascolteranno musica a bordo di un aereo.
- Le esperienze in VR, invece, hanno avuto la priorità “non avrà” perché sono piuttosto difficili da implementare e pochissimi utenti possiedono visori VR per poterle sfruttare.
MoSCoW nella vita reale
Sebbene tu possa usare perfettamente MoSCoW per gestire le tue riunioni di prioritizzazione, c’è uno svantaggio che lo rende meno efficace in certi casi.
Poiché la priorità si basa su una combinazione di molti fattori, ogni membro del team impiega abbastanza tempo a spiegare le ragioni dietro le proprie decisioni di prodotto. Dalla mia esperienza, le sessioni MoSCoW sono piuttosto lente e inefficaci rispetto ad altri framework.
Ma questo non significa che non mi piaccia MoSCoW. In realtà, è il framework che uso più spesso. Il mio uso preferito di MoSCoW è nella lista di funzionalità di un PRD.
Di solito, fornisco ai lettori il contesto relativo al valore per l’utente, le complessità tecniche e altri fattori nel documento prima di procedere alla lista delle funzionalità. Così, quando vedono "da avere assolutamente" a fianco di una di esse, hanno il contesto per capire velocemente la logica della mia scelta.
In questo modo, MoSCoW mi permette di ottenere una lista di funzionalità facilmente comprensibile in un documento dei requisiti di prodotto.
3. Metodo RICE
A differenza dei due metodi precedenti, il modello di punteggio RICE è un po’ più strutturato e meno basato su decisioni guidate dall’intuizione. Identifica quattro fattori distinti per la prioritizzazione e permette di quantificare e valutare separatamente ognuno di essi. Questi fattori sono:
- Reach: rappresenta la quota di utenti che questa funzionalità coinvolgerà.
- Impact: l’entità dell’impatto stesso.
- Confidence: mostra se sei sicuro che le persone raggiunte riceveranno davvero quell’impatto.
- Effort: è il tempo necessario al team di sviluppo e prodotto per rendere pronta questa funzionalità.
Di solito, si sceglie una funzionalità e poi si assegna un punteggio da 0 a 10 per ciascuno di questi quattro fattori. Poi si calcola il punteggio RICE con questa formula.
Infine, ordini la tua lista di funzionalità in base alla metrica principale di questo framework: il punteggio RICE (punteggio più alto = priorità più alta). Ecco come appare il risultato di una prioritizzazione con RICE.
- In questa lista si nota che la nuova interfaccia utente ha ottenuto il punteggio più alto grazie al suo basso sforzo e all’ampio reach/impact.
- La funzione Cloud Sync, invece, si trova in fondo alla lista a causa dell’alto impegno necessario per implementarla da parte del team.
RICE nella vita reale
Continuo a ripetere che sia MoSCoW che Kano non sono le migliori soluzioni per riunioni di prioritizzazione e brainstorming. Ma quale framework uso in questi casi? Il RICE!
Attribuendo un punteggio separato a ciascun fattore, diventa più semplice per le persone spiegare la logica delle proprie decisioni durante queste riunioni (aspetto che manca nel metodo MoSCoW). Inoltre, puoi delegare la valutazione di ciascun fattore ai membri più esperti in quella specifica area.
Per esempio, il tuo team di sviluppo prodotto è il più qualificato per dare il punteggio relativo allo sforzo. I tuoi analisti di dati, invece, hanno la migliore comprensione di quanto potrebbe essere ampio il reach di quella funzionalità.
4. User Story Mapping
Tecnicamente, User Story Mapping non è un framework di prioritizzazione. Viene invece utilizzato per organizzare il lavoro da svolgere per il tuo team e individuare eventuali funzionalità da aggiungere per avere percorsi utente completi.
Per costruire una story map, elencherai le principali attività (o lavori) dell’utente e poi scriverai i compiti che gli utenti devono completare per ciascuna di esse. Successivamente, elencherai tutte le funzionalità che devi sviluppare per permettere agli utenti di completare questi compiti. Puoi farlo con post-it su una lavagna oppure utilizzare uno dei tanti strumenti per product manager dedicati.
Ecco come appare la mappa per un servizio di streaming musicale.
Probabilmente, a questo punto non farai molta prioritizzazione.
Tuttavia, il processo di annotare le funzionalità necessarie per ogni attività ti aiuterà comunque con la prioritizzazione, poiché ti renderai conto che mancano delle funzionalità per alcune attività (che sono una priorità per te).
A quel punto, aggiungerai rapidamente queste funzionalità mancanti al tuo backlog e le sposterai in cima per assicurarti di aver coperto con successo quella specifica attività per i tuoi utenti.
Nell’esempio sopra, abbiamo una story map MVP in sviluppo attivo (le storie concluse hanno il segno di spunta accanto al nome). Guardandola, possiamo vedere che l’attività di Gestione Account è incompleta poiché non abbiamo ancora implementato l’accesso tramite i social media.
Quindi, prima di iniziare a lavorare sulla ricerca di artista/album, dovremmo prima completare l’attività di gestione account.
Story maps nella vita reale
Proprio come RICE, le story map sono perfette per le tue riunioni di prioritizzazione e brainstorming. Uno dei principali benefici di questo framework è la capacità di portare la prospettiva dell’utente all’interno della sala riunioni.
Esaminando le attività e i compiti dell’utente, i membri del tuo team saranno meno propensi a proporre idee di funzionalità irrilevanti per le esigenze e i problemi dei clienti. Anche se dovessero proporle, potrai facilmente assegnare loro una bassa priorità, considerando che queste funzionalità non aiutano gli utenti a completare i loro compiti.
5. Opportunity scoring
Strutturalmente, Opportunity scoring è simile a RICE. Tuttavia, a differenza della sua controparte, i criteri nel sistema di Opportunity scoring non sono scolpiti nella pietra e spetta a te sceglierli.
Per allineare la tua roadmap di alto livello con la leadership, ad esempio, potresti considerare l’adattamento alla strategia di prodotto, la fattibilità e il potenziale ricavo come criteri. Ecco come appare una roadmap prioritarizzata con questo framework.
Qui, abbiamo utilizzato una scala 0-5 per valutare ciascun fattore e calcolato la somma di tutti i fattori per ogni elemento della lista.
Scorecard nella vita reale
Considerando la flessibilità nella scelta dei criteri, le scorecard sono perfette per le riunioni di allineamento tra team.
Ad esempio, se devi allineare la tua roadmap con i team legali e di sicurezza e ascoltare il loro punto di vista sulle priorità, puoi scegliere criteri che siano rilevanti per loro (es. rischio legale vs valore per il business). Con il team marketing, invece, potresti utilizzare come criteri sforzo, costi, allineamento agli obiettivi aziendali, copertura di mercato e livello di fiducia.
6. Matrice dell’effort
Ricordi la matrice di Eisenhower, utilizzata per dare priorità alle tue iniziative personali? Bene, la matrice dell’effort è una versione più adatta a lavorare con nuove funzionalità di prodotto.
Il nome completo è Matrice Valore vs Effort, poiché consente di visualizzare la relazione tra questi due fattori per ciascuno dei tuoi compiti. Ecco come appare.
Posizioni l’effort sull’asse Y e il valore per il cliente sull’asse X. Successivamente, come nella matrice di Eisenhower, la dividi in 4 quadranti e inserisci le tue funzionalità a seconda del loro valore e sforzo richiesto. Dopodiché, prioritizzi i tuoi compiti nel seguente ordine:
- Quick Wins (funzionalità ad alto impatto che puoi realizzare subito)
- Big Projects (le tue funzionalità strategicamente più importanti)
- Fill-ins (potenziali funzionalità di facile realizzazione da considerare più avanti)
Per le funzionalità nel quadrante delle "perdite di tempo", di solito le scarterai poiché non ha senso averle nel backlog.
Matrice dello Sforzo nella Vita Reale
Sia il principale vantaggio che lo svantaggio di questo framework risiedono nella sua semplicità.
È un vantaggio, poiché puoi facilmente spiegare il processo di prioritizzazione alle persone presenti e iniziare immediatamente a selezionare le funzionalità giuste.
Lo svantaggio è che la matrice dello sforzo non mostra i diversi fattori che giocano un ruolo importante nella prioritizzazione (fiducia, portata, dipendenze, ecc.).
Quindi, il miglior caso d'uso per questo framework sono brevi riunioni di allineamento dove i dettagli non hanno importanza (dato che di solito avrai una sessione più approfondita utilizzando RICE come seguito).
Allinea i Tuoi Stakeholder con la Roadmap del Tuo Prodotto
Prioritizzare il tuo lavoro è importante. Ma non avrà valore se non hai allineato tutti rispetto alle tue priorità. Molti dei framework di cui abbiamo parlato oggi sono di natura collaborativa e ti aiutano ad ottenere automaticamente l'allineamento.
Tuttavia, se decidi di scegliere quello che non richiede di radunare tutti i tuoi stakeholder nella stessa stanza, assicurati allora di aver condiviso la tua lista delle priorità con le persone interessate e di averla allineata alle loro aspettative e esigenze.
Non dimenticare di iscriverti alla nostra newsletter per ulteriori risorse e guide sul product management, oltre a podcast, interviste e altre novità da leader ed esperti del settore.
