Hoe je productfeedback en feature requests verzamelt op Reddit, X en Hacker News

Waarom de gebruikelijke feedbackkanalen dit missen

De meeste teams verzamelen feedback uit drie bronnen: supporttickets, een in-app widget en verkoopgesprekken. Alle drie hebben ze dezelfde bias: ze horen alleen van mensen die al met je in gesprek zijn.

Openbare threads zijn anders. Iemand die vorige maand is afgehaakt, vult je enquête niet in, maar legt op Reddit graag uit waarom hij of zij is weggegaan. Een potentiële klant die tools vergelijkt, somt in een "welke moet ik kiezen?"-bericht precies op wat er aan die van jou ontbreekt. Dat is feedback die je op geen enkele andere manier zou krijgen, en het gaat vaak vergezeld van reacties van andere gebruikers die het ermee eens of oneens zijn, wat je vertelt hoe vaak het probleem voorkomt.

Het addertje onder het gras is het volume. Als je één keer per week naar je productnaam zoekt, vind je een handjevol threads, meestal te laat om nog te reageren. Als je een ongefilterde alert instelt op je naam, krijg je elke vermelding binnen, inclusief de berichten die niets met het product te maken hebben. De kunst is om alerts te schrijven die specifiek naar feedback zoeken.

Alerts schrijven die specifiek naar feedback zoeken

Een KWatch-alert matcht elk zoekwoord in de lijst, dus komma's werken als EN. Dat is precies wat feedback-alerts laat werken: in plaats van één alert op je productnaam koppel je de naam aan de woorden die mensen gebruiken wanneer ze willen dat er iets verandert.

Hier is een startset, waarbij "acme" staat voor je productnaam:

1. acme, wish en acme, would be nice voor feature requests
2. acme, bug en acme, broken voor bugmeldingen
3. acme, switched en acme, cancelled voor churn-redenen
4. acme, missing en acme, doesn't support voor ontbrekende functies waar mensen tijdens het evalueren tegenaan lopen

Elke regel is een aparte alert, omdat een alert met al die woorden zou vereisen dat ze allemaal in hetzelfde bericht voorkomen. Je zult de formulering na een week waarschijnlijk finetunen, zodra je ziet hoe je eigen gebruikers praten. Mensen typen zelden de woorden "feature request", dus zoek naar de zinnen die ze wél gebruiken, zoals "would be great if".

Een paar filters doen het meeste opschoonwerk. Schakel op Reddit en Hacker News "Alleen hele woorden" in als je productnaam kort of veelvoorkomend is, zodat "acme" niet matcht met "acmeplex". Voeg de accounts van je eigen team toe als "Uitgesloten gebruikers", zodat je eigen reacties en lanceringsberichten geen alerts triggeren. Als je een eigen subreddit voor je product hebt, kun je een aparte alert maken die daarop is gericht met "Ingesloten subreddits" en het tweede zoekwoord helemaal weglaten, aangezien bijna alles wat daar wordt geplaatst toch al feedback is.

Uitgesloten zoekwoorden werken precies andersom dan ingesloten zoekwoorden. Ingesloten zoekwoorden moeten allemaal overeenkomen, maar een bericht wordt overgeslagen zodra er één uitgesloten zoekwoord in voorkomt. Houd die lijst kort en specifiek, anders filter je echte feedback weg samen met de ruis. Ons artikel over het verminderen van ruis in keyword-alerts behandelt elk filter in meer detail.

Waar je als eerste moet luisteren

Niet elk platform levert hetzelfde soort feedback op. Naar mijn ervaring schrijven mensen op Reddit en Hacker News de lange, specifieke klachten. X is korter en feller, wat handig is om snel een haperende release op te merken. Linkedin bestaat vooral uit lof en aankondigingen, dus staat lager op deze lijst, tenzij je verkoopt aan mensen die daar over hun tooling posten.

De snelheid verschilt ook per platform, en dat verandert hoe je elke alert gebruikt. Dit zijn de verversingssnelheden uit onze documentatie:

Voor feedback is geen van deze snelheden traag. Wat de tabel laat zien, is dat een thread op Hacker News je kan bereiken terwijl deze nog op de voorpagina staat – precies het moment waarop een reactie van iemand uit het team het zwaarst weegt.

Het bij het productteam krijgen

Een alert die niemand leest, is gewoon een mooiere zoekopdracht. Het onderdeel dat teams meestal overslaan, is bepalen waar feedback binnenkomt en wie het te zien krijgt.

De eenvoudigste opzet is een speciaal Slack-kanaal. Met KWatch kun je per alert een Slack-webhook instellen, en een webhook per alert overschrijft de webhook op accountniveau. Zo kunnen je verkoop-alerts naar het verkoopkanaal blijven gaan, terwijl feedback-alerts naar bijvoorbeeld #product-feedback gaan. Productmanagers en engineers die alleen hoeven mee te lezen, kunnen lid worden van je KWatch-team met de rol "Reader", waarmee ze meldingen ontvangen maar geen alerts kunnen aanmaken of verwijderen.

Als je verzoeken in de loop van de tijd wilt tellen, stuur je dezelfde alerts naar een API-webhook. Elke match komt binnen als een JSON-payload. Hier is het voorbeeld uit onze documentatie:

{
  "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"
}

Koppel dit aan een Zapier- of n8n-webhook en voeg een rij toe aan een spreadsheet, met één kolom per veld. Het veld query laat zien welke alert is afgegaan, zodat verzoeken en bugmeldingen vanzelf gescheiden worden. Het veld sentiment (positief, negatief of neutraal) geeft je een snelle manier om boze berichten als eerste eruit te pikken. We hebben de Zapier- en n8n-configuratie stap voor stap beschreven als je dit nog niet eerder hebt ingesteld.

E-mailmeldingen werken ook, maar lange berichten worden in e-mails afgekapt. Feature requests zijn meestal vrij lang, dus Slack of een webhook past hier beter.

Wat te doen met wat je vindt

Zodra de feedback binnenstroomt, is de verleiding groot om overal op te reageren. Ik zou me een beetje inhouden. Een kort, nuttig antwoord van iemand die overduidelijk aan het product werkt ("dat staat op onze lijst, hier is voorlopig een tijdelijke oplossing"), doet al wonderen. Een reeks reacties die allemaal eindigen met een aanmeldlink levert je downvotes op, en op sommige subreddits zelfs een ban.

De waardevolste gewoonte is het wekelijkse overzicht. Eenmaal per week neemt iemand van het productteam het kanaal of de spreadsheet door en labelt elk item: verzoek, bug, reden voor churn of niet relevant. Na een maand heb je een goed beeld van waar mensen in het openbaar om vragen, afgezet tegen wat er via tickets binnenkomt. Wanneer die twee lijsten niet overeenkomen, wordt het pas echt interessant.

Als een deel van je nuttigste feedback niet uit zoekwoorden voortkomt, maar van een handvol bekende personen (power users, analisten, de oprichter van een concurrent), volgt ons zusterproduct MultiFollow specifieke LinkedIn- en X-accounts en waarschuwt het je wanneer zij iets posten, wat keyword-alerts uitstekend aanvult.