Product management per il web

Persone e relazioni: la fonte della conoscenza per il product management#section1

Le persone che scrivono, progettano e sviluppano preferiscono spesso lavorare da sole o in piccoli gruppi. Per essere fatto bene, il lavoro creativo e molto dettagliato richiede attenzione e isolamento. Preferiamo fare il nostro lavoro in maniera tranquilla alla nostra scrivania, ma quando dobbiamo valutare l’UX e l’usabilità dobbiamo allontanarci dalla scrivania e passare del tempo con gli utenti.

L’importanza di tutti, indipendentemente dal loro ruolo nel team, nel fare le valutazioni di UX e usabilità non svanirà mai, ma in pratica sappiamo che ci sono dei limiti a quante valutazioni possono fare quelli che scrivono, progettano e sviluppano. Questo è il motivo per cui c’è una comunità in aumento di user experience practitioners, che si concentrano esclusivamente sull’analisi e sulla prototipazione incentrata sull’utente. In molti team, ricoprono esclusivamente questo ruolo.

Tuttavia, c’è molto più lavoro da fare prima di cominciare l’analisi della user experience e perfino prima della scrittura, progettazione e sviluppo: è il lavoro di product management.

Il product manager forma e coltiva una vasta rete di relazioni necessaria per assicurarsi che il team comprenda i problemi in maniera tale che possa proporre, dare priorità, progettare, realizzare e testare le soluzioni appropriate. Per questo, si ha bisogno di diplomazia, tempo e capacità comunicative. Tutto ciò è necessario per relazionarsi con la dirigenza, con i clienti, con chi si occupa del copy e con gli sviluppatori per guadagnarsi la fiducia di tutti.

Ad esempio, il range di persone incluse nel processo di product management è ampio. In qualità di product manager, dovrete incontrarvi regolarmente faccia a faccia con il presidente, con il chief information officer (CIO), con il chief marketing office (CMO) e, cosa forse più importante, con il direttore del technical support o del customer service della vostra azienda o di quella del vostro cliente. È importante documentare minuziosamente questi incontri: i suggerimenti sul prodotto e i punti dolenti che scoprirete diventeranno i dati su cui prendere decisioni riguardanti il prodotto.

L’altro valore di queste relazioni è che queste sono le persone alle quali dovrete comunicare e con cui perorare il vostro prodotto durante tutto il suo ciclo vitale. Queste persone hanno un duplice ruolo: non sono solo fonte di idee chiave ed informazioni, ma sono anche il pubblico delle vostre comunicazioni riguardanti le priorità e, in una fase successiva, le performance del prodotto. Allora, come si ottiene tutto ciò?

Più comunicazione!

Dati e comunicazioni: la credibilità del product management#section2

Quello che comunicate e il modo in cui lo fate è un aspetto cruciale dell’essere product manager:

• Ricerca: se chi si occupa del copy, i progettisti e gli sviluppatori passano la maggior parte del loro tempo alle loro scrivanie e il restante lo passano con i clienti, i product manager fanno l’esatto opposto. I product manager passano la maggior parte del proprio tempo in riunioni per scoprire i nuovi bisogni e per fare ricerca sui bisogni a cui altri hanno dato voce.
• Analisi: il product management comporta anche l’uso di sondaggi e di strumenti di analisi web per rivelare più dati sul prodotto. L’analisi dei risultati svela i trend che vi aiuteranno a dare delle priorità al lavoro di ciascuno.
• Report: i product manager devono scrivere dei brevi report in maniera regolare e dei report più lunghi trimestralmente. Riempiteli con grafici, diagrammi e riassunti delle vostre scoperte e opinioni. Filtrate tutti i dati che raccogliete e condivideteli con le persone che vi hanno dato informazioni. Questo rende visibile la vostra analisi e la vostra esperienza crescente, creando così fiducia nelle vostre decisioni di prodotto.
• Presentazioni: infine, non sottostimate il valore il tempo che passate faccia a faccia con la dirigenza, i clienti e i team creativi e di sviluppo. Assicuratevi di programmare molto tempo per presentare le vostre conclusioni, idee e priorità di prodotto di persona, a complemento della vostra attività di ricerca, analisi e reporting.

Dare peso equo a questi task assicura che il vostro processo di product management sia uno strato di valore ben visibile per le aziende e per i team coinvolti nel soddisfare i bisogni degli utenti. Meglio farete questo lavoro, più fiducia avranno tutti nelle vostre decisioni riguardanti il prodotto.

Quindi, oltre alla creazione di relazioni, alla raccolta dati, all’analisi e alle comunicazioni, c’è un ingrediente segreto del product management?

Sì. In realtà sono due ingredienti: le storie utente e le road map.

Storie utente: la moneta del product management#section3

Gli scrittori, i progettisti e gli sviluppatori si preoccupano sempre dei deliverable e i web product manager non fanno eccezione. Il principale deliverable del product manager è la storia dell’utente o user story.

Le user story non sono dei requisiti, delle specifiche o dei progetti. In effetti, esplicitamente, non sono alcuna di queste: non possono esserlo perché in tal caso non sarebbero user story. Sono molto più semplici di così, ma tuttavia il lavoro richiesto per creare delle buone storie utente dovrebbe essere sostanzioso se siete meticolosi. Ecco un esempio di una buona storia utente:

Come utente di Tipo G, ho bisogno di potermi registrare per il Programma Q sia in ufficio sia in contesti mobile.

A scopi comparativi, ecco una user story scarsa:

I clienti hanno bisogno di una webform con jQuery per la registrazione online e dovrebbe esserci un link alla form su ogni pagina nella top nav così come nel grande box rosso in homepage.

Ecco alcuni elementi che rendono il primo un esempio di buona user story:

• Il cliente è identificato con uno specifico tipo. A volte un miglioramenti del prodotto non riguarda tutti gli utenti, quindi, se questo è il caso, è importante identificare il cliente o il pubblico.
• In maniera analoga, abbiamo descritto il task con dei dettagli confrontabili. Questa categoria di cliente ha bisogno di registrarsi per qualcosa online e un tipo particolare di “qualcosa”, il Programma Q.
• C’è un chiarimento ulteriore riguardante il contesto in cui questo lavoro deve essere fatto. In questo caso, indipendentemente dal fatto che si trovino ad un desktop computer in ufficio o che stiano usando un dispositivo mobile.

È egualmente importante notare che ci sono cose che mancano. Occorre ribadirlo: non ci sono requisiti dettagliati, specifiche o dettagli di design nelle user story. Questo perché in qualità di product manager dovete creare storie basate sulle esigenze delle persone. È compito degli altri creare delle soluzioni che soddisfino i bisogni articolati nella user story.

Assicuratevi di evitare di esprimere le soluzioni di design come nel secondo esempio, che è scadente perché gestisce i clienti in generale e la registrazione per un qualsiasi programma. Il cliente generale e i tipi di task possono andare bene, ma più si riesce ad essere specifici con una definizione di bisogno, meglio è. Una volta che avrete creato un po’ di user story, potrete assemblarle in un road map.

Road map: l’itinerario del product management#section4

Scoprire il bisogno di nuovi o migliorati prodotti e catturare queste necessità in storie utente è una cosa. Cosa succede quando ci sono molti nuovi prodotti o miglioramenti, così tanti da essere troppi perché un solo team possa realizzarli in una volta?

Questo è un problema, ma è un buon problema e significa che in qualità di product manager avete più lavoro da fare. Dovete impostare delle priorità, ma questo non è come gestire una gran quantità di dolcetti di Halloween dopo aver fatto “dolcetto o scherzetto”: i progettisti e gli sviluppatori non devono solo andare al contenitore delle user story e scegliere quelle che vanno bene per loro. Non è un metodo molto oggettivo e le preferenze personali non dovrebbero stare alla base delle priorità dei membri del team.

Come web product manager siete incaricati di impostare le priorità delle user story e di organizzare queste priorità in road map e “release schedules” (calendari dei rilasci). Una road map è una rappresentazione visuale delle migliori user story nella coda delle storie utente e rappresenta le priorità e i gruppi di priorità correlate, chiamate “epics”. Un calendario dei rilasci è una versione della road map, spesso non così visuale ma sempre in una sorta di formato timeline. Come implica il nome, un calendario di rilascio è dove dovreste comunicare il vostro intento di avere il Miglioramento A disponibile ai clienti nel primo quadrimestre dell’anno 20XX, i Miglioramenti B e C nel secondo quadrimestre e il nuovo Prodotto D disponibile nel terzo quadrimestre.

Inoltre, è importante capire che potete impostare le priorità in maniera oggettiva, anche se sono in realtà priorità soggettive per i vostri clienti e i vostri stakeholder. Infatti, qui è dove l’arte e la scienza del product manager si incrociano: dovete dedicarvi spassionatamente ai vostri clienti e colleghi ed essere comunque oggettivi nell’impostare le priorità per aiutarli. Scegliere i giusti tool e i meccanismi appropriati per prendere le decisioni può aiutarci in questo processo. Uno di questi strumenti è il Kano Model.

Il Kano Model: un tool del product management#section5

Il Kano Model è una teoria che è stata sviluppata negli anni ’80 all’interno dell’industria automobilistica giapponese. È un ottimo strumento che può essere utilizzato dai product manager per analizzare e comparare gli attributi di prodotto in tre categorie:

• Base: l’attributo base di un prodotto indica una caratteristica essenziale del prodotto. Utilizzando il parallelismo con l’industria automobilistica, un attributo base di prodotto per un auto potrebbe essere il volante oppure il motore. Un’auto ha bisogno di entrambe per funzionare.
• Performance: questi attributi sono quelli che possono essere confrontati tra esempi di un prodotto perché differiscono sostanzialmente. Un attributo performance per un’auto è l’efficienza dei consumi o quanti chilometri può fare con un litro di carburante. Le persone tendono a preferire le auto con un migliore attributo di efficienza dei consumi.
• Piacevolezza: gli attributi di piacere sono quelli che vanno oltre gli attributi base o di performance e a volte non servono ma possono entusiasmare gli utenti. Per un’auto, un attributo di piacevolezza potrebbe essere un tettuccio apribile. Sull’auto sportiva giusta e per determinati clienti, un tettuccio apribile potrebbe essere molto piacevole. Ma non è essenziale per il funzionamento della macchina e nemmeno migliora la performance dell’auto.

Avvalendosi di questi tre attributi, un product manager può analizzare una varietà di miglioramenti potenziali utilizzando una metrica la scala a cinque punti. Inoltre, più input sui clienti e sulle analitiche avete, meglio è.

Ad esempio, se volete fare un sito web ottimizzato per il mobile, potreste avere la seguente lista di storie utente che vorreste implementare:

• Gli utenti su iPhone dovrebbero essere in grado di vedere il sito senza dover fare “pinch and zoom”.
• Gli utenti su smartphone Android dovrebbero poter usare il sito senza fare “pinch and zoom”.
• Gli utenti dovrebbero essere in grado di completare le web form sui dispositivi mobili con uno sforzo minimo.
• Gli utenti con tablet di sette pollici dovrebbero poter usare il sito in maniera comoda, con la navigazione ridimensionata allo schermo e adatta alle proprie dita.

Non vi dirò quali user story hanno diritto di precedenza sulle altre perché queste priorità sono specifiche dei bisogni e delle preferenze sia della dirigenza dell’organizzazione sia dei clienti del vostro prodotto. Ma se vi vengono dati degli input dalla vostra azienda, se state chiedendo ai clienti come usano il vostro prodotto web e se state verificando l’attività con le analitiche, in qualità di product manager dovreste essere in grado di discernere quali miglioramenti daranno il più alto valore e se tale valore sarà di base, migliorerà la performance o magari sarà anche un miglioramento che sorprenderà i vostri clienti e genererà dell’entusiasmo per il vostro prodotto.

Questo esempio mostra come potete ottenere una lista più lunga di user story e suddividerla in quantità di lavoro più piccole che possono essere distribuite nel team. Queste piccole quantità di lavoro posso essere comunicate in calendari di rilascio e potete fare dei report su questi calendari nella road map di prodotto. Tutto ciò aiuta le aziende, i team di design e i team di sviluppo a navigare il mercato del prodotto con più intenzione e sicurezza.

Minimal viable product: un obiettivo del product management#section6

L’obiettivo del product management è di fare dei piccoli miglioramenti in maniera più continua per le persone che usano il vostro sito web, mobile app o altri software. Quando i team di design e sviluppo fanno il passo più lungo della gamba, il sito web o l’app rischiano stagnare.

In un mondo in cui le tecnologie web cambiano costantemente, il product management può fornire la chiarezza di cui si ha bisogno perché il design e lo sviluppo siano più efficienti. Il suo scopo è un minimal viable product: uno che soddisfi le esigenze delle persone al meglio possibile e le soddisfi oggi. Poi, il giorno seguente, non state lì a guardare e dire che il vostro prodotto è completo: validate tramite i vostri utenti quello che avete fatto e cercate di capire cosa dovete migliorare adesso. In seguito, il product manager dà delle priorità alle nuove storie utente e imposta le date per le nuove release per continuare a migliorare il sito o l’app.

Il web è già grande e continuerà ad ingrandirsi, ma le persone non hanno bisogno di un web più grande, ma semplicemente di un web migliore. I product manager contribuiscono al miglioramento del web e fanno in modo che le organizzazioni e i team rimangano concentrati su quello di cui si ha più bisogno. Investendo nelle relazioni con le persone all’interno e all’esterno dell’organizzazione, i web product manager imparano quello di cui hanno bisogno per impostare delle priorità di prodotto intelligenti che rendono il web gradualmente ma costantemente migliore.

Perché il web non è mai finito.

Illustrazioni: {carlok}