Le interviste discovery servono decision log

Molti team non hanno un problema di poche interviste. Hanno un problema di decisioni poco visibili.

Il founder apre una cartella piena di note. Il product lead mostra un file con pain point ordinati per tema. Il designer ha registrazioni, clip e highlight. Tutti possono dire di aver parlato con gli utenti. Poi però la roadmap viene decisa nella solita riunione, guidata dall’opinione più forte, dal cliente più rumoroso o dalla feature che aveva già sponsor interni.

Il punto debole è qui. Le interviste discovery servono decision log, non trascrizioni.

Le trascrizioni conservano ciò che è stato detto. Un decision log conserva ciò che il team ha cambiato perché ha imparato qualcosa. La differenza è sostanziale, perché la discovery non dovrebbe essere un archivio. Product Talk definisce la continuous discovery come touchpoint settimanali con i clienti, svolti dal team che costruisce il prodotto, con piccole attività di ricerca orientate a un outcome: Product Talk sulla continuous discovery. L’artefatto quindi deve collegare apprendimento e movimento.

Se il team non sa spiegare quale decisione è cambiata dopo le ultime cinque interviste, forse sta facendo ricerca interessante, ma non sta ancora usando la discovery come pratica operativa.

Le interviste non sono l’artefatto finale

Le note di intervista sono materiale prezioso. Aiutano a ricordare parole, contesto, obiezioni, vincoli, workaround ed esempi concreti. Possono però diventare anche una pila rassicurante di evidenze che nessuno usa davvero.

Il problema non è la trascrizione in sé. Il problema è che la trascrizione è troppo lontana dalla scelta di prodotto. Racconta una conversazione, non l’impegno che ne consegue. Può dirti che tre utenti si sono lamentati dell’onboarding, due hanno chiesto integrazioni e uno non ha capito il pricing. Non ti dice automaticamente che cosa farà il team, quale assunzione è diventata più fragile o quale rischio è diventato più urgente.

Così la discovery sembra piena di attività, mentre le decisioni restano uguali. Si fissano call, si taggano insight, si condividono note su Slack, si aggiungono citazioni in Notion. Poi la prioritizzazione succede altrove. La roadmap ha la sua inerzia. Il sales ha il suo percorso di escalation. Il leadership team ha la sua narrativa. La discovery diventa un archivio parallelo.

Un decision log porta le evidenze nel punto in cui il prodotto viene davvero modellato. Obbliga il team a rispondere a una domanda semplice dopo ogni ciclo di discovery: che cosa siamo disposti a decidere diversamente adesso?

Questo si collega direttamente a Discovery non è chiedere ai clienti cosa vogliono. I clienti possono descrivere situazioni, attriti, alternative e conseguenze. Non possono portare la responsabilità della strategia prodotto. Quella resta al team. Il log rende questa responsabilità esplicita.

Che cosa deve contenere il decision log?

Un decision log deve essere abbastanza semplice da essere aggiornato ogni settimana. Se diventa un database di ricerca, morirà. Se diventa burocrazia, verrà evitato. La versione utile è una tabella leggera con sette campi.

Il primo campo è la decisione. È la scelta di prodotto sotto osservazione. Per esempio: mantenere l’onboarding self service per i piccoli team, rimuovere uno step avanzato dalla prima sessione, oppure rimandare l’integrazione con Salesforce finché il problema di activation non è più chiaro.

Il secondo campo è l’assunzione. Ogni decisione poggia su una convinzione. Può essere che i nuovi utenti capiscano subito la proposta di valore, che l’admin sia il primo utente giusto, che i team invitino colleghi prima di vedere valore, o che l’assenza di una certa integrazione sia il blocco principale. Scrivere l’assunzione impedisce al team di nascondersi dietro insight vaghi.

Il terzo campo è l’evidenza. Qui entrano le interviste, ma in forma compressa. Non tutte le citazioni hanno lo stesso peso. L’evidenza dovrebbe indicare il tipo di fonte e il pattern. Per esempio: cinque trial user recenti hanno abbandonato il setup alla schermata dei permessi; tre call sales hanno citato l’integrazione, ma solo dopo domande di procurement; due account attivati hanno usato un workaround manuale senza chiedere la feature.

Il quarto campo è la confidence. Non serve una finta precisione. Bassa, media e alta spesso bastano. Il valore non sta nel sembrare scientifici. Sta nell’ammettere se il team sta agendo su un segnale, su un pattern ancora debole o su una scommessa necessaria.

Il quinto campo è l’owner. Una decisione senza owner diventa una nota. L’owner non è sempre chi esegue. È chi mantiene viva la decisione, controlla se nuove evidenze la modificano e la riporta in discussione quando serve.

Il sesto campo è la data. La discovery invecchia. Un pattern forte di sei mesi fa può essere ancora valido, ma non dovrebbe guidare scelte attuali senza essere visto. La data rende visibile l’età dell’evidenza.

Il settimo campo è la prossima review. È ciò che trasforma il log da documentazione a ritmo operativo. Una decisione può essere rivista dopo dieci nuove interviste, dopo una release, dopo un test di pricing o dopo che la prossima coorte ha completato o abbandonato l’onboarding.

Una riga concreta potrebbe essere questa: decisione, rimuovere l’invito obbligatorio al team dal primo onboarding. Assunzione, l’utente deve sperimentare valore da solo prima di invitare colleghi. Evidenza, quattro trial user su sei si sono bloccati all’invito, mentre due account attivati hanno invitato altri solo dopo aver completato un task centrale. Confidence, media. Owner, Product Lead. Data, 13 luglio 2026. Prossima review, dopo i prossimi 20 trial signup.

Quella riga vale più di una trascrizione perfetta che nessuno rilegge.

Come cambia il lavoro settimanale di prodotto?

Il decision log funziona quando entra nella cadenza già esistente del team. Non dovrebbe creare una nuova cerimonia, a meno che serva davvero.

Un ritmo pratico è semplice. Prima della review settimanale, il product lead aggiorna il log con le nuove evidenze. Durante la review, il team guarda solo le decisioni la cui confidence è cambiata, la cui data di review è arrivata o la cui evidenza contraddice il piano attuale. Dopo la review, gli owner aggiornano la prossima azione.

Questo tiene la discovery vicina alla prioritizzazione. Se un pattern suggerisce che stanno entrando nel funnel gli utenti sbagliati, il log può collegare interviste, acquisition e activation. È lo stesso problema operativo discusso in La trial non è rotta: stai portando dentro gli utenti sbagliati. Il feedback non è neutro. Un trial user che non avrebbe dovuto entrare nel prodotto può generare rumore che sembra insight.

Il log aiuta anche a distinguere tipi di decisione. Alcune scelte sono reversibili e possono essere prese con confidence media. Altre toccano architettura, positioning, pricing o impegni enterprise, e richiedono evidenze più robuste. Qui serve product leadership. SVPG sostiene che i product team sono responsabili di soluzioni valuable, usable, feasible e viable, e che la discovery serve ad affrontare questi rischi prima di investire pesantemente in delivery: SVPG sul product operating model.

Un decision log non sostituisce il giudizio. Migliora le condizioni in cui il giudizio viene esercitato. Mostra se il team sta imparando sul rischio di valore, usabilità, fattibilità, sostenibilità di business, oppure se sta solo collezionando opinioni.

L’obiezione: abbiamo già le note di ricerca

Le note di ricerca rispondono a un’altra domanda: che cosa abbiamo sentito? Il decision log risponde a una domanda più operativa: che cosa abbiamo cambiato, fermato, continuato o deciso di rivedere perché lo abbiamo sentito?

La distinzione diventa importante quando il team cresce. Finché il founder partecipa a quasi tutte le conversazioni, alcune decisioni possono vivere nella memoria. Ma non scala. Un nuovo product manager non può ricostruire il ragionamento da una cartella di registrazioni. Un designer non può sapere se una richiesta feature è stata scartata perché non valida, prematura, troppo costosa o semplicemente dimenticata. Engineering non può capire se un cambio tardivo nasce da nuova evidenza o da ansia rinnovata.

Il decision log crea una traccia condivisa. Riduce le discussioni ripetute perché il team vede perché una scelta è stata fatta. Migliora l’onboarding di nuove persone perché mostra il percorso, non solo la roadmap attuale. Rende anche il dissenso più utile. Invece di discutere preferenze, si può sfidare l’assunzione, l’evidenza, il livello di confidence o la data di review.

Questa è cultura prodotto più sana. Non una cultura in cui ogni decisione è bloccata per sempre, ma una cultura in cui le decisioni sono abbastanza esplicite da poter essere migliorate.

Dove aiuta un fractional product lead

Un fractional product lead spesso entra quando la discovery esiste già, ma la traccia decisionale è debole. Il team ha call con clienti, note sales, ticket support, analytics e intuizione del founder. Manca un modo ripetibile per trasformare quel materiale in scelte di prodotto.

La prima mossa non è installare un grande sistema di ricerca. È auditare le ultime dieci decisioni di prodotto significative. Per ciascuna, chiedere: quale assunzione abbiamo fatto, quale evidenza la supportava, chi ne era owner, quando andava rivista e che cosa ci avrebbe fatto cambiare idea?

Se le risposte non sono chiare, il team non ha ancora bisogno di più trascrizioni. Ha bisogno di un decision log.

La discovery che non cambia una decisione è solo inventario di ricerca. Lo standard operativo è semplice: dopo le interviste, il team dovrebbe poter indicare decisione, assunzione, evidenza, confidence, owner, data e prossima review. Tutto il resto può anche sembrare ascolto del cliente, ma non cambierà il prodotto in modo affidabile.