Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Quando si inizia a centralizzare il feedback dei clienti in uno strumento come Productboard, Harvestr, Dovetail o un sistema fatto in casa, una domanda emerge subito: come classificare bene un feedback che non parla sempre della stessa cosa?
Alcuni verbatim sono molto concreti:
- un fastidio su una schermata;
- una richiesta su una feature;
- un comportamento di prodotto giudicato negativo.
Altri sono molto più ampi:
- un bisogno trasversale;
- un job to be done;
- un vincolo di business;
- un obiettivo strategico.
È spesso qui che iniziano le difficoltà. Il problema non è solo «ordinare meglio» il feedback. Il problema è che un unico modello di classificazione non basta.
La trappola della classificazione su un solo asse
Molti team classificano il proprio feedback secondo una sola logica:
- per feature;
- per problema;
- per tema;
- per obiettivo;
- per tipo di cliente.
Il problema è che questa logica funziona bene per una parte del feedback, ma diventa instabile per tutto il resto.
Un approccio centrato esclusivamente sulle feature è pratico per gli attriti locali, ma riduce troppo in fretta il feedback a frammenti di prodotto. Si perdono così la logica di business, il bisogno trasversale o l'obiettivo sottostante.
Al contrario, un approccio centrato esclusivamente sugli obiettivi mantiene la prospettiva, ma diventa impreciso non appena occorre trattare un problema concreto su un percorso, una schermata o un'interazione.
In altre parole:
- un modello troppo locale manca di prospettiva;
- un modello troppo globale manca di precisione.
Il vero bisogno: coprire l'intero ambito senza complicare il sistema
La sfida non è aggiungere sempre più categorie.
Bisogna trovare un framework che sia:
- semplice da capire;
- rapido da usare;
- sufficientemente robusto;
- capace di coprire feedback che va dal molto strategico al molto tattico.
Qui sta tutta la difficoltà.
Con troppo poche classificazioni, si mescolano cose che non sono sullo stesso livello. Con troppe classificazioni, il sistema diventa faticoso da usare, e quindi poco adottato.
Il buon modello non è il più «elegante» in teoria. È quello che un team riesce a usare davvero nel tempo.
Il framework che scelgo: 4 classificazioni
Il modello che scelgo si basa su 4 classificazioni:
- Obiettivo di business
- Caso d'uso / JTBD
- Capacità di prodotto
- Punto di attrito locale
L'idea è semplice: classificare il feedback secondo il livello in cui si esprime.
1. Obiettivo di business
Si parla di obiettivo di business quando il cliente esprime:
- un traguardo commerciale;
- un vincolo organizzativo;
- una priorità operativa;
- un rischio;
- un'ambizione di trasformazione.
Esempi:
- armonizzare le pratiche tra più team;
- ridurre un rischio di conformità;
- migliorare la gestione;
- assorbire la crescita senza assumere ulteriore personale.
A questo livello, il cliente non parla ancora di una feature o di un caso d'uso preciso. Parla di ciò che conta per la sua attività.
2. Caso d'uso / JTBD
Si parla di caso d'uso / JTBD quando il cliente descrive ciò che vuole realizzare nel suo lavoro.
Siamo qui al livello dell'azione di business:
- qualificare un incidente;
- seguire un trattamento;
- confrontare più entità;
- ritrovare il contesto prima di agire;
- coordinare più persone.
Questo livello è particolarmente utile perché aiuta a capire il lavoro reale senza chiudere troppo presto l'analisi in una soluzione.
3. Capacità di prodotto
Si parla di capacità di prodotto quando il cliente esprime ciò che il prodotto dovrebbe permettere di fare.
Per esempio:
- configurare degli alert;
- gestire i diritti di accesso;
- consolidare uno storico;
- automatizzare un'assegnazione;
- collegare più oggetti o eventi tra loro.
Non siamo più al livello dell'obiettivo di business, ma non ancora al livello di un attrito locale. Siamo al livello della capacità attesa del prodotto.
4. Punto di attrito locale
Si parla di punto di attrito locale quando il feedback riguarda qualcosa di preciso nel prodotto:
- una schermata;
- una feature;
- un filtro;
- un pulsante;
- un modulo;
- un comportamento inatteso.
Esempi:
- il filtro si reimposta;
- il pulsante di esportazione è difficile da trovare;
- un campo deve essere reinserito;
- un modulo è troppo lungo.
È il livello più tattico, ma resta indispensabile. Un buon sistema di insight non deve perdere questa granularità.
La regola semplice per classificare bene il feedback
Per evitare le esitazioni, seguo una regola di classificazione molto semplice.
Il cliente parla di un traguardo commerciale o di un vincolo organizzativo? → Obiettivo di business
Parla di ciò che vuole realizzare nel suo lavoro? → Caso d'uso / JTBD
Parla di ciò che il prodotto dovrebbe permettere di fare? → Capacità di prodotto
Parla di una schermata, una feature, un comportamento o un attrito preciso? → Punto di attrito locale
Questa regola ha un merito essenziale: evita di classificare secondo il tema apparente, e spinge a classificare secondo il livello reale del segnale.
Perché questo framework mi sembra il giusto compromesso
Questo modello a 4 classificazioni mi sembra più solido di un approccio centrato esclusivamente sulle feature.
Perché? Perché il feedback di un cliente non parla sempre di una feature. Può anche parlare di:
- un bisogno trasversale;
- un problema di workflow;
- un vincolo organizzativo;
- un obiettivo di gestione;
- un'aspettativa più strategica.
Al contrario, questo framework mi sembra anche più utile di un approccio centrato esclusivamente sugli obiettivi.
Perché? Perché un buon sistema di gestione degli insight deve anche permettere di ritrovare il concreto:
- cosa blocca nel prodotto;
- cosa manca;
- cosa merita un miglioramento locale;
- cosa può alimentare direttamente discovery, design o backlog.
Questo framework tiene quindi meglio l'equilibrio tra altezza di visione e sfruttabilità operativa.
Conclusione
Classificare tutto il feedback dei clienti su un unico asse non è sufficiente. Funziona finché il feedback è omogeneo. Ma non appena si vuole coprire allo stesso tempo obiettivi di business, casi d'uso, capacità attese e attriti molto locali, il modello diventa troppo povero.
Il framework a 4 classificazioni che scelgo offre un compromesso migliore:
- Obiettivo di business
- Caso d'uso / JTBD
- Capacità di prodotto
- Punto di attrito locale
Resta semplice, copre l'intero ambito utile, e può essere usato in un vero strumento senza diventare un sistema complicato.
È questo modello che metterò in pratica nel mio progetto di Insight Manager. L'obiettivo non è solo ordinare meglio i verbatim. L'obiettivo è collegare meglio la voce del cliente alle decisioni di prodotto, con un sistema sufficientemente leggero per essere usato, e sufficientemente strutturato per restare utile nel tempo.
Per saperne di più
Il PM come architetto del Contesto Il secondo cervello è un vicolo cieco per il product management