![](\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2012\/08\/n57-2.png\")
Sia che stiamo prototipando, scrivendo, progettando, sviluppando o testando come parte di un processo di creazione del web, stiamo realizzando qualcosa che verr\u00e0 utilizzato da centinaia, migliaia o addirittura milioni di persone. Ma come possiamo essere sicuri che stiamo apportando le giuste migliorie al web, al momento giusto e per gli utenti giusti? Perch\u00e9 ce l’ha chiesto il nostro cliente o il nostro capo? Come fanno a saperlo?<\/p>\n
Introduciamo il product management per il web.<\/p>\n
Nel caso del web, il product management colma il vuoto che c’\u00e8 tra la dirigenza e i clienti da una parte e i team di user experience, content strategy e sviluppo dall’altra. I product manager sviluppano e mantengono dei rapporti stretti con i clienti e con i colleghi. Tali relazioni li aiutano ad identificare e pianificare nuovi prodotti o opportunit\u00e0 di miglioramento del prodotto. I product manager esprimono queste opportunit\u00e0 come storie utente e le presentano ai membri del team di UX, di copy, di design e di sviluppo, che poi identificano e mettono in campo soluzioni per gestire queste storie.<\/p>\n
Quindi, come si introduce il product management per il web in un team o in un’azienda? Si comincia dalle persone.<\/p>\n
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\u00e0 dobbiamo allontanarci dalla scrivania e passare del tempo con gli utenti.<\/p>\n
L’importanza di tutti, indipendentemente dal loro ruolo nel team, nel fare le valutazioni di UX e usabilit\u00e0 non svanir\u00e0 mai, ma in pratica sappiamo che ci sono dei limiti a quante valutazioni possono fare quelli che scrivono, progettano e sviluppano. Questo \u00e8 il motivo per cui c’\u00e8 una comunit\u00e0 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.<\/p>\n
Tuttavia, c’\u00e8 molto pi\u00f9 lavoro da fare prima di cominciare l’analisi della user experience e perfino prima della scrittura, progettazione e sviluppo: \u00e8 il lavoro di product management.<\/p>\n
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\u00e0, progettare, realizzare e testare le soluzioni appropriate. Per questo, si ha bisogno di diplomazia, tempo e capacit\u00e0 comunicative. Tutto ci\u00f2 \u00e8 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.<\/p>\n
Ad esempio, il range di persone incluse nel processo di product management \u00e8 ampio. In qualit\u00e0 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\u00f9 importante, con il direttore del technical support o del customer service della vostra azienda o di quella del vostro cliente. \u00c8 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.<\/p>\n
L’altro valore di queste relazioni \u00e8 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\u00e0 e, in una fase successiva, le performance del prodotto. Allora, come si ottiene tutto ci\u00f2?<\/p>\n
Pi\u00f9 comunicazione!<\/p>\n<\/div>\n
Quello che comunicate e il modo in cui lo fate \u00e8 un aspetto cruciale dell’essere product manager:<\/p>\n
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\u00f9 fiducia avranno tutti nelle vostre decisioni riguardanti il prodotto.<\/p>\n
Quindi, oltre alla creazione di relazioni, alla raccolta dati, all’analisi e alle comunicazioni, c’\u00e8 un ingrediente segreto del product management?<\/p>\n
S\u00ec. In realt\u00e0 sono due ingredienti: le storie utente e le road map.<\/p>\n<\/div>\n
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 \u00e8 la storia dell’utente o user story.<\/p>\n
Le user story non sono dei requisiti, delle specifiche o dei progetti. In effetti, esplicitamente, non sono alcuna di queste: non possono esserlo perch\u00e9 in tal caso non sarebbero user story. Sono molto pi\u00f9 semplici di cos\u00ec, 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:<\/p>\n
Come utente di Tipo G, ho bisogno di potermi registrare per il Programma Q sia in ufficio sia in contesti mobile.<\/em><\/p><\/blockquote>\n
A scopi comparativi, ecco una user story scarsa:<\/p>\n
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\u00ec come nel grande box rosso in homepage.<\/em><\/p><\/blockquote>\n
Ecco alcuni elementi che rendono il primo un esempio di buona user story:<\/p>\n
\n
- Il cliente \u00e8 identificato con uno specifico tipo. A volte un miglioramenti del prodotto non riguarda tutti gli utenti, quindi, se questo \u00e8 il caso, \u00e8 importante identificare il cliente o il pubblico.<\/li>\n
- 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.<\/li>\n
- C’\u00e8 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.<\/li>\n<\/ul>\n
\u00c8 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\u00e9 in qualit\u00e0 di product manager dovete creare storie basate sulle esigenze delle persone. \u00c8 compito degli altri creare delle soluzioni che soddisfino i bisogni articolati nella user story.<\/p>\n
Assicuratevi di evitare di esprimere le soluzioni di design come nel secondo esempio, che \u00e8 scadente perch\u00e9 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\u00f9 si riesce ad essere specifici con una definizione di bisogno, meglio \u00e8. Una volta che avrete creato un po’ di user story, potrete assemblarle in un road map.<\/p>\n<\/div>\n
\nRoad map: l’itinerario del product management<\/h2>\n
Scoprire il bisogno di nuovi o migliorati prodotti e catturare queste necessit\u00e0 in storie utente \u00e8 una cosa. Cosa succede quando ci sono molti nuovi prodotti o miglioramenti, cos\u00ec tanti da essere troppi perch\u00e9 un solo team possa realizzarli in una volta?<\/p>\n
Questo \u00e8 un problema, ma \u00e8 un buon problema e significa che in qualit\u00e0 di product manager avete pi\u00f9 lavoro da fare. Dovete impostare delle priorit\u00e0, ma questo non \u00e8 come gestire una gran quantit\u00e0 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 \u00e8 un metodo molto oggettivo e le preferenze personali non dovrebbero stare alla base delle priorit\u00e0 dei membri del team.<\/p>\n
Come web product manager siete incaricati di impostare le priorit\u00e0 delle user story e di organizzare queste priorit\u00e0 in road map e “release schedules” (calendari dei rilasci). Una road map \u00e8 una rappresentazione visuale delle migliori user story nella coda delle storie utente e rappresenta le priorit\u00e0 e i gruppi di priorit\u00e0 correlate, chiamate \u201cepics\u201d. Un calendario dei rilasci \u00e8 una versione della road map, spesso non cos\u00ec visuale ma sempre in una sorta di formato timeline. Come implica il nome, un calendario di rilascio \u00e8 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.<\/p>\n
Inoltre, \u00e8 importante capire che potete impostare le priorit\u00e0 in maniera oggettiva, anche se sono in realt\u00e0 priorit\u00e0 soggettive per i vostri clienti e i vostri stakeholder. Infatti, qui \u00e8 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\u00e0 per aiutarli. Scegliere i giusti tool e i meccanismi appropriati per prendere le decisioni pu\u00f2 aiutarci in questo processo. Uno di questi strumenti \u00e8 il Kano Model.<\/p>\n<\/div>\n