La product discovery è il lavoro che un team fa per capire quale problema vale la pena risolvere — e per chi — prima di impegnarsi a costruire una soluzione. Questa è tutta la definizione. Il resto è tecnica.
La maggior parte dei team che incontro non manca di metodi di discovery. Hanno guide per le interviste, opportunity tree, template per gli esperimenti. Quello che manca è la disponibilità a lasciare che la discovery gli faccia cambiare idea. La roadmap è già promessa, la feature ha già un nome, e la discovery diventa teatro: interviste condotte per confermare una decisione già presa.
Puoi distinguere la discovery vera dal teatro con una sola domanda: quale evidenza ti farebbe decidere di non costruire questa cosa? Se nessuno sa rispondere, non è discovery. È documentazione per una decisione che la precede.
Una buona discovery parte dalla decisione, non dal metodo. Cosa stiamo davvero cercando di decidere — se il problema esiste, se la nostra soluzione lo risolve, se le persone cambieranno comportamento per usarla? Ognuna di queste domande richiede evidenze diverse, e la maggior parte richiede molta meno macchina di quanto i team assumano. Non ogni domanda merita un A/B test. Ad alcune bastano cinque conversazioni oneste e la disciplina di ascoltare le risposte.
L'obiezione classica è che la discovery rallenta la delivery. La mia esperienza è l'opposto: i team saltano la discovery per andare veloci, e poi passano trimestri a rilasciare variazioni di qualcosa che nessuno ha chiesto. Rallentare all'inizio rende tutto quello che viene dopo più veloce, perché la direzione regge sotto pressione invece di spostarsi a ogni riunione con gli stakeholder.
L'AI ha reso tutto questo più vero, non meno. Ora puoi prototipare in ore quello che prima richiedeva settimane, il che significa mettere qualcosa di concreto davanti agli utenti quasi subito. È un regalo per la discovery — e una trappola. Costruire più velocemente significa anche poter validare più velocemente nella direzione sbagliata, scambiando la velocità di iterazione per la qualità dell'apprendimento.
I team che fanno bene la discovery non la trattano come una fase che finisce quando inizia lo sviluppo. La trattano come un ritmo — un'abitudine continua di verificare che il problema sia ancora reale, che la scommessa abbia ancora senso, e che le evidenze puntino ancora nella direzione in cui stanno andando.