Come raccogliere feedback sul prodotto e richieste di funzionalità da Reddit, X e Hacker News

Perché i consueti canali di feedback se lo lasciano sfuggire

La maggior parte dei team raccoglie feedback da tre fonti: ticket di supporto, un widget in-app e chiamate di vendita. Tutte e tre presentano lo stesso bias: ascoltano solo le persone che stanno già parlando con te.

I thread pubblici sono diversi. Chi ha disdetto l'abbonamento il mese scorso non compilerà il tuo sondaggio, ma spiegherà volentieri su Reddit perché se n'è andato. Un potenziale cliente che mette a confronto vari strumenti elencherà ciò che manca al tuo in un post del tipo «quale dovrei scegliere?». È un feedback che non otterresti mai in altro modo, e spesso si accompagna a risposte di altri utenti che concordano o meno, indicandoti quanto sia diffuso il problema.

Il problema è il volume. Se cerchi il nome del tuo prodotto una volta alla settimana, troverai una manciata di thread, di solito troppo tardi per rispondere. Se imposti un avviso generico sul tuo nome, riceverai ogni singola menzione, comprese quelle che non hanno nulla a che fare con il prodotto. Il trucco sta nel creare avvisi che cerchino specificamente feedback.

Scrivere avvisi mirati al feedback

Un avviso di KWatch trova corrispondenze per ogni parola chiave nel suo elenco, quindi le virgole agiscono come un AND. È questo che rende efficaci gli avvisi di feedback. Invece di un unico avviso sul nome del tuo prodotto, abbini il nome ai termini usati dalle persone quando desiderano una modifica.

Ecco una serie di partenza, con «acme» a rappresentare il nome del tuo prodotto:

1. acme, wish e acme, would be nice per richieste di funzionalità
2. acme, bug e acme, broken per segnalazioni di bug
3. acme, switched e acme, cancelled per motivi di abbandono
4. acme, missing e acme, doesn't support per lacune riscontrate durante la valutazione

Ogni riga è un avviso separato, poiché un avviso con tutte quelle parole richiederebbe che fossero tutte presenti nello stesso post. Probabilmente perfezionerai il testo dopo una settimana, non appena vedrai come si esprimono i tuoi utenti. Le persone scrivono raramente le parole «feature request», quindi cerca le frasi che usano davvero, come «sarebbe fantastico se».

Pochi filtri svolgono la maggior parte del lavoro di pulizia. Su Reddit e Hacker News, attiva Solo parole intere se il nome del tuo prodotto è breve o comune, in modo che «acme» non corrisponda a «acmeplex». Aggiungi gli account del tuo team come Utenti esclusi, così che le tue risposte e i tuoi post di lancio non attivino avvisi. Se hai un subreddit dedicato al tuo prodotto, puoi creare un avviso separato limitato a esso con Subreddit inclusi ed eliminare del tutto la seconda parola chiave, poiché quasi tutto ciò che vi viene pubblicato è comunque feedback.

Le parole chiave escluse funzionano all'opposto di quelle incluse. Le parole chiave incluse devono corrispondere tutte, ma un post viene scartato non appena compare anche una sola parola chiave esclusa. Mantieni quell'elenco breve e specifico, altrimenti escluderai feedback autentici insieme al rumore. Il nostro articolo su ridurre il rumore negli avvisi per parole chiave esamina ogni filtro in modo più dettagliato.

Dove ascoltare per prima cosa

Non tutte le piattaforme offrono lo stesso tipo di feedback. Trovo che Reddit e Hacker News siano i luoghi in cui le persone scrivono i reclami lunghi e dettagliati. X è più breve e pungente, il che è utile per individuare rapidamente un rilascio difettoso. Linkedin è composto perlopiù da elogi e annunci, quindi si trova più in basso in questo elenco a meno che tu non venda a persone che scrivono lì dei propri strumenti operativi.

Anche la velocità varia a seconda della piattaforma, e questo incide su come utilizzerai ciascun avviso. Queste sono le frequenze di aggiornamento riportate nella nostra documentazione:

Per il feedback, nessuna di queste è lenta. Ciò che la tabella ti mostra è che un thread di Hacker News può raggiungerti mentre è ancora in prima pagina, ossia il momento in cui la risposta di un membro del team ha il massimo impatto.

Far pervenire il feedback al team di prodotto

Un avviso che nessuno legge non è altro che una ricerca più gradevole. Il passaggio che i team spesso tralasciano è decidere dove recapitare il feedback e chi lo visualizza.

La configurazione più semplice è un canale Slack dedicato. KWatch consente di impostare un webhook di Slack per singolo avviso, e un webhook per avviso sovrascrive quello impostato a livello di account. In questo modo i tuoi avvisi di vendita possono continuare a confluire nel canale di vendita, mentre gli avvisi di feedback finiscono in un canale come #product-feedback. I product manager e gli sviluppatori che hanno solo bisogno di leggere possono unirsi al tuo team KWatch con il ruolo Reader, che riceve notifiche ma non può creare o eliminare avvisi.

Se desideri conteggiare le richieste nel tempo, invia invece gli stessi avvisi a un webhook API. Ciascuna corrispondenza arriva come payload JSON. Ecco l'esempio tratto dalla nostra documentazione:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

Indirizza questo webhook a Zapier o n8n e aggiungi una riga a un foglio di calcolo, con una colonna per ciascun campo. Il campo query ti dice quale avviso si è attivato, così un avviso di richiesta e uno di bug si ordinano da soli. Il campo sentiment (positivo, negativo o neutro) ti offre un modo rapido per estrarre subito i post più critici. Abbiamo spiegato la configurazione di Zapier e n8n passo dopo passo se non ne hai mai configurata una prima.

Anche gli avvisi via email funzionano, ma i post lunghi vengono troncati nelle email. Le richieste di funzionalità tendono a essere lunghe, quindi Slack o un webhook rappresentano la soluzione più indicata in questo caso.

Cosa fare con le informazioni trovate

Una volta che il feedback inizia ad arrivare, la tentazione è rispondere a tutto. Consiglio di trattenersi un po'. Una risposta breve e utile da parte di chi lavora chiaramente al prodotto («è nella nostra lista, ecco una soluzione provvisoria per ora») fa un'ottima impressione. Una serie di risposte che terminano tutte con un link di iscrizione ti procurerà downvote e, su alcuni subreddit, il ban.

L'abitudine più preziosa è la revisione settimanale. Una volta alla settimana, un membro del team di prodotto esamina il canale o il foglio di calcolo ed etichetta ciascun elemento: richiesta, bug, motivo di abbandono o non pertinente. Dopo un mese avrai un conteggio indicativo di ciò che le persone chiedono in pubblico, a confronto con ciò che chiedono nei ticket. Quando le due liste non concordano, è proprio lì che si trovano gli spunti più interessanti.

Se una parte del tuo feedback più utile proviene da una manciata di persone note (utenti esperti, analisti, il fondatore di un concorrente) anziché da parole chiave, il nostro prodotto gemello MultiFollow segue account specifici di Linkedin e X e ti avvisa quando pubblicano, integrando perfettamente gli avvisi per parole chiave.