Quale valore per gli stakeholder?

Questo post nasce da una riflessione su un lavoro di riprogettazione di una sezione di un sito e-commerce.
Il cliente ritiene che non si stiano cogliendo a pieno le opportunità della presenza online e decide di avviare una revisione dell’architettura informativa e dei contenuti.
Mi metto al lavoro ed il primo passo del processo è individuare il reale valore di questo intervento per gli stakeholder, quindi sia per il cliente interno sia per il cliente finale.

Il valore per i clienti interni

Dopo un veloce assessment della sezione in questione mi organizzo per alcune interviste.
I primi stakeholder sono i colleghi che lavorano in quell’area e per cui il sito e-commerce rappresenta il principale canale di vendita del prodotto.

Nel corso dei colloqui questi interlocutori tendono a focalizzarsi per lo più su cosa non funziona dal loro punto di vista (che non è detto coincida con quello del cliente finale) e a proporre soluzioni sulla base delle loro competenze digitali.

E’ perfettamente normale che accada questo, ma il mio compito come Product Owner è esplorare lo scenario a 360 gradi, prendermi tutto il tempo che serve per focalizzarmi sui problemi e tollerare in questa fase di non sapere (come diceva Einstein?).

Il mio obiettivo è fare esplicitare agli stakeholder quali sono le loro aspettative rispetto al lavoro che ci apprestiamo a fare, come sperano che cambi la loro attività quotidiana e quale risposta si attendono dai clienti in seguito a questi interventi.
Sto chiedendo loro di proiettarsi nel futuro, nello scenario in cui la riprogettazione è già avvenuta e di descrivere cosa è cambiato e come.

Ora vi sembrerà banale chiedere in anticipo “Cosa è cambiato per te?”, “Come è migliorata la tua giornata di lavoro dopo questo rilascio?”, “Cosa fanno di diverso i clienti?”. In verità le risposte a queste domande sono tutt’altro che scontate e mi permettono di cogliere una varietà di prospettive.

Nel mio caso è andata proprio così: 4 persone mi hanno dato 4 risposte affini mettendo però l’accento su aspetti differenti.
Il CEO misurerà l’efficacia in base alla crescita del venduto; il responsabile della business unit si aspetta un aumento della marginalità e un incremento del Net Promoter Score; il responsabile scientifico auspica, oltre a maggiori ricavi, un più ampio riconoscimento del brand quale leader nel settore; il marketing specialist vuole costruire pagine e campagne con maggiore flessibilità.

Come vedete è interessante raccogliere queste prospettive durante la fase di discovery per 3 motivi: da esse riusciamo a individuare una serie di problemi che non erano emersi nelle riunioni iniziali sulla riprogettazione, abbiamo la possibilità di gestire le aspettative degli stakeholder (perché adesso le conosciamo!) e sappiamo come il nostro lavoro verrà misurato in azienda.

Il valore per il cliente finale

Questo è ovviamente il punto cardinale di tutto il lavoro di riprogettazione.
Per essere certi di andare nella giusta direzione dobbiamo intervistare i clienti – possibilmente vari segmenti di clientela – così da cogliere i diversi bisogni e necessità.

Ricordate: se abbiamo individuato il valore per l’azienda ma non siamo in grado di definire quali sono i vantaggi per il cliente finale abbiamo un enorme problema. Significa che stiamo rilasciando funzionalità, ma non stiamo risolvendo problemi. In una parola: waste! Spreco.

Questo è il motivo per cui affianco sempre l’indagine all’interno dell’azienda con interviste sul campo a clienti veri e potenziali.
Negli anni ho imparato a non dare per scontato che gli esperti di settore abbiano davvero il polso del cliente (spesso è così, ma è opportuno verificare in ogni caso); preferisco sempre toccare con mano cosa significa essere nei panni dell’utente finale.
Anche qui potremmo scoprire una certa varietà di opinioni su come un prodotto, un servizio o una certa funzionalità sia in grado di migliorare la vita del cliente.

Tornando al mio caso dopo poche interviste sul campo ho raccolto alcune suggestioni su ciò che è potenzialmente di valore per il cliente finale: un’ampia scelta di contenuti, strumenti per individuare velocemente l’offerta giusta, una comparazione visuale degli item nella medesima fascia di prezzo e un processo di acquisto semplificato.

Con questa comprensione posso ora muovermi per ridisegnare l’esperienza utente, l’architettura dell’intera sezione e le funzionalità presenti nelle singole pagine.

Gli step per la creazione di valore

Adesso che ho una mappatura chiara delle aspettative interne ed esterne non mi resta che seguire alcuni semplici passi:

  1. mappare il percorso del valore
  2. riprogettare la sezione di conseguenza
  3. portare alla luce ciò che prima non c’era o era nascosto.

Mappare il percorso del valore

Per fare questo utilizzo un semplice foglio di lavoro online.
Ricostruisco il percorso dell’utente a partire dal bisogno iniziale: la ricerca della soluzione, l’atterraggio sul sito, la ricerca interna, la selezione dell’offerta, il processo di acquisto e tutto ciò che viene dopo.
Ogni casella dello spreadsheet è uno step del journey dell’utente e per ognuna di esse vado a specificare i bisogni, i problemi incontrati, le opportunità che non stiamo cogliendo, ecc.
Questo documento è la spina dorsale del lavoro di riprogettazione vera e propria.

Riprogettare la sezione del sito

Tenendo a mente i bisogni, i problemi e le opportunità vado a ridisegnare l’esperienza utente.
Personalmente amo partire da carta e matita. Uno scketch veloce della struttura e delle principali funzionalità prima di partire a costruire il wireframe con i software di prototipazione (Axure o Adobe XD).

Una volta pronto il prototipo – per quanto scarno e privo di grafica – mi piace sottoporlo agli interlocutori iniziali così da verificare se risolve effettivamente i problemi riscontrati (particolarmente rilevante è l’opinione dei reali utilizzatori del sito).
L’ultimo passo sarà la creazione del visual design e di tutti i template UI.

Portare alla luce il valore

Tutto ciò che ho individuato come rilevante dentro e fuori dall’azienda deve ora diventare visibile. Si tratta di dare risposta ai problemi e alle necessità che sono emerse.

Questo è per me un lavoro di team.
Mi piace confrontarmi con UX specialist, designers ed il tech team per capire insieme se abbiamo davvero indirizzato tutti i problemi, se siamo riusciti a rispondere correttamente alle aspettative.

A volte il lavoro di riprogettazione è anche solo questo: non sono necessarie nuove funzionalità, ma è opportuno rendere più visibile o più semplice ciò che già era presente.
Il nostro lavoro – quando è fatto bene – è per lo più un lavoro di semplificazione. A togliere.
Scusate, oggi sono in vena di citazioni…

Misurare il valore

Siamo arrivati al termine del nostro lavoro, abbiamo rilasciato la nuova versione della sezione. Come facciamo a capire se questo cambio ha avuto successo?
Io questa domanda la faccio prima, a tutti. Voglio capire sin dall’inizio sulla base di quali criteri sarà valutato il lavoro del team (in passato abbiamo già parlato dell’importanza della definizione dei criteri di successo).

Da cosa riconosceremo che questa riprogettazione è stata un successo?”, “Quale criterio di misurazione adotteremo?“.
Spesso vedo facce stranite… evidentemente sono domande inusuali!
Devo dire la verità: nei contesti in cui non c’è una cultura data-driven è normale che le persone facciano fatica ad articolare una risposta a una domanda così a bruciapelo.

Possiamo insistere provando a riformulare in altro modo: “Cosa faranno di più i clienti? Cosa di meno? Cosa diversamente?”, “Cosa inizieranno o smetteranno di fare?“.
Se ci pensate sono esattamente le stesse domande che stanno alla base della definizione degli impatti nell’Impact Mapping.
E infatti è proprio lì che vogliamo arrivare: a condividere degli impatti – ovvero le modificazioni nei comportamenti – e a formulare sulla base di questi le metriche più adatte.

I Key Performance Index corretti ci consentiranno di rispondere con dati quantitativi alla mano alle aspettative degli stakeholder interni e di misurare realmente se e come abbiamo influenzato gli stakeholder esterni.
Le stesse metriche le utilizzo per creare report mensili che condivido con il management team per monitorare l’andamento delle performance di prodotto. E così il ciclo si chiude!

I migliori libri per Product Owner: Lean Startup

Il 2011 per me è stato davvero un anno di svolta.
E’ l’anno in cui ho scoperto l’Agile e ho preso parte ad un primo pilot nella mia azienda di allora (Matrix!). Sarà per questo che sono così legata al libro di Eric Ries?
Lean Startup” è uscito nello stesso anno e per me è stato davvero una rivelazione… uno di quei libri che ti aprono un mondo. L’ho letto e riletto più volte, consumato di note e regalato con gioia.

Racconta per filo e per segno qualcosa che ai tempi avevo solo intuito durante il mio percorso professionale ma non ero mai riuscita ad articolare così chiaramente.
Ries lo fa con una leggerezza, una facilità e una trasparenza senza eguali.
Ecco perché ho deciso di partire da questo volume per inaugurare una nuova serie di post: “I libri migliori per Product Owner”.

Il libro parla del mondo delle startup (come è intuibile dal titolo), ma i principi ed i suggerimenti che contiene sono dal mio punto di vista preziosi in qualunque contesto di mercato.
Questo volume ha proprio cambiato il mio modo di pensare; mi ha illuminato con un metodo che applico istintivamente a tutti i progetti in ambito professionale e tendo a far sconfinare anche al di fuori del lavoro.

Sono 5 i concetti-chiave che mi hanno più influenzato come Product Owner e voglio ripercorrerli con voi uno ad uno. Parliamo di flessibilità, apprendimento validato, Minimum Viable Product, cicli di feedback e metriche di qualità.

Rimani flessibile

Le startup a differenza delle aziende consolidate non possono prevedere il proprio futuro perché non hanno passato e non sanno (ancora) quali sono gli approcci migliori per trovare clienti o creare un’attività sostenibile.
Per scoprire cosa potrebbe funzionare, devono rimanere flessibili. Nel loro caso adottare piani fissi con traguardi prestabiliti o fare affidamento su previsioni di mercato a lungo termine significa illudersi. Perché gestire una start-up è come guidare una jeep su un terreno accidentato: i fondatori devono costantemente cambiare direzione e rispondere rapidamente a ostacoli imprevisti e vicoli ciechi.

Come Product Owner tendo a storcere il naso quando sento parlare di roadmap “annuali” e di pianificazioni che vanno oltre i 6 mesi. Non fraintendetemi: ha tutto il senso del mondo definire degli obiettivi di business annuali o pluriannuali ma non credo che il percorso su come raggiungerli (la roadmap appunto) sia scritta sulla pietra.

Oltre l’orizzonte temporale di metà anno tutto ciò che viene dichiarato è potenzialmente soggetto a cambiamento per motivi interni ed esterni all’azienda (nuove opportunità di mercato, la necessità di rispondere alle mosse di un competitor, una ripianificazione delle priorità a fronte di determinati risultati).
Posso immaginare che nell’edilizia la pianificazione di un complesso sia un progetto che è meno soggetto a fluttuazione ma nel mondo digitale 6 mesi sono un periodo lungo in cui lo scenario può essere stravolto anche sono dall’evoluzione della tecnologia stessa.
Per questo motivo come Product Owner evito di fare piani dettagliati che vadano oltre i 6 mesi e per periodi successivi mi limito ad indicare una serie di temi (di alto livello) che saranno oggetto di sviluppo, ma che possono essere riconsiderati periodicamente strada facendo.

Rimanere flessibile mi consente di cogliere opportunità più interessanti che si presentano lungo il percorso e che non erano previste in fase iniziale o di riconsiderare le mie priorità se nuovi dati le mettono in discussione.

Non dare per scontato il valore

L’obiettivo principale di qualsiasi startup è trovare un modello di business redditizio e sostenibile.
In pratica, questo significa scoprire quali prodotti desiderano i potenziali clienti e come trasformare i loro desideri in ricavi costanti.

Alla base di ogni prodotto esistono infatti due presupposti fondamentali: l’ipotesi del valore e l’ipotesi di crescita.
L’ipotesi del valore presuppone che un prodotto fornirà valore ai propri clienti, ovvero che i primi utilizzatori troveranno e abbracceranno il prodotto.
L’ipotesi di crescita afferma che il prodotto non solo piacerà alla nicchia degli early adopters, ma troverà anche un mercato più ampio in seguito.

E’ importante comprendere che questi concetti sono ipotesi e come tali devono essere testate e convalidate parlando con i clienti. Solo in questo modo sapremo di essere sulla strada giusta per trovare un modello di business sostenibile.

Come Product Owner non posso dare nulla per scontato, anche che ciò che l’azienda ritiene sia di valore per il cliente finale. Ho spesso sperimentato che le società affermano di conoscere il loro pubblico ma presumono, a volte dimostrano anche una certa arroganza nel pretendere di sapere a priori ciò che vogliono i clienti, ma la verità è che fino a quando un prodotto non va in mano ad un utilizzatore finale non saprai mai quanto piacerà e come verrà utilizzato.

Sapete come si dice? Customer is king! Quindi la cosa più di valore che posso fare per assicurare il successo di un prodotto è lasciare da parte il mio “corporate ego”, rimanere umile, approcciare il cliente ed ascoltarlo. Tutto il resto è presunzione!
Se avete bisogno di indicazioni pratiche su come farlo le trovate in questo post dedicato alle 15 domande per costruire le Personas.

Testa le idee con esperimenti

Come si possono mettere alla prova le idee di valore e di crescita? Semplice! E’ necessario formulare ipotesi su se e come determinati prodotti avranno successo in un particolare mercato.
E’ stato questo il caso di Zappos che, prima di lanciare il suo business in rete e ben prima dell’acquisizione da parte di Amazon, ha testato l’assunzione più rischiosa di tutto il suo modello di business: “i clienti statunitensi saranno disposti ad acquistare scarpe online”.

Nick Swinmurn – fondatore dell’azienda – l’ha fatto nel 1999 creando una versione minima del prodotto (MVP), ma minima davvero. Ha rilasciato un sito “civetta”, il front-end di un negozio di scarpe online senza che esistesse alcun tipo di back-end, di infrastruttura dietro o di magazzino. Ha evaso i primi ordini acquistando e spedendo le scarpe precedentemente fotografate direttamente nei negozi.
Questo MVP gli ha permesso di verificare che l’idea di business iniziale era valida.

Sono tristemente consapevole di quanto il concetto di MVP nelle aziende digitali sia stato scarsamente compreso, spesso osteggiato e molto vituperato (… a quanto pare oggi “fa più figo” parlare di Minimum Lovable Product).

Non entro in questa polemica che richiederebbe un post a sé, ma mi preme sottolineare il principio che ne sta alla base: quando non si è ancora trovato il product/market fit, quando il valore è ancora solo un’ipotesi il MVP dovrebbe essere il più semplice possibile e contenere solo ciò che è necessario per offrire ai clienti un’esperienza realistica di come funzionerebbe il prodotto. Serve solo quanto basta per trarre utili feedback!
Qui trovate uno strumento che potrebbe supportarvi nel creare esperimenti Lean.

Diverso è il caso di un prodotto consolidato che viene riproposto in una nuova veste o riaggiornato. In questo caso il “minimum” accettabile dal cliente non è meno delle funzionalità già presenti nel prodotto. In ogni caso questo approccio può tornarvi molto utile per evitare eccessivi sviluppi upfront o gold plating.

Costruisci – Misura – Impara

Ries si sofferma a lungo sui benefici del ciclo Build – Measure – Learn (BML) in Lean Startup.


Come funziona? Si costruisce una versione semplice del prodotto, come un prototipo o uno smoke test, lo si porta sul mercato e si raccolgono i feedback dei clienti.
Con i dati quantitativi di questo esperimento si misura l’interesse per il prodotto, nel caso di Zappos quante persone hanno cliccato sul pulsante “buy” e hanno provato ad acquistare scarpe dal negozio fake.
Ciò che si impara in un ciclo completo viene utilizzato per ottimizzare il prodotto che nella versione migliorata fa partire il successivo ciclo BML.
Ci sono due aspetti importanti qui: la velocità del feedback loop è fondamentale e un prodotto non è mai finito al primo rilascio!

Personalmente credo molto nel feedback loop (e non solo in ambito digitale!).
Questo è l’approccio corretto non solo per il lancio di un nuovo prodotto, ma per qualsiasi ottimizzazione vogliate fare.
Costruite un MVP o una nuova funzionalità o una nuova interfaccia, la mettete nelle mani di clienti reali e analizzate quanto e in che modo il prodotto cambia i loro comportamenti.
Se non misurate i risultati non avete modo di imparare alcunché!

Allo stessa stregua come Product Owner utilizzo estensivamente gli esperimenti per testare varianti del mio prodotto. Gli A/B test e in generale tutti i test dai più semplici ai più complessi dovrebbero essere il pane quotidiano per chi lavora in ambito prodotto.
Anche quando avete raggiunto una buona conoscenza del target e del mercato scoprirete che i test riusciranno sempre a stupirvi. I risultati inaspettati sono all’ordine del giorno.

Cerca le metriche giuste

Definire le metriche corrette da monitorare e valutarle con costanza è fondamentale per qualsiasi startup… e per qualsiasi prodotto aggiungo io!
Solo quando vediamo i KPI di riferimento migliorare sappiamo di essere indirizzati verso il raggiungimento degli obiettivi a lungo termine.
Ovviamente queste metriche possono variare – e di molto – da business a business, quindi non esiste una formula magica che possa valere per tutti.

Le metriche “giuste” sono quelle che ci consentono di capire se stiamo andando nella giusta direzione. Eric Ries sottolinea come molte startup cedano alla tentazione di utilizzare “vanity metrics”, metriche lusinghiere ma inutili o addirittura dannose che fanno sembrare un’azienda buona ma non aiutano ad avvicinarla ai suoi obiettivi.
E’ fin troppo facile farsi lusingare da tanti like su Facebook: possono essere fonte di gran soddisfazione ma questi apprezzamenti non pagano gli stipendi e non rappresentano in alcun modo un modello di business sostenibile.

Come Product Owner è mia responsabilità capire quali sono le metriche più adatte per misurare le specificità del mio prodotto. Senza dati sono totalmente cieca.
Posso avere delle intuizioni circa la strada da intraprendere, posso aver collezionato feedback dai miei utenti, ma ho in ogni caso bisogno di dati quantitativi affidabili per prendere delle decisioni informate e giustificarle agli occhi degli stakeholder.
I dati mi aiutano ad eliminare sul nascere qualsiasi guerra di opinione.

Conclusione

Le startup utilizzano un approccio semi-scientifico per testare le loro ipotesi di base e costruire un modello di business sostenibile sulle ipotesi convalidate.
Io Product Owner posso trarre vantaggio dal metodo Lean Startup decidendo di sviluppare rapidamente prototipi di prodotto e perfezionandoli continuamente attraverso il feedback dei clienti. Eseguendo cicli di costruzione, misura e apprendimento (BML) incremento significativamente le possibilità di successo del mio prodotto.