Product discovery: capire cosa vale la pena costruire

La product discovery è il lavoro che un team fa per capire quale problema valga la pena risolvere, e per chi, prima di impegnarsi a costruire una soluzione. La definizione è tutta qui. Il resto è tecnica.

Quasi tutti i team che incontro non hanno un problema di metodi. Hanno guide per le interviste, opportunity tree, template per gli esperimenti. Quello che manca è la disponibilità a lasciarsi far cambiare idea dalla discovery. La roadmap è già stata promessa, la feature ha già un nome, e la discovery diventa una messinscena: interviste fatte per confermare una decisione già presa.

Per distinguere la discovery vera dalla messinscena basta una domanda: quale evidenza ti convincerebbe a non costruirlo? Se nessuno sa rispondere, non è discovery. È documentazione a supporto di una decisione presa prima.

Una buona discovery parte dalla decisione, non dal metodo. Che cosa stiamo cercando di decidere, esattamente? Se il problema esiste, se la nostra soluzione funziona, se le persone cambieranno abitudini per usarla? Ognuna di queste domande chiede evidenze diverse, e quasi sempre serve molta meno struttura di quanto i team pensino. Non tutte le domande meritano un A/B test. A volte bastano cinque conversazioni sincere e la disciplina di ascoltare davvero le risposte.

L'obiezione classica è che la discovery rallenta la delivery. La mia esperienza dice il contrario: i team saltano la discovery per andare veloci e poi passano trimestri a rilasciare varianti di qualcosa che nessuno aveva chiesto. Rallentare all'inizio rende più veloce tutto quello che viene dopo, perché la direzione regge sotto pressione invece di cambiare a ogni riunione con gli stakeholder.

Con l'AI questo è ancora più vero. Oggi fai in poche ore un prototipo che prima richiedeva settimane, quindi puoi mettere qualcosa di concreto davanti agli utenti quasi subito. Per la discovery è un regalo, ma anche una trappola: costruire più in fretta vuol dire anche validare più in fretta nella direzione sbagliata, scambiando la velocità delle iterazioni per la qualità di quello che impari.

I team che fanno bene discovery non la vivono come una fase che finisce quando parte lo sviluppo. La vivono come un ritmo: l'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 si sta andando.