La Product Discovery come Mindset e non come processo

La Product Discovery come Mindset e non come processo

- di
La Product Discovery come Mindset e non come processo

“Una buona discovery è fondamentale”. “I Product Manager dovrebbero focalizzarsi di più sulla discovery che sulla delivery”. “La discovery dovrebbe essere continua e non una tantum”.

Tutte affermazioni corrette, non è vero?

Tuttavia, ho letto e sentito parlare di molte aziende che affrontano la discovery nel modo sbagliato. Mi riferisco a quelle aziende che:

  • Dedicano una quantità esagerata di tempo a scrivere documentazione su come i team dovrebbero fare discovery;
  • Usano la parola “Discovery” per tutto, tanto da farla quasi diventare una buzzword vuota e scontata (“I need a cup of coffee. Let’s do some discovery first!”);
  • Evangelizzano la Continuous Product Discovery , senza sapere cosa significhi realmente.

In questo articolo ti racconterò cosa significa per me “Product Discovery” e quali sono i problemi frequenti che ho visto e sperimentato sulla mia pelle. Ti darò inoltre qualche consiglio su come migliorare la Continuous Discovery nella tua azienda. 

La product discovery è un viaggio continuo, non un semplice processo. Può essere un mindset ed è importante capire come migliorare la continuous discovery nella tua azienda.

Cos’è la product discovery

Se cerchi “product discovery” su Google, troverai un sacco di definizioni. 

Roman Pichler sostiene che la “Product discovery si riferisce alle attività richieste per determinare il motivo e il perché un prodotto dovrebbe essere sviluppato”.

Tim Herbig la definisce così: “La Product Discovery descrive un processo iterativo che riduce l’incertezza che ruota attorno al problema o a un’idea per essere certi che il giusto prodotto venga costruito per il giusto pubblico”.

Il blog di ProductPlan invece: “Il processo di product discovery consiste in due fasi”.

Non sbagliano, ma mi preoccupa la terminologia e i rischi che l’interpretazione di certe parole come “attività” e “processi” possono comportare all’interno di determinate aziende. 

Marty Cagan, dice che la “product discovery significa affrontare i rischi che riguardano il valore, l’usabilità, la fattibilità, la redditività(..), e l’etica”, e questa è la definizione in cui credo. In sostanza, puoi affrontare questi rischi ripetutamente e in modi così diversi, che provare a definire specifiche e processi di discovery potrebbe rappresentare un forte limite, una possibile perdita di opportunità e un rischio di fallimento.

Product Discovery significa fondamentalmente rispondere alle seguenti domande:

  • Qual’è il problema più grande o “pain point” dei nostri utenti?
  • Gli utenti sceglieranno e capiranno come utilizzare una possibile soluzione?
  • Possiamo “costruire” una soluzione e far sì che questa funzioni anche per il nostro business?

Le persone credono che la product discovery sia qualcosa di nuovo, o che comunque esista da quando esiste il software. In realtà, dobbiamo tornare indietro di parecchi anni, a prima della nascita del software. Consideriamo, per esempio, alcuni innovatori della nostra storia; prendete nomi come Thomas Edison, Leonardo Da Vinci, Nikola Tesla, Galileo Galilei: cosa avevano in comune? Oltre ad essere individui straordinari, credo che avessero una mentalità che definirei di “scoperta”.

Hanno tutti creato soluzioni preziose, utilizzabili e fattibili per loro stessi e per gli altri partendo dai problemi, bisogni e cogliendo le opportunità. Non sono stati forniti loro approfonditi documenti su come intercettare i bisogni e trovare soluzioni. Non è stato detto loro come e quali idee validare. Dipendeva tutto dalla loro testa, dal loro ragionamento e dal loro approccio. Le stesse caratteristiche che si possono trovare nelle aziende innovative di oggi, come Apple, Google e SpaceX.

Cos’è la Continuous Product Discovery

Tornando ai tempi moderni, la continuous product discovery è forse qualcosa di nuovo. Comunque un concetto più recente.

La product discovery è spesso vista come una cosa una tantum: un preludio che anticipa la costruzione di qualcosa, un nuovo prodotto o una feature. Gli specialisti hanno cercato di risolvere questo problema introducendo il concetto di scoperta continua del prodotto, spiegando che la scoperta non finisce mai e che dovrebbe essere parte della nostra routine quotidiana come Product Manager. Teresa Torres è uno dei principali esperti e sostenitori di questo argomento, e si può imparare molto dal suo sito web producttalk.org o dal suo libro Continuous Discovery Habits.

Con la Continuous Product Discovery si entra in una sorta di loop infinito tra problem space e solution space: si analizzano i dati (qualitativi e quantitativi), si trova il problema giusto da risolvere, si testano le idee e si impara dai risultati. Ma attenzione, non si tratta di un percorso lineare da seguire passo dopo passo: dalla definizione del problema potreste aver bisogno di tornare indietro per analizzare il comportamento degli utenti, a volte potreste iniziare con un’idea, e solo dopo scoprire che effettivamente risolve un problema (oppure no). Ciò che conta di più è la velocità e la frequenza.

Perché la Continuous Product Discovery è così difficile

In teoria, la continuous product discovery del prodotto dovrebbe essere più facile della product discovery iniziale. Probabilmente avete alcuni utenti e state raccogliendo insight sia qualitativi che quantitativi. Tuttavia, ancora molte aziende combattono su questo fronte.

Nella mia (breve) esperienza ho visto spesso fare questi errori.

🕵️ Product Discovery significa User Research  

La “user research”, e in particolare la “generative research”, vale oro per la product discovery, ma c’è molto di più. Devi analizzare i dati comportamentali, raccogliere insight di mercato, inquadrare e dare priorità alle opportunità, generare ipotesi, eseguire esperimenti e validare le idee.

Se sei un Product Manager, o lavori in un team di prodotto, l’assenza di un UX Researcher non può essere un ostacolo. Certo portano valore, empatia e conoscenza, ma la loro assenza non dovrebbe diventare una “scusa” per non fare discovery.

Se “non avete abbastanza tempo”, significa che vi state concentrando su cose che considerate più di valore (ma hanno davvero valore per l’utente?). Se avete bisogno di trovare più tempo, iniziate a rifiutare le riunioni senza un’agenda e un obiettivo chiaro, promuovete la comunicazione e la documentazione asincrona, imparate e testate diverse tecniche, strumenti e framework e plasmate la vostra routine quotidiana per migliorare la product discovery.

🎯 Nessun outcome chiaro e definito   

Ho visto team testare idee senza aver chiara l’ipotesi principale da validare e la metrica (o le metriche*) da migliorare. “Testiamo questo, e poi vediamo come va!” è qualcosa che ogni persona di prodotto che ho incontrato ha detto almeno una volta (devo ammettere che sono colpevole anche io). Cerco di evitarlo assicurandomi che ogni idea abbia le risposte a queste domande:

  • quale problema, bisogno o desiderio dell’utente/cliente stiamo cercando di soddisfare/risolvere? 
  • come misuriamo il successo? 

*A mio parere, va bene considerare anche più di una metrica, ma è fondamentale definire la metrica di successo, e considerare le altre come metriche secondarie e/o di monitoraggio;

La product discovery richiede troppo tempo  

Questo succede quando si affronta la product discovery come processo.

Mentre avere un obiettivo è mandatorio, non puoi aver chiari tutti i passi da compiere in anticipo, così come non puoi metterci mesi a cercare problemi e trovare possibili soluzioni. 

In un paio d’ore si può:

  • leggere i ticket aperti al servizio clienti e trovare alcuni spunti
  • identificare alcune possibili soluzioni che potrebbero risolvere il problema più grande
  • intervistare le persone fuori dal tuo ufficio (o da casa) per capire se qualcuna di quelle soluzioni potrebbe funzionare

Sarai sorpreso di vedere quante “fantastiche” idee non supereranno questo terzo step.

👑 Qualcun altro decide il “cosa”  

Se vuoi demotivare il team di prodotto, questa è la modalità perfetta per farlo.

Immaginiamo di lavorare per Facebook e Mark Zuckerberg viene da noi dicendo “Le stories diventeranno la nostra prossima mission in Facebook. Cercate di validare velocemente e di trarne degli insegnamenti”

Anche se situazioni simili accadono in quasi tutte le aziende, e il Mark Zuckerberg della vostra azienda potrebbe avere ragione, questo è quando l’HiPPO sta schiacciando qualsiasi diversità di pensiero, strategia e visione.

Questa persona potrebbe avere l’appoggio di altre persone che condividono la stessa idea (situazione win-win), o nella maggior parte dei casi, non trovare persone favorevoli e con evidenze a supporto. Questo scoraggia, crea forte stress e genera ansia nel trovare del valore ad ogni costo, e porta a decisioni sbagliate nel breve, medio e lungo periodo. 

Non c’è una soluzione facile – devi trovare il modo di tenere questi Manager fuori dalle fasi di product discovery. I tuoi migliori amici ora sono gli insight qualitativi e quantitativi e le grandi doti comunicative;

🥰 Saltare troppo in fretta nelle soluzioni e… innamorarsene  

Qui vi sembrerò un po’ pazzo, ma sono più contento quando un mio esperimento fallisce, che quando ha successo. È come una doccia fredda, che mi riporta alla realtà e mi ricorda che gli utenti sono individui diversi, con differenti bisogni e modi di approcciare ad un problema. 

Tuttavia, è davvero facile innamorarsi delle proprie idee e fare di tutto per farle funzionare. Questo accade spesso quando i team non si concentrano con attenzione sui giusti problemi da risolvere, e hanno l’approccio “one-fits-all solution”.

Invece di pensare al successo o al fallimento di un esperimento, prova a concentrarti su ciò che hai imparato in entrambi gli scenari:

  • l’esperimento ha avuto successo – perché? Cosa devo imparare ancora?
  • l’esperimento è fallito – perché? Come ha interagito l’utente con la soluzione? Ci siamo rivolti agli utenti sbagliati?

💰 Troppa attenzione verso il business invece che all’utente  

Questo si verifica quando i team di prodotto danno priorità alle opportunità (e alla discovery) in base alle potenziali entrate che porteranno all’azienda. La discovery si trasforma in “chiediamo ai nostri clienti cosa vogliono“, o “il reparto vendite suggerisce X, Y e Z, per vendere di più“. 

Chiedete ai vostri clienti di descrivere i problemi che stanno affrontando, risolveteli, e vedrete arrivare i ricavi. Non chiedete soluzioni.

Cosa si può fare per migliorare la Product Continuous Discovery

Tutto dipende dal tipo di azienda e dalla conoscenza che il team di prodotto ha di questo argomento. In generale, se credete veramente nella product discovery come leva di crescita e di successo tra i competitor, questo è probabilmente quello che dovete iniziare a fare, o migliorare:

  • Definire un generoso budget dedicato alla product discovery, e per ogni team (cioè: persone, strumenti, coupon per interviste agli utenti e user test, ecc);
  • Libero accesso ai dati, che devono essere rilevanti e affidabili e, se necessario, richiedere supporto esterno per interpretare i numeri;
  • Permettere ai PM, e ai team in generale, di stare in contatto con gli utenti e i tutti i giorni; se i Product Manager hanno tutto il necessario per analizzare i feedback degli utenti e contattarli, avete già fatto un buon lavoro;
  • Creare un repository per raccogliere e condividere tutti gli insight in incontri bisettimanali o mensili dedicati;
  • Celebrare i PM per quello che hanno scoperto e non solo per averlo consegnato;
  • Educare e allenare le persone su cosa sia realmente la Product Discovery e aiutarle a vedere le cose da una prospettiva diversa;
  • Last but not least, assumere esploratori.

Key takeaway

La continuous product discovery è complessa, non ha mai fine ed è la principale fonte di apprendimento. Non ha bisogno di processi, strumenti e documentazione. Ha bisogno invece di esploratori, persone con un obiettivo e curiose di capire il senso delle cose. Ha bisogno di leader che puntano a costruire un mondo migliore e sono disposti a migliorare la vita delle persone

Strumenti e processi possono aiutare all’inizio, ma non ti basteranno. Questo potrebbe sembrare strano, ma la verità è che è necessario creare e coltivare un vero mindset di discovery.

Spero che questo articolo vi sia piaciuto e sia stato utile. Non esitate a darmi dei feedback o a farmi domande nei commenti qui di seguito. È anche per me un’occasione per impararare.

Qui trovi la versione originale in Inglese dell’articolo Product Discovery Is A Mindset, Not A Process.

Se l’articolo ti è piaciuto iscriverti alla Newsletter.

Riceverai direttamente nel tuo inbox i nostri articoli insieme a tante altre sorprese 😉

Le slide sono disponibili per studenti ed ex studenti del Master in Product Management

Accedi a "Agile Starter Kit" Gratis

Iscriviti alla newsletter e accedi ad Agile Starter Kit: la cartella che contiene oltre 70 pagine su Agile, Scrum / Kanban, Organizzazione Team, User Story, Backlog, e tutto ciò che ti serve per partire.

Scarica il post sulle alternative a Scrum

Iscriviti alla newsletter e scarica gratuitamente il post "Agile Scrum: Alternative più flessibili e agili"