Febbraio 28, 2022 - di Jasmine Comi
Vorrei condividere con voi la mia esperienza da Product Manager che si è trovata ad affrontare un’improvvisa transizione da un contesto focalizzato sul B2B a un contesto B2C.
Da qualche anno infatti, sto lavorando nel mondo del Turismo digitale, settore in cui le opportunità d’imparare e di sperimentare sono davvero tante. Ho infatti modo di lavorare su diverse tipologie di piattaforme e d’interagire con diverse platee di utenti.
Quando vi parlo di utenti, non mi riferisco solo agli end user, ma a utenti come fornitori di esperienze e partner. Nel primo caso stiamo quindi parlando di piattaforme B2C, mentre nel secondo di piattaforme B2B.
È proprio per questo motivo che parlo di transizione, perché il mio passaggio dal mondo B2B al B2C è stato davvero un cambio sostanziale non solo a livello di piattaforma, ma anche di relazioni.
Sin da subito ho dovuto rivedere completamente il mio approccio, specialmente per quanto riguarda il mindset e il rapporto con gli stakeholder.
Ci sono tre aree importanti su cui vi invito a riflettere. Vediamole insieme.
Innanzitutto, dobbiamo ricordare che una piattaforma B2B deve essere in grado di soddisfare una platea di utenti molto diversi tra loro. Prendo ad esempio il mio caso, dove abbiamo dovuto sviluppare una piattaforma per fornitori di esperienze di viaggio.
In base alla tipologia di fornitore con il quale ci trovavamo a dialogare, le richieste erano le più svariate, dalla disponibilità dei prodotti al caricamento delle immagini. Il nostro obiettivo era quindi quello di sviluppare una piattaforma che avesse delle funzionalità comuni per tutte le tipologie di utenti.
Il primo aspetto su cui ragionare, tipico del mondo B2B, è quindi la creazione della roadmap e solo successivamente delle metriche di controllo.
L’obiettivo principale della roadmap è infatti quello di comprendere quali sono le funzionalità che la piattaforma deve avere, piuttosto che focalizzarsi su quali metriche migliorare. Prima di tutto, un partner o un fornitore vi chiederà di poter compiere determinate azioni sulla piattaforma. Starà poi alla capacità del product manager, valutare come collegare le funzionalità a metriche misurabili.
La roadmap è quindi composta da una serie di funzionalità che si estendono nel medio/lungo periodo (ci riferiamo ad un arco temporale di minimo 1 anno).
Perché l’orizzonte è così esteso? Ritornando all’esempio precedente della piattaforma di fornitori di esperienze, l’obiettivo è quello di evolvere la piattaforma rendendo l’utente autonomo di compiere determinate azioni senza le quali, la piattaforma in sé non avrebbe senso. Ovviamente questo approccio è in linea con questa tipologia di piattaforma, dove l’utente è un fornitore che necessità specifiche funzionalità per poter fornire il suo materiale. Qualora parlassimo di piattaforme B2B verso dei partners, dove abbiamo influenze dal mercato (per esempio fluttuazioni di vendita), la roadmap sarà soggetta a qualche cambiamento in corso d’opera, assomigliando maggiormente ad un ambito B2C come vedremo dopo.
Le funzionalità vengono raccolte e discusse sempre con gli stakeholders principali, anche se la sequenza e la prioritizzazione rimarrà sempre a capo del product manager (che è a tutti gli effetti l’owner della piattaforma). Più avanti nell’articolo andremo ad approfondire gli strumenti necessari per poter attuare la prioritizzazione delle funzionalità.
Nell’approccio B2B vi sono delle metriche importanti da considerare, ci riferiamo innanzitutto a quelle relative all’ambito dell’adoption.
Nel dettaglio, meritano di essere menzionati:
Tuttavia, quando ci si concentra su piattaforme interne, il focus si sposta maggiormente sul come rendere più semplice una determinata azione piuttosto che misurarne l’effettivo impatto attraverso i KPI. Questo perché non sempre una nuova funzionalità ha un impatto determinante sulle nostre metriche.
L’unico modo per comprendere se si sta veramente facilitando una funzionalità è quello di ricevere direttamente dei feedback qualitativi interni (anzichè limitarsi a semplici metriche numeriche). Ad esempio nel caso della piattaforma di fornitori di esperienze, oltre a dei KPI di riferimento (bounce rate sulle pagine, time to complete uploading etc), preferivamo associarle a dei survey con i fornitori e stakeholder interni che seguivano molto da vicino questa parte.
Nell’ambito B2C, ci rivolgiamo anche in questo caso a una platea molto ampia, ma siamo facilitati dall’utilizzo delle personas, ovvero “l’utente tipo”, che ci permetterà di comprendere al meglio interessi e necessità del nostro target. Nella mia esperienza, avendo due principali canali di vendita e-commerce con una platea di utenti diversi, abbiamo speso molto tempo nella stesura di personas, e questo ci è servito tantissimo.
La differenza sostanziale rispetto all’approccio B2B è che nell’ambito B2C la roadmap sarà fortemente influenzata dalle metriche. In questo caso, la roadmap anziché rappresentare una sequenza di funzionalità, rappresenterà una sequenza di KPI, che ci permetterà di affrontare al meglio le condizioni di variabilità del mercato in cui ci troviamo. Ci tengo a specificare che questo vale per la mia esperienza di piattaforma B2B rivolta a fornitori, dove le esigenze non sono soggette a cambiamenti influenzati da sales.
Anche nel B2C, la roadmap ha dei tempi di orizzonte abbastanza lunghi, circa di 1 anno, ma tende a essere più flessibile rispetto a quella B2B, in quanto più soggetta all’andamento del mercato. Non è così casuale – specialmente in tempi come questi – che da un quarter all’altro la roadmap venga completamente stravolta.
Spesso e volentieri i product manager si trovano ad affrontare un tema alla volta. Potrà capitare di intervenire sulla retention degli utenti, sul come aumentare il margine medio della piattaforma, eccetera. La metrica di riferimento per i nostri specifici e-commerce – north star – è il conversion rate.
Chiaramente, le metriche da valutare saranno diverse in base all’ambito d’intervento. Possiamo però sintetizzare 3 macro aree principali per l’approccio B2C, ognuna delle quali dovrà avere delle proprie metriche di riferimento per monitorare se le azioni intraprese sono corrette o meno:
Un altro aspetto fondamentale da trattare riguarda lo stakeholder management e la raccolta dei requisiti nel passaggio dal mondo B2B a B2C. Nell’ambito B2B, spesso e volentieri è lo stakeholder interno che tende a guidare la maggior parte degli sviluppi della piattaforma.
Questo cosa significa?
Questo rapporto rappresenta uno degli aspetti fondamentali per capire la dinamiche insite nel mondo B2B. Nei momenti di confronto con lo stakeholder, si cerca di comprendere quali sono i problemi principali da risolvere. Spesso lo stakeholder presenta una lista di requisiti già definita, ma è compito del product manager filtrare e capire il “why” che sta dietro a questi requisiti.
Nella mia esperienza specifica sulla piattaforma di fornitori di esperienze – e cercando di comprendere il perché di alcune loro richieste – spesso chiedevo allo stakeholder un Business Case di supporto per meglio comprendere l’impatto che loro prevedevano. Questo mi aiutava a capire quale problema prioritizzare in primis.
Una volta chiaro il problema d’affrontare, insieme al team di design si cercano delle prime soluzioni che -successivamente – il product manager deve controllare con il team di prodotto, ma non solo. Va controllato anche quanto “effort” sia necessario per realizzarle e prioritizzare in base ad una semplice matrice impact/effort, oppure un modello RACI (che prenda in considerazione anche il numero totale di utenti impattati). Non reputo che un modello sia migliore dell’altro, ma personalmente tenderei a utilizzare il primo per un approccio B2B e il secondo prettamente nell’ambito B2C.
Per quanto riguarda il mondo B2C, ci troveremo un maggior numero di stakeholder da soddisfare. Oltre a quello interno, colui che guida gli sviluppi è l’utente finale. In questo caso, insieme al team di design, si possono mettere in atto alcune tecniche che permettono di acquisire informazioni su come far evolvere una piattaforma in base alla volontà dell’utente.
Tra le principali tecniche suggerisco:
Dopo aver raccolto i dati qualitativi, il product manager è in grado di confrontarli con altri dati quantitativi, riguardanti il flusso dell’utente. Dati che possono essere raccolti attraverso dei sistemi di tracciamento (Google Analytics, Tableau, eccetera). Dall’incrocio tra questi dati, il product manager formula delle ipotesi che costituiranno la base della nostra roadmap. La roadmap viene infine prioritizzata utilizzando i sistemi precedentemente presentati come effort/impact matrix o RACI.
L’ultimo aspetto da considerare è la parte di testing e validazione. Nell’ambito B2B il testing di una nuova funzionalità viene portato avanti tramite l’utilizzo di un prototipo che risulta essere un “proxy” della soluzione finale. Durante una sessione di feedback organizzata con gli stakeholder, il prototipo viene impiegato per capire se il lavoro svolto finora è in linea con le aspettative e i problemi discussi.
Difficilmente nel B2B verranno impiegati dei test del tipo AB Test: è difficile raccogliere dei dati sufficienti per confermare il successo di una nuova funzionalità, e anche perché dovremo avvalerci di dati qualitativi per ottenere un feedback diretto. Questo approccio non esclude a priori l’utilizzo di sistemi di testing quantitativi, ma quest’ultimi tendono ad essere meno frequenti.
Durante la sessione di feedback si testa dunque il prodotto, avendo al contempo una sua validazione. Questo ci permette, in caso di esito positivo, di poter iniziare a lavorare sulla parte di sviluppo. Una volta rilasciata la nostra funzionalità, andremo ad utilizzare strumenti come Analytics e sessioni di feedback con gli stakeholder per ottenere un “continuous learning”. Queste sessioni ci permetteranno di comprendere come evolvere ulteriormente il nostro prodotto. Nel nostro caso, è capitato di fare anche “un soft launch”, ovvero rilasciare le nuove funzionalità a un numero di utenti selezionati e vedere il loro comportamento supportato dall’analytics della piattaforma.
Nell’ambito B2C l’approccio è focalizzato sull’utilizzo di dati quantitativi. Partendo dalle ipotesi già identificate, il product designer ci aiuta con la creazione di alcuni “low fidelity mock-up” che ci permettono di capire come le nuove funzionalità vengono posizionate all’interno di una pagina. Successivamente, è necessario organizzare un incontro con gli stakeholder per fare una prima validazione.
Questi mockup permettono dunque al team di prodotto di iniziare con la fase di sviluppo, dando tempo al product designer di realizzare i visual finali che verranno validati poi con gli stakeholder. Occorre evidenziare che sia i mock-up, che i visual finali non necessariamente si riferiscono a nuove funzionalità ma anche a miglioramenti o spostamenti di funzionalità preesistenti. Il tool per antonomasia per testare nel B2C è l’AB Test.
Questo ci aiuta a capire se una nuova funzionalità ha degli impatti positivi rispetto alla nostra north star di riferimento, ma anche a ottenere degli insight per poter evolvere e iterare successivamente. Non tutte le ipotesi che andiamo a testare si rivelano di successo, ma tutti i test possono portare a dei learning che ci permettono di iterare velocemente.
Vorrei evidenziare anche una similitudine tra i due ambiti, ovvero tutta la parte relativa alla discovery. Capire i flussi e i problemi che ci sono dietro un’esigenza è importante sia nel B2B come nel B2C. La parola chiave è iterare e far sì che la discovery sia continua sempre in entrambi gli ambiti.
Quello che notiamo infine è che la differenza principale si racchiude nel rapporto che si instaura con lo stakeholder e nella modalità di utilizzo di strumenti che possono essere impiegati in maniera differente. Ci tengo a dire che nonostante ciò, l’approccio rimane valido in entrambi gli ambiti e le diverse fasi di sviluppo sono condivisibili.
Ciao, sono Jasmine e sono Lead product manager in TUI Musement, dove coordino 3 diversi team specializzati nel flusso e2e del nostro customer. Ho iniziato il mio percorso nell'ambito project management nel 2016 nel settore della grande distribuzione. Dopo questa esperienza, se ne sono susseguite altre tra product e project management in diverse industry tra Italia e UK. Nel 2019 inizio come digital product manager in Musement dove ho avuto l'opportunità di lavorare in ambiti B2B e B2C.
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management