Il tuo team sta per sviluppare una nuova funzionalità. Quanto state scommettendo senza sapere se qualcuno la userà? Lo vediamo ogni giorno: startup che bruciano budget su feature mai validate, con il contabile che piange (e noi lo sappiamo perché veniamo dalla contabilità).
Noi, di Meteora Web, abbiamo imparato sulla nostra pelle: quando costruivi software per clienti reali, ogni riga di codice non validata è un costo che non torna indietro. Ecco perché la product discovery non è un lusso da metodologi agili: è il primo strumento per non fallire con le finanze dell'azienda.
In questa guida operativa ti portiamo dritto al cuore della discovery: user research attraverso interviste e come trasformare i risultati in un problem statement che guida le decisioni. Niente teoria astratta, solo quello che funziona nei progetti reali (e che abbiamo testato con clienti dal retail al B2B).
Perché la maggior parte delle interviste fallisce (e come evitarlo)
L'errore più comune: trattare l'intervista come un questionario. Fai domande del tipo: “Ti piacerebbe una funzione che fa X?”. La risposta è quasi sempre sì, ma non significa nulla. Le persone vogliono essere educate, e le loro intenzioni non corrispondono ai comportamenti.
L'approccio che usiamo noi: interviste contestuali basate su esperienze passate. Chiedi non cosa vorrebbero, ma cosa hanno effettivamente fatto. Esempio: invece di “Vorresti un sistema che ti avvisi quando un prodotto scende di prezzo?”, chiedi: “Raccontami l'ultima volta che hai cercato un prodotto scontato. Come hai fatto? Quanto tempo hai speso? Cosa ti ha fatto desistere?”.
Questo tipo di domanda produce dati reali, non opinioni. E i dati reali sono quelli che ci servono per calcolare il ROI delle decisioni di prodotto.
Le 3 regole per interviste che funzionano
- Non parlare del tuo prodotto. Mai. L'intervista esplora il problema, non la soluzione. Se nomini la tua idea, condizionerai la risposta.
- Chiedi storie, non scenari ipotetici. “Parlami dell'ultima volta che…” apre ricordi specifici, con dettagli comportamentali e contestuali.
- Fai silenzio. Dopo una domanda, aspetta. La maggior parte delle persone ha bisogno di qualche secondo per organizzare il pensiero. Se interrompi, perdi la profondità.
Noi abbiamo applicato queste regole in un progetto per una startup di e-commerce moda (ricordi? abbiamo gestito l'ERP di un negozio di abbigliamento). Le interviste ai buyer hanno rivelato che il loro vero problema non era “trovare nuovi fornitori” ma “valutare la qualità dei campioni in tempi stretti”. Quella scoperta ha cambiato completamente la roadmap e salvato mesi di sviluppo.
Template di domande per user research (copia e usa)
Ecco uno script base che usiamo noi. Personalizzalo sul tuo contesto, ma mantieni la struttura.
# Script intervista discovery (15-20 minuti)
1. Presentazione: “Grazie per il tuo tempo. L'obiettivo è capire come vivi [area problema]. Non c'è risposta giusta o sbagliata.”
2. Domanda di apertura: “Raccontami del tuo ruolo e di cosa ti occupi ogni giorno.” (costruisce contesto)
3. Esperienza specifica: “Parlami dell'ultima volta che hai affrontato [situazione problema].”
4. Dettagli: “Cosa hai fatto esattamente? Quanto tempo ci hai messo? Cosa ha funzionato e cosa no?”
5. Emozioni: “Come ti sei sentito durante quel processo?”
6. Alternative: “Cos'altro hai provato per risolvere questo problema?”
7. Chiusura: “C'è qualcos'altro che non ti ho chiesto e che pensi sia importante?”Dal caos delle interviste al Problem Statement
Dopo 10-15 interviste hai montagne di note, audio, trascrizioni. Come ne tiri fuori un problem statement che valga la pena sviluppare? Qui entra in gioco il nostro lato da ragionieri: bisogna quantificare.
Un problem statement efficace risponde a tre domande:
- Chi è l'utente target? (non demografico, ma comportamentale: “il buyer di moda che deve valutare 10 campioni a settimana”)
- Quale problema specifico affronta? (non “cattiva esperienza”, ma “non ha un metodo veloce per confrontare qualità e prezzo tra campioni fisici”)
- Quale impatto ha questo problema? (costi, tempo perso, opportunità mancate – con numeri reali se possibile)
Esempio di problem statement ben scritto:
“I buyer di abbigliamento che gestiscono più fornitori spendono in media 4 ore a settimana per confrontare i campioni fisici, con un tasso di errore del 15% nelle valutazioni qualitative. Questo ritarda le decisioni di acquisto e costa all'azienda circa 12.000 € a stagione in occasioni perse.”
Vedi la differenza? Non è vago. È misurabile. E perché è misurabile, puoi decidere se risolverlo vale l'investimento. Noi lo facciamo sempre: prima di sviluppare qualsiasi cosa, calcoliamo il costo del problema per il cliente. Se non supera la soglia di sviluppo, il problema non è prioritario.
Come costruire il tuo problem statement (passo passo)
- Raccogli tutte le note delle interviste e cerca pattern ricorrenti. Usa un foglio di calcolo o uno strumento come Miro (ma anche carta e penna funzionano).
- Identifica il contesto più frequente: in che situazione si manifesta il problema? Es: “durante la selezione dei campioni pre-stagione”.
- Quantifica la frequenza e l'impatto: quante persone, quante volte, quanto tempo/costi? Usa le storie raccolte: se 8 su 10 intervistati hanno menzionato lo stesso ritardo, hai un dato.
- Scrivi il problem statement in una frase seguendo la struttura: [Utente] ha [problema] che causa [impatto].
- Validalo con un paio di intervistati: “Abbiamo capito che il tuo problema è questo, corretto?” Se annuiscono, sei sulla strada giusta.
Errori comuni nella product discovery (e come evitarli)
Dopo oltre 8 anni sui progetti, abbiamo visto gli stessi errori ripetersi. Eccone tre che fanno più danni.
Intervistare solo “early adopters” entusiasti
Se parli solo con chi già ama il tuo prodotto, scoprirai solo come migliorarlo, non se il mercato più ampio lo vuole. Noi cerchiamo sempre di includere almeno un 30% di non utenti o ex-utenti. Loro raccontano perché hanno mollato.
Fermarsi dopo 3-4 interviste
Un errore tipico delle startup con budget stretto. Poche interviste possono dare una falsa sicurezza. La saturazione – quando non emergono più nuovi pattern – arriva solitamente tra 10 e 15 interviste. Noi puntiamo a 12 come minimo.
Trasformare il problem statement in una soluzione
“Il problema è che non hanno un'app per confrontare i campioni.” No. Il problema è che il confronto manuale richiede troppo tempo. L'app è solo una possibile soluzione. Se parti con la soluzione già in testa, chiudi la porta a idee migliori. Noi l'abbiamo visto accadere: un cliente voleva costruire un portale B2B, ma dopo le interviste è emerso che il vero bisogno era una semplice checklist digitalizzata su WhatsApp. Hanno risparmiato 6 mesi di sviluppo.
Strumenti pratici per la discovery
Non serve un budget da big tech. Ecco cosa usiamo noi quotidianamente:
- Registrazione audio/video: Otter.ai o semplicemente la registrazione di Zoom (con consenso). Ascoltare le pause e i toni è spesso più importante delle parole.
- Trascrizione automatica: Whisper (open source) o servizi come Rev. Le trascrizioni permettono di cercare keyword e pattern.
- Mappa delle affinità: Miro o una lavagna fisica. Raggruppa i temi emersi e cerca le connessioni.
- Template di problem statement: abbiamo creato un semplice Google Doc con la struttura: “Per [utente] che [contesto], il [problema] è importante perché [impatto].” Usalo e condividilo con il team.
In sintesi – cosa fare adesso
- Pianifica 12 interviste con utenti reali (inclusi non-clienti). Usa lo script template sopra.
- Conduci le interviste senza mai parlare della tua soluzione. Ascolta storie, non opinioni.
- Analizza i pattern e scrivi un problem statement quantificato per il problema più ricorrente.
- Validalo con almeno 2 intervistati.
- Decidi se il problema vale un investimento. Se sì, passa alla definizione della soluzione. Se no, torna alla discovery.
Noi, di Meteora Web, usiamo questo processo ogni volta che iniziamo un nuovo progetto – per un e-commerce, una piattaforma proprietaria o un semplice sito vetrina. Il prodotto giusto si costruisce prima nelle interviste, poi nel codice. E il codice costa, quindi meglio azzeccare la prima.
Per approfondire come le metodologie di product management si legano alla strategia digitale, dai un'occhiata al nostro articolo su come l'AI di Meta viene usata per attacchi ai customer agent – un esempio di come i problemi non validati portino a rischi di sicurezza. Se invece vuoi capire come proteggere il tuo stack mentre costruisci il prodotto, leggi l'attacco ai repo GitHub per rubare password degli sviluppatori AI.
Sponsored Protocol
