Il Processo di Scoperta del Prodotto
La scoperta del prodotto è il processo di comprendere i tuoi utenti, identificare le loro difficoltà e trovare soluzioni che sai li aiuteranno.
A seconda della qualità dell’attività di discovery che svolgi, potrai determinare il successo o il fallimento della tua attività. La logica è semplice. Con una grande discovery del prodotto, finisci per sviluppare funzionalità di cui le persone hanno davvero bisogno e per cui sono disposte a pagare. Una cattiva discovery, invece, presuppone continue nuove funzionalità di cui nessuno sente la necessità.
Questo può sembrare molto travolgente, soprattutto considerando la quantità di input nella discovery del prodotto. Ma esiste un buon sistema per gestire questo compito cruciale, grazie a una varietà di strumenti e framework.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Quindi, capiamo cos’è la discovery di prodotto e come svolgerla al meglio.
Cos’è la scoperta del prodotto?
La scoperta del prodotto è il processo in cui si comprendono le difficoltà degli utenti e si trovano soluzioni valide per colmarle.
Questo processo di solito è molto diverso da come se lo immaginano i tuoi stakeholder. Per molti di loro si tratta di pensiero creativo e di stilare una lista di funzionalità interessanti una volta sola, per poi costruire il prodotto basandosi su quella lista.
Questo pensiero è sbagliato in 2 aree fondamentali:
- La discovery è un processo iterativo e senza fine. Non si conclude la discovery, si chiude un ciclo e si inizia il successivo.
- La discovery non consiste nell’inventare creativamente idee interessanti. Consiste invece nel capire i bisogni degli utenti, elaborare soluzioni in grado di risolverli e poi validare che queste soluzioni funzionino effettivamente.
Un altro errore comune riguarda il rapporto tra discovery e delivery. Molti stakeholder le vedono come due fasi separate che vengono una dopo l’altra. In realtà, i team di sviluppo prodotto efficaci svolgono discovery e delivery in parallelo. Mentre il tuo team consegna le funzionalità scoperte due mesi fa, tu stai già facendo discovery per il prossimo set di funzionalità.
Visuale:
- Diagramma a biforcazione “Discovery vs. Delivery”. Visualizza questa idea: i team svolgono discovery e delivery in parallelo. Mentre il tuo team consegna le funzionalità scoperte due mesi fa, tu stai facendo discovery per il prossimo set di funzionalità.
- Alt: “Tracce parallele che mostrano discovery e delivery continue.”
- Didascalia: “La discovery di prodotto non è un evento unico — procede insieme alla delivery.”
Anche se ti trovi in un mercato in cui lo sviluppo a cascata è la norma e la discovery precede la delivery, è sempre fondamentale prestare la massima attenzione alla discovery, poiché la sua qualità influenzerà direttamente il successo del prodotto.
Perché la discovery è un vantaggio competitivo
La risposta breve sarebbe questa. Grazie alla discovery, comprendi meglio le tue personas e i bisogni degli utenti, e riesci così a proporre soluzioni efficaci. Disporre di soluzioni efficaci ti rende un concorrente forte sul mercato, visto che acquisisci velocemente e mantieni facilmente i clienti.
Per la risposta lunga, diamo un’occhiata a Inspired di Marty Cagan. Nel libro, Marty sottolinea che una discovery efficace ti aiuta a mitigare 4 tipi di rischi:
- Rischio di Valore: si riferisce alla possibilità che le persone non usino il tuo prodotto perché per loro non ha alcun significato.
- Rischio di Usabilità: si riferisce alle difficoltà delle persone nell’usare il tuo prodotto.
- Rischio di Fattibilità: si riferisce alla possibilità che il tuo team non riesca a svilupparlo.
- Rischio di Viabilità: si riferisce alla capacità del prodotto di aiutare la tua azienda a sopravvivere e prosperare.
Se riesci a mitigare tutti questi rischi e i tuoi concorrenti falliscono anche solo in uno, ottieni un forte vantaggio competitivo e la possibilità di accaparrarti una fetta più grande del mercato.
Tiny Speck è un ottimo esempio di questa idea. Era una società di videogiochi che sviluppò un MMORPG online che fallì clamorosamente. Il problema? Hanno creato il gioco semplicemente copiando idee da altri (detta anche Factory Trap) senza comprendere chiaramente i bisogni dei videogiocatori.
L’azienda dopo poco eliminò il gioco e lanciò invece il suo strumento di comunicazione interna. Esatto, era Slack.
Quindi la stessa azienda è anche un ottimo esempio di successo del prodotto grazie a una discovery rigorosa. Diversamente dal gioco, il team di Slack svolgeva continue iterazioni di discovery e comprendeva molto chiaramente quali fossero i bisogni dei loro utenti.
4 domande chiave della scoperta di prodotto
Se vogliamo comprendere l'essenza della product discovery senza perderci nei dettagli, possiamo guardare a queste 4 domande a cui cerca di dare risposta.
- Esiste un problema reale? Esatto, a volte si rischia di creare una soluzione alla ricerca di un problema. Ciao al 90% delle startup basate su ChatGPT là fuori ;)
- Possiamo risolverlo? A volte il problema sta nella complessità della soluzione. S.T.A.L.K.E.R. è una serie di videogiochi ucraini che si è trovata di fronte proprio a questo problema. Volevano costruire A-life, il loro sistema di intelligenza artificiale, che simulava completamente le vite di NPC e animali nel gioco. Ma era semplicemente un problema troppo complesso da risolvere.
- Dovremmo risolverlo? A volte il problema esiste, ma non è abbastanza rilevante da meritare una soluzione tramite un prodotto. Google Glass è un ottimo esempio. Sì, era interessante, ma non avere Google Glass non avrebbe reso la vita meno comoda a nessuno.
- Possiamo consegnarlo in modo efficace? Questa domanda riguarda più il lato operativo dello sviluppo prodotto e la capacità di scalare e supportare gli utenti. YouTube, nei suoi primi giorni, rischiò di fallire proprio per la sua incapacità di scalare.
Quello che sostanzialmente fai durante la product discovery è utilizzare diversi strumenti e framework per raccogliere insight che ti permettano di rispondere a queste domande.
Framework per strutturare la discovery
Si potrebbe sostenere che un product manager esperto possa fare discovery senza alcun playbook o framework. Questo è vero. Ma c’è una ragione se esistono i framework di discovery: ti permettono di portare struttura e prevedibilità nel processo di discovery.
Vediamo ora questi 5 framework:
Dual-Track Agile: È il processo che prevede due percorsi paralleli nello sviluppo Agile. C’è la traccia discovery che genera idee di funzionalità, e la traccia delivery che le progetta e sviluppa.
Di solito uso ProductBoard e Jira per gestire questo framework.
Opportunity Solution Tree: Ne parleremo più avanti. In breve, questo framework ti permette di creare un albero in cui la radice rappresenta l’outcome principale. A partire da questa radice, si sviluppano rami di opportunità per risolvere dei problemi. Poi, per ciascuna opportunità, si creano rami di possibili soluzioni.
Miro offre ottimi template di Opportunity Solution Tree che puoi utilizzare.
Discovery Sprint: Questo framework è ispirato al design sprint creato da Google. Permette di iterare rapidamente sulle soluzioni. Si hanno circa 2 settimane per svolgere interviste con utenti, proporre una soluzione, costruire il prototipo e testarlo.
Continuous Discovery: A differenza dei tre precedenti, dove ci sono iterazioni con inizio e fine, la continuous discovery non ha fine: si svolgono cicli infiniti di interviste agli utenti target, si creano soluzioni e le si testa costantemente.
Qui trovi una comparazione diretta tra questi framework.
| Framework | Dimensione Org | Cadenza Discovery | Tolleranza al Rischio |
|---|---|---|---|
| Dual-Track Agile | Mediogrande | Continuativa | Moderata |
| Opportunity Solution Tree | Piccola-media | Ad hoc o ciclica | Da bassa a moderata |
| Discovery Sprint | Startup-media | Sprint a tempo limitato | Alta |
| Continuous Discovery | Team di prodotto maturi | Settimanale/giornaliera | Bassa |
La scelta del framework dipende da te. Non tutti i team trarranno gli stessi vantaggi dallo stesso framework. Utilizza la tabella qui sopra per scegliere quello che meglio si adatta alla dimensione, ai ritmi e alla propensione all’incertezza del tuo team.
Ruoli & Collaborazione nel Team
C’è un’idea diffusa (e rischiosa) che la product discovery riguardi solo i team di prodotto. In realtà, sebbene sia principalmente un’attività per questi team, un ottimo processo di discovery coinvolge anche altri membri e stakeholder. Ecco come ciascun membro può contribuire alla discovery:
- Product Manager: Guidano il processo di discovery, allineano il team e danno priorità a soluzioni e insight.
- User Experience Design: Partecipano alla ricerca utente, creano concept di design, prototipi cliccabili e conducono test di usabilità.
- Sviluppo: Valutano la fattibilità delle soluzioni e segnalano i rischi legati alla delivery.
- Stakeholder: Forniscono il contesto strategico e di business a livello alto.
Come si può vedere, il coinvolgimento di ogni membro è importante. Quindi, se la leadership ti chiede se il team scrum debba partecipare al processo di product discovery, la risposta è sicuramente sì!
Il processo di Product Discovery
Comprendere le esigenze dei tuoi clienti e ideare soluzioni validate per loro ricorda un imbuto dove gli strati superiori sono molto più grandi di quelli inferiori.
Questo è esattamente ciò che accade nella product discovery. Si parte da un insieme di intuizioni, lamentele e commenti dal proprio pubblico target e si arriva solo a un paio di soluzioni validate che sai creeranno valore per i tuoi utenti.
Ecco come appare.
Ora, analizziamo meglio il processo di product discovery e comprendiamo le particolarità di ciascuno dei suoi elementi.
Generalmente, il processo di product discovery si compone di questi 10 passaggi.
Adesso vediamo nel dettaglio ogni passaggio.
1. Rivedi la tua direzione strategica
Le buone funzionalità risolvono i problemi degli utenti. Le grandi funzionalità fanno lo stesso seguendo, nel contempo, la più ampia direzione strategica del tuo prodotto. Prima di iniziare la product discovery, è importante rivedere il documento strategico e ricordare dove vuoi arrivare sul lungo termine e quale direzione vuoi prendere.
Questo ti aiuterà a concentrare i tuoi sforzi di discovery su soluzioni che sono allineate con la tua strategia. Altrimenti rischi di concentrarti su funzionalità che, alla lunga, non porteranno alcun beneficio.
2. Elenca le tue assunzioni
Un altro aspetto importante della discovery che va affrontato prima di comunicare con gli utenti sono le tue assunzioni. L’idea è che probabilmente stai facendo molte supposizioni sul tuo mercato o sugli utenti, ed è importante documentarle per garantire che la tua ricerca non si basi troppo sulle tue ipotesi più azzardate.
Per questo puoi costruire una mappa delle assunzioni.
| Assunzione | Nota/Non nota | Importanza |
|---|---|---|
| Gli utenti si fideranno di una voce AI simile a un DJ | Non nota | Alta |
| Le persone usano Spotify principalmente in modalità passiva (ascolto in sottofondo) | Nota | Alta |
| Gli utenti vogliono dare un nome alle loro personalità DJ | Non nota | Bassa |
| I podcast aumentano il tempo trascorso sulla piattaforma | Nota | Media |
Nella mappa qui sopra puoi fare affidamento sulle assunzioni in alto a sinistra e fare attenzione a quelle in alto a destra.
3. Parla con i tuoi utenti
Senza questo passaggio, la product discovery è solo un gioco di ipotesi. Parla con i tuoi utenti, oppure rischi di costruire qualcosa di completamente sbagliato.
Ci sono molti modi diversi per parlare con gli utenti:
- Incontrarli di persona (ad esempio, andare in ospedale e intervistare i medici).
- Incontrarli alle fiere di settore (ad esempio, parlare con giornalisti tecnologici al CES).
- Fare videochiamate Zoom con loro.
Per l’ultimo caso, puoi utilizzare vari metodi come piattaforme di partecipazione a ricerche, contattare la tua base utenti o raggiungere il tuo pubblico target su LinkedIn usando un account recruiter.
4. Analizza i feedback dagli utenti e dai dati
Oltre ai riassunti delle interviste agli utenti, controlla la tua dashboard di analisi del prodotto e i feedback raccolti dai team di assistenza e vendita. Così facendo, raccogli spunti da molteplici fonti. E invece di leggere infiniti riassunti o trascrizioni, puoi far processare tutto a un LLM.
Ecco un esempio di prompt che puoi usare:
Sei un senior product manager software con 10 anni di esperienza. Sei molto abile nell'analizzare le trascrizioni del tuo team di vendita e nell'identificare le informazioni chiave che saranno utili per la tua ricerca di prodotto.
Questa è la trascrizione della chiamata di vendita
{{sales_transcript}}
Sulla base delle informazioni presenti nella trascrizione di vendita, identifica le seguenti informazioni.
Per favore, individua quanto segue:
1. Principali punti dolenti: si riferisce ai problemi e alle sfide più rilevanti che l'utente sta vivendo con gli strumenti e i processi attuali.
2. Perché sono interessati a te: si riferisce ai motivi per cui l'azienda sta cercando ora un nuovo strumento.
3. Feedback sul prodotto: si riferisce ai commenti che l'azienda ha fornito al team di vendita riguardo a {{your_product_name}} e alle sue funzionalità dopo aver visto la demo.
Dopo aver analizzato i feedback e averli confrontati con le intuizioni delle interviste utente e le analytics, inizierai a vedere emergere tendenze e temi ricorrenti.
5. Identifica i punti dolenti degli utenti nei tuoi risultati
Individuare i punti dolenti non è sempre così semplice. Certo, ci sono casi in cui l'80% degli utenti ti dice che una parte specifica del loro lavoro è problematica, ma non significa necessariamente che sia un problema che vale la pena risolvere. Devi anche comprendere l'“intensità” di tale dolore.
Immagina che il 70% degli utenti della tua piattaforma social dica di essere infastidito dal numero di notifiche e dal fatto che non si possano contrassegnare tutte come già viste.
Quando abbini il loro feedback ai dati analitici — che mostrano che il 90% di loro riceve in media 2-3 notifiche al giorno — puoi dedurre che questa lamentela non è abbastanza "intensa" da essere prioritaria rispetto ad altri elementi sulla tua lista.
6. Trova soluzioni per questi problemi
Questo è il momento in cui elabori delle possibili soluzioni ai problemi che hai identificato attraverso le interviste con i clienti e l’analisi dei feedback.
Puoi semplicemente sederti con i tuoi team di design e sviluppo e fare brainstorming. Tuttavia, per garantire che le soluzioni siano direttamente legate ad un obiettivo aziendale più ampio, puoi utilizzare il framework Opportunity Solution Tree di Teresa Torres. Ecco com’è per il problema degli utenti Spotify di “Non so cosa ascoltare”.
Attraverso questo framework abbiamo visto che rimuovere la barriera del “cosa ascoltare” potrebbe aumentare gli utenti attivi giornalieri (DAU), rendendolo un problema molto impattante da risolvere.
7. Testa le tue soluzioni con prototipi
Analizzare i feedback degli utenti e trasformarli in una lista di potenziali funzionalità è solo il punto di partenza. La product discovery si basa sul metodo scientifico, e questo significa che dovresti testare e validare le idee prima di aggiungerle alla roadmap di prodotto.
Puoi validare le soluzioni in diversi stadi del loro ciclo di vita — dalla semplice descrizione dell’idea a un utente durante l’intervista per raccogliere feedback, fino a generare mockup di base, chiedere feedback a gruppi di utenti e raccogliere i risultati su prototipi precoci. Potresti anche arrivare a costruire e lanciare un prodotto minimo funzionante (MVP).
La validazione nelle prime fasi, come discutere l’idea in un’intervista, è veloce ed economica, ma la qualità del feedback può essere bassa perché gli utenti potrebbero avere difficoltà a capire appieno il concetto.
Al contrario, testare con un MVP fornisce feedback più ricchi e accurati perché gli utenti possono interagire con le funzionalità effettive del prodotto. Tuttavia, questo approccio è più lento e costoso a causa del lavoro di sviluppo necessario.
Considerando questo compromesso, il mio metodo di validazione preferito sono i prototipi cliccabili, in quanto sono relativamente economici da realizzare e permettono agli utenti reali di vedere un vero design UX del tuo nuovo prodotto o funzionalità.
Per velocizzare la creazione dei prototipi, puoi utilizzare Figma AI o le funzionalità AI integrate di altri tool di UX design.
8. Documenta i risultati dei test
Una volta completati i test, raccogli tutti gli apprendimenti e i risultati in un unico documento. Raggruppali in base alla soluzione e all’ipotesi che vuoi testare.
In questo modo, quando sarà il momento di valutare una soluzione, avrai tutto ciò che ti serve in un unico posto per prendere una decisione informata.
9. Valida o invalida le tue soluzioni
Questo è il momento in cui guardi a tutti i risultati dei tuoi test e decidi se:
- Consideri la soluzione validata e la aggiungi al tuo backlog di prodotto esistente.
- Capisci che la soluzione è sulla strada giusta ma necessita di una revisione. Quindi la riporti nella fase di ideazione per apportare correzioni basate sui risultati dei test.
- Invalidi la soluzione perché non risolve i problemi degli utenti che doveva risolvere.
Tutti e tre i risultati sono attesi. Quando invalidi un prodotto, dovresti considerarlo un grande successo, poiché hai appena evitato di costruire prodotti e sprecare tempo e risorse per qualcosa che non risolve i problemi dei tuoi utenti.
More Articles
- L’IA nella Ricerca sugli Utenti: Come l’Intelligenza Artificiale Sta Trasformando le Analisi sugli Utenti
- Spedire Prodotti Global-First Senza il Mal di Testa Globale: Come Integrare la Localizzazione nel Tuo Flusso di Lavoro di Prodotto
- L’IA nella Pianificazione dello Sprint: Come l’IA Migliora l’Efficienza del Team
10. Costruisci le Soluzioni Validate e Ricomincia Daccapo
L’ultimo passo logico del processo di product discovery è aggiungere le tue soluzioni al backlog, priorizzarle e realizzarle.
Tuttavia, è davvero importante capire che non si interrompe il product discovery qui. Invece, si conclude questa iterazione e si inizia immediatamente la successiva. I prodotti di successo sono quelli in cui il processo di discovery non finisce mai.
Qui, i team sono in grado di prendere decisioni di prodotto corrette sulla base dell’apprendimento dai feedback degli utenti, dell’usabilità e dei test A/B.
Strumenti per il Product Discovery
Ecco alcuni strumenti che vale la pena esplorare per aiutarti a muoverti più velocemente nel product discovery e ottenere risultati migliori, organizzati per fase.
- User Research: Hotjar per le registrazioni delle sessioni, UserTesting per i test di usabilità e Figma per la progettazione dell’esperienza utente e prototipi cliccabili.
- Journey Mapping e Collaborazione Visiva: Miro è lo strumento universale in questo campo. Puoi anche considerare di provare il suo concorrente emergente - FigJam o altre alternative a Miro.
- Competitor Research: Similarweb per i canali di traffico dei concorrenti, Builtwith per gli stack tecnologici.
- Product Analytics: GA4 per i canali e il traffico. Amplitude per il comportamento e le metriche chiave di prodotto. Per i software di heatmap, HotJar è un’opzione molto popolare.
- Tracciamento e Prioritizzazione: Modello di valutazione RICE per una definizione delle priorità leggera, Aha! o ProdPad per la roadmapping e la raccolta delle idee di prodotto.
Questi sono gli strumenti che utilizzo e che raccomando ai miei colleghi. Per altre opzioni, puoi anche dare un’occhiata alla nostra lista curata di strumenti per il product discovery.
Inoltre, come avrai notato, non ho menzionato qui alcuna soluzione AI. Questo perché voglio parlarne separatamente e con maggior dettaglio.
Come l’AI sta Trasformando il Discovery
La discovery è probabilmente stata l’area del product management dove l’AI ha aggiunto più valore. Il motivo è che i LLM sono eccellenti nei tipi di attività che si trovano comunemente nel product discovery. In particolare, trascrizione, sintesi ed estrazione di insight.
Abbiamo trattato l’impatto dell’AI sul product discovery in uno degli episodi del nostro podcast. Il nostro ospite, Craig Watson, ci ha raccontato la sua esperienza personale e ha condiviso molti spunti preziosi.
In particolare, sottolinea che l’AI è stata di grande aiuto ai product manager nei seguenti ambiti:
Trascrizione e sintesi delle interviste utente: I PM non devono prendere appunti durante la chiamata o riascoltare le registrazioni successivamente. Tutto ciò che serve è la presenza di un bot AI nella chiamata per registrare. Il bot trasformerà poi la registrazione in una trascrizione e in un riassunto, evidenziando i risultati più importanti di quell’intervista. Gli strumenti migliori per questo sono Dovetail, Krisp e GreatQuestion.
Individuare pattern ripetibili nei dati qualitativi: È molto dispendioso in termini di tempo ascoltare tutte le interviste e trovare dolori o processi che si ripetono. I LLM possono svolgere molto bene questo compito, analizzando centinaia di interviste alla ricerca di pattern. Dovetail è il migliore in questo, secondo la mia esperienza.
Clustering, conteggio e punteggio dei feedback: Anche qui, possono volerci ore o addirittura giorni per convertire manualmente i dati qualitativi in dati quantitativi. I LLM impiegano solo pochi secondi per contare e vedere quali feedback sono più comuni nei dati. Possono anche effettuare la valutazione tramite il modello di punteggio ponderato o RICE.
Nonostante tutto il valore che queste automazioni possono apportare, Craig consiglia comunque di non affidarsi troppo all’AI durante la discovery.
“L’AI non sostituirà la tua intuizione — ti aiuterà a prendere decisioni più rapide e basate sui dati.”
Sono d’accordo con lui. Lascia che l’AI nel product discovery svolga il lavoro manuale per te. Ma non affidarti alle decisioni dell’AI senza prima verificarle tu stesso.
FAQ
Come gestiscono la product discovery i team Agile?
I team Agile possono sfruttare il Dual-Track Agile, dove la discovery procede parallelamente alla delivery. In questo caso, i team Agile si uniscono occasionalmente alla fase di discovery per svolgere compiti come fornire feedback sulla fattibilità tecnica delle idee di soluzione, realizzare concept di design, costruire prototipi e testarli.
Gli ingegneri dovrebbero essere coinvolti nella product discovery?
Assolutamente sì! Gli ingegneri sono coloro che alla fine realizzeranno la funzionalità. Possiedono quindi conoscenze preziose sulla fattibilità dell’idea. Possono anche evidenziare i possibili rischi tecnici e di implementazione ad essa associati. Infine, possono indicare le limitazioni tecniche che il team di prodotto dovrà tenere in considerazione durante la progettazione della funzionalità.
In che modo la product discovery riduce il time-to-market?
Il maggiore valore che le aziende ottengono dalla product discovery è la validazione delle idee a basso costo. In questo modo, si evita il rischio di sviluppare funzionalità che gli utenti non desiderano e di ritardare notevolmente il momento in cui si rilascia finalmente la versione che viene apprezzata e utilizzata. Inoltre, si accorciano i cicli di iterazione e si ottiene un feedback precoce. Tutto ciò aiuta anche ad accelerare la delivery.
Qual è la differenza tra product discovery e product strategy?
Quando si definisce la strategia di sviluppo prodotto, si indica la direzione generale del prodotto e si elencano le principali tappe da raggiungere lungo quel percorso. La product discovery è il processo di identificazione delle esigenze dei clienti e di creazione di soluzioni validate per soddisfarle. Di solito, la product discovery mira a proporre soluzioni allineate con la strategia di prodotto che consentano di avvicinarsi ai traguardi fissati.
