Tecniche di product discovery: come sceglierle e usarle

La product discovery è il lavoro, guidato dalle evidenze, con cui capisci che cosa vale la pena costruire prima di costruirlo. Le tecniche che funzionano meglio sono le interviste e l'osservazione dei clienti, i dati di utilizzo, la ricerca sui concorrenti e sul business, la ricerca tecnica, la mappatura delle ipotesi, i prototipi e i test di usabilità. Non esiste un metodo giusto in assoluto. Scegli in base all'incertezza che devi ridurre, poi combini due o tre metodi in modo che una fonte di evidenza ne verifichi un'altra. Questa guida ti mostra come farlo, come condurre un workshop di discovery e come la discovery si colloca accanto allo sviluppo.

In breve

• La discovery è un processo decisionale: capire il problema, esplorare le soluzioni, testarle e poi decidere che cosa costruire.
• Scegli le tecniche in base al rischio. Interviste per le motivazioni, dati di utilizzo per i modelli ricorrenti, ricerca tecnica per la fattibilità, prototipi per il rischio legato alla soluzione.
• Combina almeno due metodi (triangolazione) prima di impegnare budget nello sviluppo.
• Un workshop di discovery ha bisogno di un solo risultato, una sola decisione, un gruppo ristretto ed evidenze datate. Per la maggior parte delle prime sessioni basta un'agenda di 90 minuti.
• Discovery e sviluppo non sono reparti in sequenza. Lo stesso team dovrebbe fare entrambe le cose, in continuo.

Che cos'è davvero la product discovery

Una 2025 academic review of product discovery la descrive come il processo di comprendere e validare bisogni e problemi degli utenti, esplorare possibili soluzioni, testarle e decidere che cosa costruire. La parola che conta è decidere. La discovery non è un progetto di ricerca che finisce in una presentazione. Finisce con una scelta: costruiamo questo, lo cambiamo oppure ci fermiamo.

La discovery study guide del Nielsen Norman Group la inquadra come lo studio dello spazio del problema, la definizione dei problemi che vale la pena risolvere e la raccolta di evidenze sufficienti per sapere che cosa fare dopo. Nota anche che la discovery copre di solito tre tipi di lavoro: ricerca sugli utenti, ricerca e analisi sul business, e ricerca tecnica sulle tecnologie e sulle capacità disponibili.

Questa suddivisione in tre parti è utile per chi fonda un'azienda. La maggior parte dei prodotti falliti non è fallita perché il codice era scritto male. È fallita perché nessuno ha verificato se ai clienti interessasse davvero, se il modello di business reggesse o se la tecnologia potesse fare il lavoro a un costo sensato. Ognuna di queste è una domanda a sé, e ognuna richiede la propria tecnica.

Atlassian boils discovery down to four questions:

1. I clienti troveranno valore nell'idea e la useranno?
2. Riescono a capirla?
3. Il team tecnico è in grado di realizzarla?
4. Sostiene la strategia aziendale e i bisogni degli stakeholder?

Tieni queste quattro domande sempre davanti a te. Ogni tecnica elencata qui sotto risponde a una o più di esse.

Le tecniche fondamentali di product discovery

L'elenco qui sotto è raggruppato per tipo di incertezza che ogni tecnica riduce, non per moda. Non le userai tutte in un solo progetto.

Interviste ai clienti e osservazione

Le interviste sono il punto di partenza di quasi ogni percorso di discovery. Maze groups interviews with competitor analysis and product analytics, come modo per capire problemi e punti dolenti degli utenti nella fase di apprendimento. NN/G aggiunge che la ricerca esplorativa di questo tipo è discovery study guide, il che va benissimo, a patto di non trattare cinque conversazioni come un risultato statistico.

Regole pratiche che fanno risparmiare tempo:

• Chiedi dei comportamenti passati, non delle intenzioni future. «Raccontami l'ultima volta che hai fatto questa cosa» vale più di «Lo useresti?».
• Intervista chi ha il problema adesso, non chi potrebbe averlo un giorno.
• Annota separatamente ciò che è stato detto e ciò che pensi significhi. Questa distinzione torna utile nella sezione sul workshop qui sotto.
• L'osservazione (guardare qualcuno svolgere il compito nel suo contesto) rivela spesso soluzioni di ripiego che in un'intervista le persone dimenticano di menzionare.

Teresa Torres, come riportato da Mind the Product, sostiene la necessità di at least weekly customer touchpoints da parte del team che costruisce il prodotto, con piccole attività di ricerca orientate a un risultato desiderato. Per una startup è realistico: una o due brevi conversazioni a settimana costano molto meno di un grande studio all'anno.

Dati di utilizzo e comportamento

Le interviste ti dicono il perché. I dati di utilizzo ti dicono quanti e dove. Se hai già un prodotto o un sito online, guarda dove gli utenti abbandonano, quali funzioni restano intoccate e che cosa cercano le persone. Se un prodotto non ce l'hai ancora, i dati di un processo esistente (ticket di supporto, dati degli ordini, esportazioni da fogli di calcolo) possono svolgere lo stesso ruolo.

La rassegna accademica elenca i dati di utilizzo tra le tecniche fondamentali di discovery, accanto a interviste e osservazione. Usa i numeri per individuare i punti che meritano un approfondimento, poi torna dalle persone per capirli.

Ricerca su concorrenti e business

L'analisi della concorrenza è la tecnica più economica di questa pagina. Non stai cercando cose da copiare. Stai cercando ciò per cui i clienti già pagano, quali lacune lasciano aperte i concorrenti e quali promesse fanno tutti nel mercato (e che quindi non significano nulla). La ricerca sul business copre l'altro lato: economia unitaria, logica di prezzo, ciclo di vendita, normative e se l'idea si sposa con la strategia dell'azienda che la porterà avanti.

Questo corrisponde alla quarta domanda di Atlassian. Un'idea amata dagli utenti ma che l'azienda non può finanziare né sostenere resta comunque un'idea fallita.

Ricerca tecnica

È la tecnica che viene saltata più spesso, ed è quella in cui un partner tecnico può aggiungere più valore. Mind the Product ricorda che technical feasibility is one uncertainty to check before committing to execution. In pratica significa:

• I dati di cui hai bisogno sono davvero accessibili, e con quale qualità?
• I sistemi a cui devi collegarti (uno shop, un CRM, un ERP) espongono interfacce utilizzabili?
• Esiste una prova di concetto che dimostri che la parte difficile funziona?
• Quanto costerebbe mantenerlo in esercizio, non solo costruirlo?

Un approfondimento tecnico di uno o due giorni che risponda a queste domande può evitare mesi di rilavorazione. Affina anche il perimetro, perché scopri che cosa è economico e che cosa è caro prima di promettere qualsiasi cosa.

Cinque perché e definizione del problema

La rassegna accademica include i cinque perché tra le tecniche consolidate. Parti da un problema dichiarato («i clienti abbandonano il checkout») e continui a chiedere perché finché non arrivi a una causa su cui puoi agire. È semplice e veloce, e funziona meglio con le persone che vedono il problema ogni giorno, per esempio chi lavora nel supporto e nelle vendite. Tratta le risposte come ipotesi da testare, non come conclusioni.

La definizione del problema è il passo successivo: scrivi il problema come un'unica frase chiara su una persona specifica in una situazione specifica. Se il team non riesce a mettersi d'accordo su quella frase, nessun elenco di funzionalità servirà a qualcosa.

Mappa del percorso e mappa delle opportunità

Una mappa del percorso mette in fila i passi che compie un cliente, con quello che fa, pensa e prova in ciascuno. Segna i punti di attrito. Una mappa delle opportunità raggruppa poi quei punti dolenti e i bisogni insoddisfatti, così il team vede quale gruppo è più ampio o più costoso. Entrambe le tecniche rendono visibile la comprensione condivisa, ed è per questo che funzionano bene nei workshop.

Mappatura delle ipotesi

Ogni idea poggia su ipotesi: che i clienti abbiano quel problema, che siano disposti a pagare, che cambino le proprie abitudini, che l'integrazione funzioni. Elencale, poi colloca ciascuna su due assi: quanto è importante per l'idea e quante poche evidenze hai. Le ipotesi nell'angolo in alto, importanti e non dimostrate, sono quelle da testare per prime.

Productboard suggerisce di valutare ogni idea di soluzione rispetto a four kinds of risk before committing to build: valore, usabilità, fattibilità e sostenibilità economica. Etichettare ogni ipotesi con una di queste quattro voci rende evidente a quale tecnica ricorrere.

Generazione di idee e definizione delle priorità

Una volta chiarito il problema, genera più soluzioni possibili, non una sola. Fai schizzi, raccogli idee o scrivi brevi descrizioni di soluzione. Poi stabilisci le priorità in base alle evidenze raccolte, non in base a chi ha alzato di più la voce. Basta un punteggio semplice su valore per il cliente, impegno e rischio. L'obiettivo è una lista breve di opzioni che vale la pena testare, non un backlog ordinato di cinquanta voci.

Prototipi e test di usabilità

I prototipi rispondono alle domande a cui parlare non basta: le persone riescono davvero a usarlo, e risolve il problema così come lo vivono? Un mock-up cliccabile realizzato in pochi giorni basta spesso a testare il flusso principale con cinque o sei persone. Maze descrive la fase finale della discovery come Maze groups interviews with competitor analysis and product analytics. Testa per prima la parte più rischiosa dell'idea, non quella più bella.

Come scegliere e combinare le tecniche

La rassegna accademica è chiara sul fatto che la scelta della tecnica è 2025 academic review of product discovery: non si può dare per scontato che lo stesso metodo vada bene per ogni prodotto, team o fase. Un modo praticabile per decidere:

Se la tua incertezza maggiore è…	Inizia con	Poi conferma con
Le persone hanno davvero questo problema?	Interviste, osservazione	Dati di utilizzo, sondaggio
Quanto è grande o diffuso?	Dati di utilizzo, dati esistenti	Interviste per spiegare i modelli ricorrenti
Sceglieranno la nostra soluzione?	Prototipo, test di usabilità	Un piccolo esperimento dal vivo
Possiamo costruirlo a un costo ragionevole?	Approfondimento tecnico, prova di concetto	Analisi dei sistemi coinvolti
Il business case regge?	Ricerca su concorrenti e prezzi	Conversazioni con potenziali acquirenti

Tre principi mantengono onesto il mix.

Adatta il metodo alla fase. All'inizio, con poche evidenze, usa metodi qualitativi ad ampio raggio. Più avanti, quando hai una soluzione specifica, passa a test più circoscritti su usabilità e fattibilità. Secondo Mind the Product, technical feasibility is one uncertainty to check before committing to execution. Se conosci già il problema, gli utenti e la strada tecnica, una lunga fase di discovery è uno spreco.

Triangola. NN/G raccomanda la discovery study guide per aumentare la fiducia nei risultati. Se le interviste dicono che una funzione è importante e i dati mostrano che nessuno usa l'equivalente più vicino, hai una contraddizione che conviene risolvere prima di costruire.

Adattati al tuo contesto. La rassegna accademica osserva che il mix giusto dipende dal tipo di prodotto, dalla struttura del team, dalla cultura e dai vincoli locali. Per i team in Svizzera questo significa pianificare per utenti che parlano più lingue, avere chiaro quale segmento del mercato svizzero servi e verificare presto se regole sulla protezione dei dati o di settore influiscono sul modo in cui puoi raccogliere e conservare dati di ricerca e informazioni sugli utenti. Solleva queste domande durante la discovery, quando un cambiamento costa una conversazione, non dopo il lancio.

Un mix realistico per il primo giro di una startup in fase seed: otto o dieci interviste, un'analisi di tre o quattro concorrenti, mezza giornata di approfondimento tecnico sull'integrazione più rischiosa e un prototipo cliccabile testato con cinque utenti. Sono poche settimane di lavoro a tempo parziale, non un trimestre.

Come condurre un workshop di discovery

Il workshop è una tecnica per portare più persone a una decisione condivisa. Learning Loop suggerisce di usarlo quando several people need shared understanding for a meaningful decision: scegliere tra opportunità, risolvere letture contrastanti della ricerca, far emergere ipotesi o concordare il prossimo piano di apprendimento. Se una sola persona può decidere da sola, lascia perdere il workshop.

Prepara tutto prima del giorno stabilito

• Un risultato e una decisione. «Decidere quale dei tre problemi dei clienti testiamo per primo» è un obiettivo da workshop. «Parlare del nostro prodotto» non lo è.
• Un gruppo piccolo e interfunzionale. Prodotto, design, sviluppo e qualcuno vicino ai clienti. Aggiungi un responsabile della decisione, che deciderà se il gruppo si divide.
• Evidenze grezze con data. Porta note delle interviste, dati e schermate con le date, così tutti vedono quanto è vecchia ogni informazione.
• Ruoli. Un facilitatore, una persona che prende appunti e una lavagna condivisa. Sulla lavagna separa le evidenze (quello che abbiamo visto o sentito) dall'interpretazione (quello che pensiamo significhi).

Boldare fa un'osservazione utile: l'agenda va costruita attorno al why the group is meeting and what result it should produce, e non esiste un insieme universale di tecniche. Considera qualsiasi modello come un punto di partenza.

Un'agenda di 90 minuti che funziona

La guida di Learning Loop propone questa suddivisione:

Minuti	Blocco	Risultato
25	Obiettivo ed evidenze	Visione condivisa dell'obiettivo e dei fatti
15	Ipotesi	Elenco delle ipotesi, con quelle rischiose evidenziate
20	Mappa delle opportunità	Problemi e opportunità raggruppati
15	Priorità dei problemi	Un problema o un risultato selezionato
15	Prossima azione di ricerca	Azione, responsabile e data di verifica

L'ultimo blocco è quello che i team dimenticano. Un workshop che finisce senza un responsabile con nome e cognome e una data di verifica non produce nulla.

Quando serve un formato più lungo

Per un prodotto nuovo senza una visione condivisa, una giornata intera può essere giustificata. Airfocus pubblica un longer template che va dalle presentazioni alla visione di prodotto, all'elevator pitch, ai KPI, alle personas, alle user story e alle priorità, fino alla mappatura delle user story e alla chiusura con i prossimi passi. È accurato, ma richiede anche un'intera giornata di persone senior, quindi usalo quando la posta in gioco giustifica il tempo.

Mockitt descrive una struttura diversa, costruita su sei blocchi: frame the decision and constraints, read the evidence, group opportunities, identify risky assumptions, design the next test, and commit. I risultati che elenca vale la pena prenderli in prestito come lista di controllo: una dichiarazione di decisione, osservazioni collegate alle fonti, un problema o un risultato selezionato, l'ipotesi che più probabilmente cambierà la decisione, un piano di test con un responsabile e una data di verifica.

Qualunque formato tu scelga, giudica il workshop da ciò che lascia dietro di sé: una decisione, un test e una data.

Discovery e sviluppo a confronto

La discovery chiede se qualcosa vale la pena di essere costruito. Lo sviluppo lo costruisce a livello di produzione. Il playbook di Productboard dice che la discovery four kinds of risk before committing to build, invece di sostituirlo: esplori i bisogni, proponi e validi le soluzioni, poi ne scegli una da costruire.

L'errore più comune è trattarli come due fasi gestite da due gruppi, con un passaggio di consegne nel mezzo. La posizione del Silicon Valley Product Group è che discovery and delivery are two core activities the same cross-functional team should perform continuously. In un dato momento i product manager e i designer possono orientarsi di più verso la discovery e gli sviluppatori verso lo sviluppo, ma tutti partecipano a entrambe. Separarle, secondo questa visione, danneggia l'autonomia del team e l'innovazione.

Atlassian segue una linea simile e raccomanda una boils discovery down to four questions, con roadmap aggiornate man mano che arrivano nuovi dati e avanza lo sviluppo. E Maze sottolinea che Maze groups interviews with competitor analysis and product analytics: i team dovrebbero ripercorrere le fasi via via che cambiano le esigenze di ricerca nel corso della vita del prodotto.

Che cosa significa in pratica per un team piccolo:

• Porta uno sviluppatore alle interviste e alle revisioni dei prototipi. Gli sviluppatori individuano presto i problemi di fattibilità e sentono direttamente il linguaggio degli utenti.
• Mantieni il lavoro di discovery piccolo e frequente. Una cadenza settimanale vale più di uno studio di tre mesi che finisce in un rapporto che nessuno legge.
• Lascia che lo sviluppo alimenti la discovery. Rilascia in piccolo, misura l'uso reale e trasforma quello che impari nel prossimo giro di domande.
• Usa una regola chiara per cambiare modalità: quando l'incertezza è alta, impara; quando è bassa, costruisci.

È anche per questo che la continuità delle persone conta così tanto quando lavori con uno studio esterno. Se gli sviluppatori che costruiscono il prodotto non hanno partecipato all'apprendimento, quell'apprendimento si perde al momento del passaggio di consegne.

Dove ci inseriamo noi

In Ampersand il lavoro di discovery è guidato dagli stessi ingegneri senior che poi costruiscono, così quello che impariamo sui tuoi utenti, sui tuoi sistemi e sui tuoi vincoli non si perde tra una consulenza e un passaggio di consegne. Per i team in fase iniziale offriamo consulenza e direzione tecnica a tempo parziale, audit tecnici e due diligence, e costruiamo siti web, app, piattaforme, integrazioni e automazioni con l'IA. La nostra pagina dei prezzi elenca i piani, tra cui Guidance a CHF 799 al mese e Run & monitor a CHF 750 al mese. Gli altri incarichi vengono quotati in base al progetto. Se hai un'idea e vuoi testarne l'ipotesi tecnica più rischiosa prima di impegnarti a costruirla, scrivici dal nostro sito.

Errori comuni da evitare

• Confondere le opinioni con le evidenze. I pareri degli stakeholder sono input, non risultati. Segnalali come tali sulla lavagna.
• Fare ricerca senza una decisione in mente. Se nessuna scelta dipende dalla risposta, non fare lo studio.
• Testare solo ciò che è facile. I team testano il colore dei pulsanti perché è semplice e saltano l'ipotesi sul prezzo che potrebbe affondare il prodotto.
• Usare un solo metodo. Solo un sondaggio o solo interviste lasciano punti ciechi. Abbinali.
• Trattare la discovery come una fase. Una volta che il prodotto è online le domande cambiano, ma non finiscono.

Domande frequenti

Quali sono le tecniche di product discovery più utili per una startup?

Inizia con interviste ai clienti, un'analisi rapida dei concorrenti, la mappatura delle ipotesi e un prototipo cliccabile testato con una manciata di utenti. Aggiungi un approfondimento tecnico se l'idea dipende dall'integrazione con altri sistemi. Sono attività economiche, rapide e coprono il rischio su valore, usabilità e fattibilità.

Quanto dovrebbe durare la product discovery?

Dipende da quanta incertezza ti porti dietro. Un primo giro mirato di interviste, un approfondimento tecnico e un test del prototipo possono stare in poche settimane di lavoro a tempo parziale. La discovery continua procede poi in parallelo allo sviluppo, con piccole attività settimanali invece che in un unico blocco lungo.

In che cosa un workshop di discovery è diverso da una riunione normale?

Un workshop ha un solo risultato, una sola decisione, un gruppo definito, evidenze preparate e ruoli assegnati. Si chiude con un problema scelto, un prossimo test, un responsabile e una data di verifica. Una riunione normale spesso finisce con una discussione e nessun impegno.

La product discovery è la stessa cosa dello sviluppo del prodotto?

No. La discovery riduce l'incertezza su che cosa valga la pena costruire, mentre lo sviluppo lo realizza a qualità di produzione. Entrambe dovrebbero però essere svolte dallo stesso team interfunzionale, in continuo, invece di passare da un gruppo all'altro.

Fonti

• 2025 academic review of product discovery
• discovery study guide
• at least weekly customer touchpoints
• technical feasibility is one uncertainty to check before committing to execution
• Maze groups interviews with competitor analysis and product analytics
• four kinds of risk before committing to build
• boils discovery down to four questions
• discovery and delivery are two core activities the same cross-functional team should perform continuously
• several people need shared understanding for a meaningful decision
• longer template
• frame the decision and constraints, read the evidence, group opportunities, identify risky assumptions, design the next test, and commit
• why the group is meeting and what result it should produce