Scrum, Kanban, framework, processi e metodi sono tutti ottimi strumenti di lavoro. Ma ciò non basta. Per fare la differenza come Product Management devi saper far tesoro dei feedback dei clienti, stabilire una buona comunicazione col team e con gli stakeholders, lavorare sull’outcome e sul vantaggio che il prodotto apporterà all’utente. Per fare tutto questo devi testare e validare ciò che porti in sviluppo. Non farti fregare dalla fretta o convincere dalla troppa sicurezza del team, potresti incorrere in brutte sorprese.
Product Discovery, cos’è.
Con product discovery si intendono tutti quei processi e quelle attività che permettono di condividere all’interno del team un’immagine chiara del progetto da sviluppare. La product discovery esplora il prodotto, i suoi requisiti, portando così il progetto nella giusta direzione ancor prima di svilupparlo.
L’obiettivo della product discovery è quindi proprio quello di ridurre il rischio di insuccesso nello sviluppo del prodotto. Sviluppare un nuovo prodotto comporta infatti rischi diversi. Qualche esempio?
il prodotto non risponde a un bisogno, il prodotto punta a risolvere un problema che il consumatore non ha o non si pone;
il prodotto è apprezzato ma dalla nicchia della nicchia della nicchia...
il prodotto pecca nell’usabilità, è molto complicato;
la realizzazione del prodotto richiede una spesa non sostenibile.
Questi sono solo alcuni dei tanti rischi che potrebbero manifestarsi.
La product discovery ci aiuta a comprendere quale strada seguire. Può focalizzarsi su più aspetti: sulla richiesta/necessità e quindi sul mercato, sulle funzionalità e quindi sul valore percepito dall’user, sul business e quindi sul testare le ipotesi del modello di business.
Nella frenesia, tutti i giorni inciampiamo in errori diversi o entriamo in confusione. Ricordati che la tua migliore alleata è la chiarezza. Mantieni quanto più possibile l’ordine: prima di scrivere e sviluppare una user story assicurati di validarla con la product discovery. La validazione è sempre una parte molto delicata non solo per la sua importanza ma anche per come viene organizzata e gestita.
Product Discovery, perché.
Oggi più che mai viviamo un momento in cui i prodotti usabili ma inutili stanno affollando i nostri contesti. Le features e i bisogni sono stati scavalcati dall’usabilitá, dal design e dalla semplicità dei prodotti stessi. Ecco che qui entra in gioco la product discovery e l’urgenza di metterla in pratica: prima di sviluppare nuovi prodotti è necessario azionare tutti quei processi che esplorano il prodotto, lo scoprono prima di svilupparlo. Come? Inquadrando il problema che il mio prodotto andrà a risolvere, comprendendo come risolverlo e valutando più strade per farlo e infine mettendo tutto a punto anzi a progetto, pianificando e prioritizzando feature da sviluppare.
Attraverso una buona product discovery sarà possibile comprendere quale feature sviluppare e a quale dare la priorità. Non immaginare un processo limitato e incasellato nel tempo: la discovery accompagna il prodotto nella sua evoluzione. Pensaci: non si smette mai di imparare e non si smette mai di conoscere. Il cliente, il mercato, il prodotto stesso.
“Se avessi un’ora per risolvere un problema, utilizzerei 55 minuti per pensare al problema e 5 minuti a trovare la soluzione”,diceva Albert Einstein.
Non aver fretta di arrivare alla soluzione, di arrivare a risolvere il problema: guardalo, conoscilo, innamorati del problema stesso e agisci solo dopo averlo davvero compreso. Stai con il problema, conoscilo, riconoscilo in ogni sua parte e comportamento: solo dopo averlo compreso potrai davvero risolverlo.
Product discovery, le tecniche.
The Double Diamond Method è uno dei metodi più famosi per mappare il processo progettuale. Sviluppato dal Design Council, permette di progettare, prototipare e testare la soluzione scelta. Come? Attraverso quattro fasi chiave:
Discovery: la scoperta e l’identificazione del problema. Qui si definisce il contesto, si conosce l’user e i suoi reali bisogni. Le informazioni relative all’utente devono essere raccolte e organizzate: raggruppate per tematica, classificate come fonte (dato reale, feedback, ipotesi da verificare), prioritizzate in base al numero di ipotesi se alto maggior priorità.
Define: si definiscono soluzioni basate sulla discovery. Si analizzano i dati raccolti, elaborando le possibili soluzioni. In questo step si inizia a prototipare la soluzione scelta fino a verificarla e quindi testarla con l’utente.
Development: nella fase di sviluppo si sviluppano e testano le potenziali soluzioni. È una fase iterativa che permette di esplorare, sperimentare, fallire ed imparare.
Delivery: in questa fase finale il prodotto viene affinato e rilasciato.
La complessità della product discovery, come anticipato prima, sta nel gestire il team e organizzare il lavoro. Erroneamente le aziende non impiegano due o tre risorse per la discovery e la prototipia del nuovo prodotto ma un intero team di sviluppo: ciò porterà a realizzare un prototipo estremamente costoso ancora da testare.
Quindi come integrare la product discovery al processo di sviluppo del prodotto? L’unica strada possibile è un’ottima organizzazione ma puoi usare metodi diversi.
Organizzazione 1
Se hai un solo team di sviluppo non puoi certo impiegarlo solo sullo sviluppo del nuovo prodotto ma puoi dedicare parte di esso alla discovery.
Si può raggruppare un piccolo discovery team di tre professionisti (PM, sviluppatore e designer) e concentrare il loro lavoro sulla discovery del nuovo prodotto. Oltre alla discovery, il PM inizierà a raccogliere feedback e capire se ciò che è già stato validato ha un reale impatto mentre sviluppatori esterni al discovery team fixano i bug. Tutto questo porterà a:
Feauture validate e quindi mandare avanti lo sviluppo del prodotto
Impatto negativo quindi insensato da portare avanti
Organizzazione 2
L’empowered team, ovvero un team autonomo e maturo, responsabile e intraprendente. È il team stesso in questo caso a scegliere come e quando fare discovery. Questa modalità funziona nei team già rodati, dove alla base è già stata costruita una forte cultura di fiducia e intesa.
Organizzazione 3
Il Dual Track o binario parallelo. Secondo questa tecnica il team gestisce la discovery e la delibera nella stessa release. Una parte del team studia quindi le feauture da portare in backlog, l’altra sviluppa. Per integrare al tuo unico stesso team la discovery e la delivery devi avere ben chiaro dove investire il tempo e organizzare al meglio ogni attività. Prima di sviluppare il team non deve mai dimenticarsi di validare: solo da ciò possono nascere reali soluzioni.
Come nel calcio anche nella product discovery si schiera la propria squadra, il proprio team seguendo un modulo: il 5-3-2.
I 5 difensori saranno i 5 professionisti dedicati alla delivery, i 3 centrocampisti saranno gli schierati alla discovery e i 2 attaccanti si dedicheranno invece al bug fixing.
Per fare tutto ciò serve come già ribadito una massima organizzazione. Ogni attività di discovery da portare avanti va necessariamente inserita nella sprint backlog e assegnata a un PO, così che il team avrà gli strumenti per monitorare l’avanzamento del progetto.
Anche in questo caso vale l’estimation: ogni stories viene quindi pesata e smontata.
Dopo aver letto tutte queste informazioni sarà comunque tosta iniziare? Sí. Ma come diciamo spesso “chi ben comincia è a metà dell’opera”, quindi inizia a sperimentare e trova con il tuo team il tuo metodo.