Il modo più costoso di scoprire che una feature non serve è costruirla. Lo dicono i dati: Pendo nel report State of Product 2024 stima che il 65% delle feature lanciate non venga mai usato dalla maggioranza degli utenti. La product discovery è il processo che dimezza questo spreco intervistando utenti, formulando ipotesi falsificabili e validandole con prototipi prima di scrivere una riga di codice. Qui dentro hai i metodi che puoi applicare da lunedì mattina senza budget e senza tool a pagamento.

Cos’è la product discovery e perché serve?

La product discovery è la fase del lavoro di Product Manager in cui formuli e validi ipotesi sul valore (l’utente lo vuole?), sull’usabilità (l’utente sa usarlo?), sulla fattibilità tecnica (sappiamo costruirlo?) e sulla sostenibilità di business (ha senso per il P&L?). Serve perché senza discovery costruisci feature che il cliente ha richiesto ma non userà, oppure che risolvono il problema sbagliato per il segmento sbagliato. Marty Cagan in Inspired sostiene che le tech company best-in-class dedicano il 50% del tempo del PM alla discovery e il 50% al delivery: non è opzionale.

Un esempio fashion concreto: un brand di lusso vuole lanciare un’app per la clientelizzazione. Senza discovery costruisce wishlist e push notification — feature standard. Con tre settimane di discovery scopre che il pain reale delle clienti VIP è il follow-up dello store associate dopo l’acquisto: vogliono che la commessa di Milano le chiami quando arriva una borsa simile, non ricevere notifiche generiche. L’MVP cambia: invece di un’app cataloghi, diventa un CRM mobile per gli store associate. Stesso budget, retention 3x.

Come si conducono le customer interview?

Teresa Torres in Continuous Discovery Habits propone l’intervista comportamentale: non chiedi all’utente cosa vuole (risposte teoriche inaffidabili), gli chiedi cosa ha fatto l’ultima volta che ha affrontato il problema. La struttura della singola intervista è sempre la stessa, 45 minuti:

• 5 minuti: contesto del partecipante (ruolo, anni di esperienza, ambiente di lavoro). Non vendi il prodotto, non spieghi cosa stai costruendo.
• 30 minuti: storia comportamentale. “Raccontami l’ultima volta che hai dovuto fare X. Quando è stato? Cosa è successo prima? Cosa hai usato? Cosa è andato male?”. Pesci di dettaglio, non di opinione.
• 10 minuti: validazione di ipotesi specifiche con mockup o esempi concreti. “Se ti dicessi che esiste uno strumento che fa Y, cosa cambierebbe nella tua giornata?”.

Le interviste vanno fatte continuativamente, non in batch da 20 all’inizio del progetto. Torres consiglia 3 interviste a settimana per il PM, ogni settimana dell’anno. Dopo 12 interviste i pattern emergono; dopo 24 hai consenso statistico qualitativo. Se non puoi fare 3 interviste a settimana, il blocker non è il tempo: è l’organizzazione che non considera la discovery una priorità — un problema da affrontare prima del prodotto stesso.

Cos’è Jobs To Be Done e come lo applichi?

Il framework Jobs To Be Done (JTBD), formalizzato da Clayton Christensen ad Harvard, sostiene che gli utenti non comprano prodotti: assumono prodotti per fare un lavoro. Il classico esempio del milkshake McDonald’s: le persone non compravano il milkshake al mattino perché avevano fame, lo compravano perché serviva un compagno per il tragitto in auto — durava 25 minuti, una mano libera per guidare, niente briciole. Il job era “rendere meno noioso il pendolarismo”, non “fare colazione”. Il concorrente del milkshake non era il caffè, era la radio.

Per applicare JTBD scrivi i job statement nel formato: “Quando <contesto>, voglio <motivazione>, così posso <esito atteso>”. Esempio pharma: “Quando un paziente cronico inizia una nuova terapia, voglio sapere se sta assumendo correttamente le dosi, così posso intervenire prima di una crisi”. Il job non è “dare farmaci” — è “prevenire ricadute”. Il prodotto giusto può essere un’app, un wearable, una telefonata settimanale di un infermiere: la soluzione dipende dal contesto, ma il job rimane stabile per anni. Cambi le soluzioni, non i job.

Come validi con prototipi senza buttare settimane?

La validation è la terza gamba della discovery. Le tecniche da meno a più costose sono: landing page test (1-3 giorni, misuri click-through su una promessa di prodotto), concierge test (1-2 settimane, fornisci il servizio manualmente a 5-10 utenti per validare che lo paghino), wizard of oz (1-2 settimane, l’utente vede un prodotto che sembra automatico ma dietro ci sei tu), prototipo Figma cliccabile (3-5 giorni, validi usabilità e flusso). Solo dopo aver passato almeno due di queste fasi vai in sviluppo. Un PM che salta validation perché “tanto poi vediamo in produzione” sta firmando un assegno medio di 4-6 settimane di sviluppo sprecato — con costi engineering italiani fra 25K e 40K per sprint, vale la pena passare una settimana a prototipare.

La discovery è una competenza pratica: si impara facendola, non leggendo libri. Nel programma del Master dedichi 4 settimane a customer interview reali con utenti pharma e fashion, scrivi 2 business case completi con JTBD e prepari un portfolio di discovery da mostrare in colloquio.