Ottobre 12, 2020 - di Marco Imperato
Product Discovery: cosa è, il metodo, come organizzare il team
In questo post scoprirai cosa è la Product Discovery e come integrarla nei tuo processi di sviluppo prodotto.
Ho scritto questo post con Katia Cassano, Global Product Management e Product Lead in Paypal che, oltre ad aver lasciato una preziosa testimonianza su come integrare i processi di product discovery, mi ha dato una grande mano nell’organizzazione dei contenuti.
L’articolo è diviso in due parti: la prima riguarda la teoria e il metodo, nella seconda parte ci si focalizza invece sull’organizzazione del team.
Ecco Cosa troverai:
- La Product Discovery: Teoria e Metodo
- La prima volta con la Product Discovery
- Agile, Product Management e Discovery
- Mindset e Product Discovery
- Cosa è la product Discovery?
- Product Discovery, User Story e Product Backlog.
- Product Discovery e Feature Discovery
- Product Discovery Continua
- Tecniche di product Discovery: The double Diamond Approach
- Product Discovery: Implementarla senza impazzire (troppo)
Cosa non troverai:
Non andremo a fondo sulle diverse tecniche, ma ne abbiamo già parlato abbondantemente qui:
- MVP: Minimum Viable Product
- User Research: quando e come parlare con i tuoi utenti
- Intervistare i tuoi utenti, perchè devi farlo subito
Se vuoi scaricare il post che stai leggendo in PDF e accedere ad oltre 100 pagine su Agile, Team Cross-funzionale, Scrum/Kanban, Backlog, etc. ti presento Agile Starter Kit, una cartella condivisa su Google Drive pensata per gli eroi come te che stanno iniziando il proprio viaggio nel Digital Product Management.
Se hai già accesso alla cartella troverai direttamente lì il post in PDF.
La prima volta con la Product Discovery
La prima volta che ho letto questa espressione onestamente non capivo bene cosa fosse e a cosa servisse.
“Product discovery is about coming up with something that is worth building and delivering. Very specifically, the output of product discovery is a validated product backlog.”
L’ho scoperta su SVPG (grazie Marty, senza di te non so come avrei fatto a capire come funziona il Product Management) e l’ho trovata molto interessante, ma facevo davvero fatica a capire come potessi applicarla al mio prodotto e al mio team.
Io avevo il mio bel Product Backlog pieno di storie super precise con acceptance criteria e specifiche perfetti. Alcune storie erano già state pesate alla perfezione da sviluppatori e designer che avevano calcolato meticolosamente quanto tempo avrebbero impiegato.
Eravamo una perfetta e ben oliata Fabbrica di Funzionalità: organizzati al meglio per analizzare, progettare, sviluppare e mandare in produzione qualsiasi feature venisse decisa.
È stato molto difficile comprendere il nuovo Paradigma.
Dopo tutto, la fase di start-up l’avevamo ormai superata: sapevamo esattamente quello che dovevamo fare.
Era falso.
Era troppo difficile accettare che tutto quello che c’era scritto in backlog era solo e soltanto un insieme di ipotesi, e che se anche ormai avevamo superato la fase di Start-up, non avevamo la più pallida idea se la feature Y, o il redesign X avrebbe avuto l’impatto che ci immaginavamo.
Usavamo Scrum e questo sembrava bastare. Sulle metodologie Agile, visto che ne parliamo tanto qui su Product Heroes, è necessaria una precisazione.
Agile, Product Management e Discovery
Agile e le varie metodologie come, Scrum e Kanban, sono ottimi strumenti di Project Management. Devi assolutamente conoscerli, e sono una parte importante del tuo lavoro, ma hanno davvero poco a che vedere con il Product Management.
Essere in grado di organizzare un team o preparare una Sprint è la base, devi saperlo fare. Punto. Ma non è questo che fa la differenza.
La differenza in un buon Product Manager la fanno: l’Outcome che è in grado di generare lavorando con il team, Il Why su cui lavora, il problema che sceglie di risolvere, le informazioni che riesce a tirar fuori dagli utenti, come comunica e negozia con gli stakeholder (soprattutto!), le metriche che scegli di muovere, etc.
Non è sufficiente usare dei framework Agile: puoi fare la migliore estimation di sempre o essere cintura nera di sprint planning ma se non validi sistematicamente tutto quello che vuoi portare in sviluppo e poi in produzione, stai soltanto facendo del buon Project Management.
La cosa più strana è che la maggior parte dei team ne hanno consapevolezza, ma c’è sempre una scusa per saltare la parte di validazione:
- Siamo pochi (l’avrai sentito ripetere decine di volte in team di 3, 30 o 300 persone).
- Abbiamo esperienza. Sappiamo cosa vuole l’utente.
- Non c’è bisogno.
- Siamo in ritardo.
Mindset e Product Discovery
Prima di procedere per me è molto importante ricordarti che è sempre una questione di mindset e di consapevolezza: se tu e il tuo team non accettate che tutto quello che avete in mente da rilasciare sono solo idee e che pertanto vanno prima validate, non ha senso che continui a leggere.
Ho visto troppe ottime idee che avevano tantissimo senso (per noi) avere zero impatto sugli utenti.
Quel che conta è il tempo che impieghi a capire se ha senso portare un’idea in produzione, rispetto alle metriche che vuoi impattare.
Il cambio di Mindset è cruciale: il team non viene più valutato sugli Output che produce, ma sull’Outcome.
Cosa è la Product Discovery?
La Product Discovery è un insieme di tecniche e processi il cui obiettivo finale è la riduzione del rischio di insuccesso nello sviluppo di un prodotto digitale.
Esistono diversi tipi di rischi a cui si va incontro quando si creano nuovi prodotti. Eccone alcuni:
- Vogliamo risolvere un problema che non importa a nessuno
- Il problema è importante ma per pochissime persone
- Stiamo implementando una soluzione molto complicata da utilizzare
- Stiamo progettando un prodotto la cui realizzazione potrebbe richiedere troppe risorse
- Problema e Soluzione funzionano, ma il business model non è sostenibile
È semplice: se stai facendo delle cose per la prima volta il rischio che tu ti stia sbagliando è molto alto. Inoltre, anche se nei processi di discovery avrai trovato idee/feature/problemi su cui ha senso muoversi in avanti sai che saranno necessarie varie Iterazioni per creare qualcosa che abbia realmente impatto su scala.
Integrare la Product Discovery nei tuoi processi ti aiuterà a capire quale strada seguire sprecando il meno possibile.
Se dovessimo sintetizzare al massimo potremmo dire che l’Outcome della Product Discovery è una maggiore conoscenza del Customer, ricordandoci che solo e soltanto partendo dal customer il nostro Product Backlog avrà senso.
Tre diverse categorie di Product Discovery
Qui Katia ci aiuta a fare chiarezza introducendo la sua personale classificazione:
“Esistono diversi livelli di product discovery a seconda dell’ obiettivo che si vuole raggiungere.
La mia classificazione quindi e’:
1) Test problem: Problem/Need Discovery focalizzata sulle opportunità di mercato
2) Test Solution: Feature Discovery focalizzata sulla validation di funzionalità o MVP legate al valore percepito dal consumatore.
3) Test Business Model: Business Model Discovery che si focalizza sul test delle ipotesi di business.
Queste 3 categorie racchiudono diverse attività e diverse metodologie.
Product Discovery, User Story e Product Backlog.
Una delle parti che mi ha lasciato più dubbi, in passato, era il rapporto tra Product Discovery, User Story e Product Backlog, ovvero: cosa viene prima?
Più avanti vedrai alcuni consigli su come organizzare il lavoro, ma per semplificare possiamo dire che prima di scrivere una User Story sul product Backlog dovremmo validarla con la Product Discovery.
Non si tratta di superca**ole! Prima di scrivere:
COME Utente VOGLIO pagare con Apple Pay PERCHÈ è il sistema più comodo per pagare online.
Dobbiamo assicurarci che questa informazione sia vera o quantomeno dobbiamo capire qual è il rischio che stiamo sostenendo nel momento in cui manderemo in sviluppo una funzionalità di questo tipo.
Feature Discovery e Product Discovery
Come avrai letto non tutte le attività di product Discovery sono finalizzate alla validazione della soluzione, ma sicuramente la validazione della soluzione è una delle parti sui cui spesso i Team fanno fatica a capire come organizzarsi. Su questo quindi spenderemo qualche parola in più.
Nel caso delle Feature l’Outcome della Product Discovery è un Backlog Validato.
L’output, come vedremo, può essere di vario tipo.
La Feature Discovery raccoglie una serie di attività che servono a capire quale feature ha senso sviluppare per avere il massimo impatto sui tuoi utenti. Queste attività solitamente includono prototipazione, user testing, MVP e altre.
Product Discovery Continua
La Product Discovery non è un processo lineare e sempre uguale, ma varia in base a un numero indefinito di elementi come la maturità del prodotto su cui stai lavorando, i segmenti a cui ti rivolgi, il mercato, il team con cui lavori, etc.
La prima cosa che devi avere chiaro al di là delle singole attività che puoi svolgere è che la Discovery è un processo continuo: non smetterai mai di conoscere il tuo customer, di imparare di più sul problema che vuoi risolvere,
La tendenza che abbiamo è di concentrarci sullo sviluppo della soluzione non appena abbiamo prove ragionevoli che sia quella giusta, ma la domanda che ti devi continuamente chiedere è “Stiamo lavorando sull’opportunità più significativa?”.
Tecniche di product Discovery: The Double Diamond Approach.
Utilizzo da molti anni The Double Diamond Approach che si compone in 2 macro aree:
- Identificazione e definizione del problema (problem discovery)
- Sviluppo e scelta della soluzione (solution discovery)
Identificazione e definizione del problema
Per prima cosa, bisogna definire un piano di apprendimento sulla base delle seguenti attività:
- Consolidare le informazioni inerenti all’utente e raggrupparle per temi (consiglio vivamente di organizzare un workshop con il proprio team e key stakeholder).
- Associare ad ogni informazione la categoria della fonte di provenienza (dati, opinioni e ipotesi).
- Infine, raggruppare le fonti per singolo tema e identificare i temi che hanno il numero più alto di ipotesi. Questi saranno le vostre priorità su cui focalizzare il processo di discovery.
Il passo successivo riguarda la preparazione dell´intervista in cui bisogna definire un’introduzione e un questionario.
Come si scrive un questionario? Qui di seguito un esempio:
- Organizzare un brainstorming con il proprio team in cui ogni persona scrive su un foglio le domande inerenti al tema selezionato;
- Confrontare le domande e raggruppare quelle simili;
- Stilare la lista finale (ricorda di formulare domande aperte come, ad esempio, “parlami di …” e spesso usare l’avverbio “perché”).
Condotta l’intervista, abbiamo tutte le carte in tavola per definire il problema (problem statement).
Ecco il template che uso e che mi permette di inserire le informazioni consolidate durante le interviste:
Io sono… (intervistato) e mi sento… (sentimenti negativi) in quanto ho… (bisogno) perché…(ostacolo).
Sviluppo e scelta della soluzione
Una volta definito il problema (problem statement) su cui si vuole investire tempo e risorse, si è pronti per la seconda fase, Solution Discovery, in cui bisogna prototipare la soluzione scelta e testarla.
Esistono vari metodi di prototipazione quali, ad esempio:
- Storyboard con foto e/o schizzi e testi descrittivi.
- Bozze di pagine web.
Raccomando di non perdersi nei dettagli ma essere rapidi nel costruire il prototipo in quanto, nel caso in cui non rispecchiasse le esigenze degli utenti, si dovrà ripetere il processo dall’inizio.
Nel corso della mia esperienza lavorativa, condivido il fatto di aver scartato moltissime idee che sembravano ottimali, ergo consiglio vivamente di velocizzare l’iter creativo/ progettuale affinché si possa testare il prodotto nel minor tempo possibile, confermando o escludendo la soluzione prescelta.
Non sorprendetevi se, talvolta, il prototipo non soddisfi le aspettative dell’utente in quanto
bisogna essere sempre predisposti ad accettare l’eventualità di un fallimento, dato che e´ parte integrante del processo di apprendimento.
Quanto deve durare la Product Discovery?
Riguardo la durata, a differenza di quello che si trova scritto online in cui ognuno vuole vendere il proprio framework, non esiste un tempo definito: dipende da che tipo di discovery si vuole fare e dalle risorse a disposizione
Il problema principale nell’applicare la Product Discovery
Il Problema principale che riscontro non è tanto la mancata comprensione di quanto sia importante la Product Discovery, solo un pazzo potrebbe pensare che sia inutile, quanto il modo in cui viene implementata.
Invece di utilizzare una o due persone che lavorano su un prototipo per un paio di settimane le aziende utilizzano un intero team di ingegneri per sviluppare, testare e rilasciare il prodotto in produzione. Questo è il motivo per cui spesso si impiegano un gran numero di release per avere un prodotto che abbia senso.
Citando Marty Cagan
le aziende tipicamente utilizzano il team di sviluppo per costruire un prototipo estremamente costoso e usano i loro clienti reali come tester inconsapevoli.
L’obiettivo di questo post è proprio quello di darti due esempi pratici che ti possono aiutare ad organizzare il tuo team per avere il massimo impatto.
Team e Product Discovery: come organizzarsi
Nei miei anni come CPO ho impiegato la maggior parte del tempo nel trovare la giusta organizzazione per i team che gestivo. Alla fine il successo di un prodotto dipende dalle persone che ci lavorano e il successo delle persone è inversamente proporzionale all’ambiguità organizzativa.
Obiettivi chiari e rimozione di problemi inutili (quelli organizzativi tipicamente) sono sempre stati tra le mie priorità principali dal momento in cui ho iniziato a gestire più di 8 persone.
Sotto le otto persone puoi ancora fare un po’ di improvvisazione, superata quella soglia per me, se non ti organizzi bene rischi di trascorrere più tempo a spegnere incendi che ad avere impatto.
Ho fatto diversi tentativi, ispirandomi e leggendo a fondo chi l’aveva già fatto prima di me (trovi alcune fonti in fondo al post), per integrare la product discovery nei processi di sviluppo prodotto.
Queste che leggi sono le due modalità che per me hanno funzionato meglio. Il principio di base però resta sempre lo stesso
The whole team is responsible for product outcomes, not just on-time delivery
“Stop & Learn” con Team Unico
Quando hai un unico team di sviluppo c’è poco da fare: se vuoi costruire un prodotto che abbia impatto non puoi impiegare l’intera “capacità” del team nel “solo” sviluppo di nuovo software.
Immaginiamo che il tuo team sia composto da 5 persone (2 Back-End, 1 Front-end, 1 Designer, 1 Product Manager), e che tu stia usando Agile Scrum.
In questo caso il mio consiglio è di fermarsi dopo ogni Release/Sprint (dipende da come lavori) e di dedicare del tempo alla Product Discovery. Immaginiamo che un processo medio di Discovery duri sette giorni lavorativi e che il Discovery Team sia composto dal Product Manager, il Designer e uno sviluppatore.
Durante quei sette giorni succederanno tre cose:
- Il Discovery Team lavorerà sulla discovery di una nuova idea/opportunità. In questo post trovi anche come capire su quale nuova opportunità ha senso lavorare.
- I due sviluppatori fuori dal team di Discovery lavoreranno su bug fixing o minor improvement, consiglio sempre di far ruotare il team di Bug Fixing.
- Il Product Manager oltre a lavorare sulla Discovery inizierà a capire se quanto rilasciato nella release precedente e che è già stato validato grazie alla Discovery precedente ha un reale impatto, in base alle prime metriche registrate e ai Key Result definiti.
Trascorsi i 7 giorni di Discovery ci sono due possibilità:
- Avremo una parte del Backlog Validato che ha senso mandare in sviluppo e quindi può iniziare la sprint o la release.
- Il processo di Discovery avrà dimostrato che non ha senso portare avanti una determinata feature.
La domanda che sorge spontanea è: ma quindi se faccio 3 discovery che non portano il risultato sperato e che quindi non mi danno l’evidenza che qualcosa possa avere impatto, tengo bloccato il restante team di sviluppo?
La domanda che ti faccio io è: il tuo obiettivo è far lavorare gli sviluppatori per costruire feature (Output) o creare un prodotto che abbia impatto sulle metriche che hai definito (Outcome)?
Team unico: Empowered Teams
Questa è la variante sul Team unico che preferisco. Ne ha parlato Silvana qui e si tratta di dare piena delega al team sul come e quando fare Discovery.
Il team ha un obiettivo di Quarter definito tramite OKR, non è obbligato a rilasciare un certo numero di feature, ma ha il solo obiettivo di muovere le metriche che sono state definite. Quanto stare nel Problem Space (Discovery) o nel Solution Space (Delivery) lo decide il team.
Il team decide come organizzarsi: Scrum, Kanban, niente, è libero di rilasciare in produzione, di eseguire test sugli utenti, etc.
Questo tipo di organizzazione ha senso solo su prodotti più maturi in cui il CEO ha ormai delegato completamente la responsabilità di prodotto ed è stato dedicato del tempo (tanto tempo) per costruire una cultura di fiducia, fallimento, iterazione, ownership.
Non lo fai dall’oggi al domani e il team deve essere già rodato.
Per farlo funzionare ricordo che una delle migliori soluzioni è stata quella di creare un luogo fisico in cui il team cross-funzionale potesse lavorare insieme e soprattutto non chiedere continuamente “a che punto siete?” :).
Agile Dual Track
Semplicemente Discovery e Delivery avvengono parallelamente nella stessa sprint, flusso o release.
[Se vuoi approfondire su Agile puoi farlo da qui.]
Questa soluzione ha senso se hai team più grandi e soprattutto più maturi, in termini di esperienza sia di delivery che di discovery. Un Team o una parte di Team (ora vedremo) cerca di capire cosa ha senso portare in Backlog, l’altra parte si occupa invece di sviluppare quello che c’è in Backlog.
Questa illustrazione di Jeff Patton rende perfettamente l’idea.
3, 2, 1…
Fighissimo! Ma come cacchio faccio?
Questa è stata la mia reazione quando ho visto per la prima volta questo schema. Come sempre mi venivano promesse soluzioni ai problemi che avevo, ma non mi veniva mai detto come.
Per fortuna adesso c’è qualcuno che si è già sbattuto per capire come fare e ti dirà cosa ha funzionato per lui.
Dal Dual Track al 5-3-2
Personalmente ho provato varie soluzioni e vari incastri, ma quello che ha funzionato meglio per me, sul mio prodotto, in Italia, nel mondo reale si chiama 5-3-2 (ne ho parlato già qui sul Bug Fixing).
La premessa è che non avevo la possibilità di dedicare un intero team di 2-3 persone alla discovery quindi dovevo capire, in quattro team cross-funzionale di 6-8 persone, come integrare discovery e delivery.
Gli obiettivi erano due:
- Sviluppare solo ciò che avevamo già validato
- Rilasciare soluzioni “robuste” e scalabili
Era un Prodotto B2B Multi-Sided Marketplace, che aveva da centinaia a migliaia di utenti per ogni “lato”.
Come funziona la 5-3-2?
Fatta 10 la Capacity del team dedichiamo:
– 5 unità alla Delivery
– 3 alla discovery
– 2 al Bug Fixing.
Per me non è importante il 5-3-2 che puoi far diventare 4-3-3, 3-3-4 o 1-1-8 (se sei assalito dai Bug), ma passarti il concetto che devi decidere “dove mettere il tempo” del tuo team e devi disciplinare il processo.
La Discovery può essere lato Customer o lato Tech (Spike). In base al goal della discovery per ogni sprint vai ad allocare “ore uomo” alla discovery.
Esempio:
- per la prototipazione su Invision o XD, di solito lavoravano UX + Front-end così che anche in fase di progettazione iniziassimo a prendere in considerazione l’effort necessario.
- su MVP di solito lavoravano PM, FE o BE, e UX, così, nel caso di MVP si lavorava su soluzioni “brutte”, ma comprensibili e che poi eventualmente si sarebbero potute sviluppare in un tempo normale (non infinito).
- Su Spike erano sempre ed esclusivamente allocate figure Tech
- Su Inteviste, sempre PM e a giro altre figure del team in base al tipo di insight che si ricavava.
Alcune regole:
- Ownership: ogni singola attività di discovery, bug fixing o delivery va portata in Sprint backlog e assegnata a un owner anche se le attività coinvolgono più di una persona.
- Disciplina: rispetto a un team che si occupa solo di delivery con il 5-3-2 la complessità aumenta esponenzialmente. È importante che il team comprenda la necessità di essere disciplinati e monitorare ogni singola attività sulla board condivisa che sia Jira, Phabricator, Asana, etc.
- Estimation: l’estimation viene fatta anche per la discovery. È un po’ complesso all’inizio perchè si tratta di smontare l’attività in tante microtask, ma nel lungo termine ci si abitua.
Esempio per un intervista:
1. Raccogliere 20 customer > 4 SP
2. Preparare Script > 2 SP
3. Contattare Customer e Calendarizzare le interviste > 8 SP
etc.
All’inizio è veramente tosta. Ci abbiamo messo mesi per trovare un nostro ritmo, ma dopo è una figata: l’intero team è responsabile per gli outcome di discovery e delivery.
Attenzione: non ti aspettare un sistema oliato e rodato che girerà senza problemi (così per me non è stato), ma qualcosa di simile al Managed Caos di Eric Schmidt
Qui di seguito trovi un paio di slide di esempio che ho usato pe presentare il nuovo modello ai team.
Ecco alcuni Link di Approfondimento
2 replies on “Product Discovery: cosa è, il metodo, come organizzare il team”
Michele Paterniti
Mi domando se in questo contesto gli sviluppatori sono contenti di lavorare sulla discovery o se, invece, non sia difficile coinvolgerli in una attività a basso contenuto tecnico.
Marco Imperato
Ciao Michele, grazie per la domanda. All’inizio del mio percorso avevo lo stesso dubbio, poi, strada facendo, ho capito che nella maggior parte dei casi gli sviluppatori vogliono anche partecipare al processo di creazione del prodotto. Dipende dai profili, come in tutti i lavori, ma ho visto un grande cambiamento in meglio nel momento in cui anche gli sviluppatori, come i designer, si sentivano la responsabilità di quello che stavano costruendo, ovvero non erano “cose decise da altri”.