Discovery non è chiedere ai clienti cosa vogliono

Una delle scorciatoie più pericolose nella discovery è pensare che basti chiedere ai clienti cosa vogliono. Sembra una frase ragionevole: se dobbiamo costruire qualcosa per loro, perché non partire dalle loro richieste?

Il problema è che le richieste dei clienti sono spesso soluzioni travestite da bisogni. Arrivano già filtrate da quello che conoscono, dagli strumenti che usano oggi, dai workaround che hanno inventato, dalla frustrazione del momento. Se le prendiamo alla lettera, rischiamo di trasformare la discovery in un processo di raccolta ordini.

Un team di prodotto non dovrebbe ignorare quelle richieste. Dovrebbe trattarle come indizi. Dietro “mi serve un export” può esserci un bisogno di reporting, un problema di fiducia nel dato, una revisione manuale fatta ogni venerdì o un manager che chiede aggiornamenti fuori dal sistema. La richiesta è il punto di partenza, non la risposta.

Discovery significa ridurre incertezza

Teresa Torres definisce la continuous discovery come un ritmo di contatti settimanali con i clienti, portati avanti dal team che costruisce il prodotto, attraverso piccole attività di ricerca orientate a un outcome desiderato. È una definizione utile perché sposta la discovery da “fare interviste” a “prendere decisioni con dati recenti”.

La parola chiave, per me, è ritmo. La discovery non dovrebbe essere una fase cerimoniale prima della delivery, né un grande progetto di ricerca ogni sei mesi. Dovrebbe essere il modo con cui il team riduce progressivamente l’incertezza mentre costruisce.

Quell’incertezza non è una sola. C’è incertezza sul valore: questa cosa risolve davvero un problema importante? C’è incertezza sull’usabilità: le persone capiranno come usarla? C’è incertezza tecnica: possiamo costruirla bene con il tempo e lo stack che abbiamo? C’è incertezza di business: ha senso per il modello economico, il supporto, la compliance, il go-to-market?

SVPG usa spesso queste quattro lenti nel suo Product Operating Model: valuable, usable, feasible, viable. Sono semplici, ma aiutano a evitare una trappola comune: validare solo la parte che ci fa più comodo.

Il cliente conosce il problema meglio di noi

Il cliente conosce il proprio contesto meglio di noi. Sa dove perde tempo, cosa lo irrita, cosa aggira ogni settimana, quali fogli Excel tiene aperti perché il prodotto non lo aiuta abbastanza. Su questo dobbiamo ascoltarlo con molta attenzione.

Non è detto, però, che conosca la soluzione migliore. Il cliente vede il problema dal punto in cui si trova oggi; il team di prodotto dovrebbe vedere anche le alternative, i vincoli tecnici, i pattern che si ripetono tra clienti diversi e le conseguenze di ogni scelta sulla roadmap futura.

Quando un cliente chiede una feature, la domanda non è “la facciamo o no?”. Prima viene un’altra domanda: quale lavoro sta cercando di fare, e perché il prodotto attuale non lo supporta?

Questa distinzione cambia la qualità della conversazione. Invece di difendere o promettere feature, il team può indagare comportamenti reali: quando succede, chi è coinvolto, cosa viene fatto prima, cosa viene fatto dopo, cosa succede se il problema non viene risolto. A quel punto la discovery diventa meno opinabile, perché comincia a poggiare su evidenze concrete.

La discovery debole diventa roadmap gonfia

Quando la discovery è debole, la roadmap si riempie di cose plausibili. Ogni richiesta ha una storia convincente, ogni stakeholder ha un motivo, ogni cliente importante sembra portare un’urgenza legittima. Il problema è che una roadmap piena di cose plausibili non è una strategia.

La build trap nasce spesso qui. Non quando il team è pigro o incapace, ma quando lavora bene su problemi scelti male. La delivery procede, le release escono, la velocity sembra sana. Poi, a distanza di mesi, si scopre che il prodotto è più complesso, ma non molto più utile. Per questo la discovery deve restare collegata a come il team misura outcome, non solo a quanto produce.

Una buona discovery non elimina questo rischio. Lo rende visibile prima. Costringe il team a formulare ipotesi, scegliere quale incertezza ridurre e accettare che non tutte le richieste meritano lo stesso investimento.

Per questo i rituali da soli non bastano. Puoi avere interviste, survey, opportunity solution tree, backlog di insight e workshop ben condotti. Se nessuno collega tutto questo a decisioni reali di priorità, la discovery resta teatro.

Cosa cambia per un founder o una startup

In un team piccolo, la discovery deve essere leggera. Non serve creare un reparto ricerca o rallentare ogni decisione con processi enormi. Serve però evitare l’errore opposto: decidere solo sulla base di urgenze interne, clienti rumorosi o intuizioni del founder.

Una pratica sostenibile può essere molto concreta: parlare ogni settimana con qualcuno che vive il problema, raccogliere esempi reali, separare richiesta e bisogno, scegliere una sola ipotesi da verificare prima di costruire. Non è glamour, ma cambia la qualità della roadmap.

Il ruolo di un Fractional PM, in molti contesti, è proprio aiutare il team a costruire questo ritmo senza trasformarlo in burocrazia. Non prendere il posto del founder, non imporre framework, ma creare un modo più affidabile per decidere cosa vale la pena costruire.

La discovery non serve a sapere tutto. Serve a evitare di costruire per settimane su una certezza che nessuno ha verificato.