Genesi del problema: da qui parte tutto

C'è una domanda che in discovery funziona quasi sempre: "Raccontami l'ultima volta che hai dovuto fare X."

Funziona perché non chiede opinioni, chiede memoria. E la memoria di un comportamento reale è l'unico dato semi-affidabile che una persona possa darti su sé stessa.

Il problema è che questa domanda si rompe nel momento in cui la capability di cui stai parlando non esiste ancora — tipicamente quando stai progettando qualcosa attorno all'AI, o un automatismo, o un servizio che nel mercato non ha precedenti. Non c'è un'ultima volta da raccontare. Quindi l'intervistato fa l'unica cosa che può fare: immagina.

E quando immagina, non immagina sé stesso. Immagina una versione idealizzata di sé: più organizzata, più motivata, più paziente, con più tempo. Quella persona adotterebbe volentieri il tuo prodotto. Quella persona però non esiste, e soprattutto non è quella che il lunedì mattina deve decidere se aprire il tuo tool o rifare la solita cosa a mano.

A questo si somma un secondo effetto: se descrivi l'idea prima di intervistare, tutto quello che senti dopo non è più una descrizione del lavoro della persona, è una reazione alla tua presentazione. E le reazioni sono cortesi.

Tre strade percorribili

Nessuna delle tre chiede all'intervistato di prevedere il futuro. Tutte e tre lo riportano su terreno verificabile.

1. Cerca il workaround, non il bisogno

Prima di nominare qualsiasi cosa, ricostruisci come la persona risolve oggi quel problema. Non in generale: l'ultima volta, in dettaglio, passo per passo, con nomi di file, di strumenti, di colleghi.

Quello che ti interessa non è il processo ufficiale. È il pezzo sporco: il foglio Excel parallelo, il messaggio su WhatsApp che sblocca l'approvazione, il copia-incolla ripetuto quattordici volte, la telefonata che serve perché il sistema non parla con l'altro sistema.

Il segnale più affidabile è l'imbarazzo. Le parti per cui la persona si scusa mentre le racconta — "lo so che è assurdo, ma…", "non dovrei farlo così però…" — sono esattamente i workaround.

Nessuno costruisce un workaround per un problema che non fa male. Il dolore lì è una reazione naturale al pericolo, o come in questo caso al problema, e la prova è che qualcuno ha investito fatica per aggirarlo.

Da lì ricavi il costo reale che ha quel problema: quanto tempo, quante persone coinvolte, quanti errori, quanto vale il rifacimento quando salta.

2. Fabbrica l'esperienza prima dell'intervista

Se il problema è che non esiste un ricordo, creane uno. Fai vivere l'esperienza, poi intervista con le tecniche normali: a quel punto c'è un'ultima volta di cui parlare.

Tre livelli, in ordine di costo crescente:

L'argomento contro questo approccio è sempre stato il costo. Oggi quell'argomento regge molto meno: costruire un proxy credibile costa una frazione di quello che costava, e in molti casi si fa in giorni.

Il punto non è validare l'interfaccia. È generare un comportamento osservabile da cui partire.

3. Sposta il discorso dalla funzionalità alla decisione

Quasi ogni capability nuova, se la spogli, non aggiunge uno strumento: cambia una decisione. La rende più veloce, più informata, delegabile a qualcun altro, oppure la elimina.

Allora smetti di parlare di funzionalità e parla di quella decisione, che esiste già oggi:

• Chi la prende, oggi?
• Sulla base di quali informazioni? Quali di queste sono mancanti o arrivano tardi?
• Quando è stata l'ultima volta che è andata male?
• Cosa è costato quando è andata male?
• Un mese dopo, come fa a sapere se aveva deciso bene?

Nessuna di queste domande richiede immaginazione. Tutte producono materiale utilizzabile: se scopri che la decisione la prende una persona diversa da quella che pensavi, o che l'errore costa molto meno di quanto stimavi, hai imparato più che da dieci "sì, lo userei".

Test di prontezza: puoi già intervistare?

Prima di calendarizzare, completa questa frase:

"Oggi, quando devono ottenere ______ (risultato), fanno ______ (comportamento concreto)."

Se non riesci a riempire entrambi gli spazi con qualcosa di specifico e verificabile, non sei pronto per interviste strutturate. Ti serve prima una fase di osservazione: guardare le persone lavorare, leggere i ticket di supporto, farti mostrare gli schermi.

Attenzione: "usano Excel" non basta. "Ogni venerdì mattina esportano il gestionale in CSV, lo incollano in un foglio condiviso e riconciliano a mano le righe che non tornano" — quello sì.

Checklist operativa

Prima dell'intervista

• Ho completato la frase del test di prontezza con dati concreti
• Ho scritto quale decisione la capability andrebbe a cambiare (non quale funzionalità aggiunge)
• Ho definito cosa mi farebbe cambiare idea sull'ipotesi (se nessuna risposta può smentirmi, l'intervista è teatro)
• Ho scelto persone che il problema ce l'hanno adesso, non che potrebbero averlo
• Ho deciso se serve un proxy (prototipo / Mago di Oz / concierge) e a che livello
• La traccia non contiene nessuna descrizione della soluzione nei primi due terzi

Durante l'intervista

• Ho aperto con l'ultima volta reale, non con uno scenario ipotetico
• Ho chiesto di camminare nel processo passo per passo, non di riassumerlo
• Ho annotato ogni punto in cui si è scusato o giustificato → workaround
• Ho quantificato: quanto tempo, quante persone, ogni quanto, quanto costa quando salta
• Ho chiesto chi decide, con quali informazioni, e l'ultima volta che è andata storta
• Quando è emersa un'opinione ("sarebbe utile…") l'ho riportata a un fatto ("l'ultima volta che è successo, cosa hai fatto?")
• Non ho corretto, completato o difeso nulla
• Ho lasciato i silenzi

Segnali da pesare, in ordine di affidabilità

1. Ha già speso qualcosa per aggirare il problema — tempo ricorrente, soldi, un tool comprato, una persona dedicata
2. Ha costruito un workaround stabile, non un'eccezione una tantum
3. Ricorda un episodio specifico in cui è andata male, con dettagli e conseguenze
4. Sa dire cosa è costato, anche approssimativamente

1. Dice che è un problema importante
2. Dice che lo userebbe
3. Dice che lo pagherebbe (la più debole di tutte, se non c'è nulla sopra)

Dopo l'intervista

• Ho separato nelle note fatti osservati da opinioni dichiarate
• Ho estratto i workaround in una lista a parte, con il costo associato
• Ho aggiornato o smentito l'ipotesi sulla decisione da cambiare
• So dire cosa ho imparato che non sapevo prima (se la risposta è "niente", rivedo la traccia, non gli intervistati)

Trappole ricorrenti

Sintesi in una riga

Continua il manuale