Як збирати зворотний зв'язок та запити на нові функції з Reddit, X та Hacker News

Чому звичайні канали зворотного зв'язку це пропускають

Більшість команд збирають зворотний зв'язок із трьох джерел: тікети підтримки, віджет у додатку та дзвінки з продажів. Усі три мають одне й те саме упередження: ви чуєте лише тих людей, які вже спілкуються з вами.

Публічні обговорення зовсім інші. Той, хто скасував підписку минулого місяця, не буде заповнювати ваше опитування, але із задоволенням пояснить на Reddit, чому пішов. Потенційний клієнт, який порівнює інструменти, перелічить недоліки вашого продукту в дописі «що мені обрати?». Це зворотний зв'язок, який ви ніколи не отримали б іншим шляхом, і до нього часто додаються відповіді інших користувачів, які погоджуються або не погоджуються, показуючи, наскільки поширена проблема.

Складність полягає в обсязі. Якщо шукати назву свого продукту раз на тиждень, ви знайдете кілька обговорень, і зазвичай буде запізно відповідати. Якщо налаштувати звичайне сповіщення на назву, ви отримаєте кожну згадку, включно з тими, що взагалі не стосуються продукту. Хитрість полягає в тому, щоб налаштувати сповіщення, спрямовані саме на пошук зворотного зв'язку.

Створення сповіщень для пошуку зворотного зв'язку

Сповіщення KWatch зіставляє кожне ключове слово у своєму списку, тому коми працюють як оператор AND. Саме завдяки цьому працюють сповіщення для зворотного зв'язку. Замість одного сповіщення на назву продукту ви поєднуєте назву зі словами, які люди використовують, коли хочуть щось змінити.

Ось початковий набір, де «acme» позначає назву вашого продукту:

1. acme, wish та acme, would be nice для запитів на функції
2. acme, bug та acme, broken для звітів про помилки
3. acme, switched та acme, cancelled для причин відтоку клієнтів
4. acme, missing та acme, doesn't support для недоліків, виявлених під час оцінювання продукту

Кожен рядок — це окреме сповіщення, оскільки для сповіщення з усіма цими словами знадобилося б, щоб усі вони були присутні в одному дописі. Ймовірно, ви скоригуєте формулювання через тиждень, коли побачите, як висловлюються ваші власні користувачі. Люди рідко пишуть слова «запит на функцію» («feature request»), тому шукайте фрази, якими вони дійсно користуються, наприклад «було б чудово, якби» («would be great if»).

Кілька фільтрів виконують основну частину очищення. На Reddit та Hacker News увімкніть опцію «Тільки цілі слова» (Whole Words Only), якщо назва вашого продукту коротка або поширена, щоб «acme» не збігалося з «acmeplex». Додайте акаунти власної команди до списку «Виключені користувачі» (Excluded Users), щоб ваші відповіді та дописи про релізи не викликали сповіщень. Якщо у вас є сабреддіт продукту, можна створити окреме сповіщення для нього за допомогою «Включені сабреддіти» (Included Subreddits) і взагалі прибрати друге ключове слово, оскільки майже все, що там публікується, у будь-якому разі є зворотним зв'язком.

Виключені ключові слова діють протилежно до включених. Усі включені ключові слова мають збігатися, але допис відкидається, щойно в ньому з'являється будь-яке виключене ключове слово. Тримайте цей список коротким і конкретним, інакше ви відфільтруєте справжній зворотний зв'язок разом із шумом. Наша стаття про зменшенні шуму в сповіщеннях за ключовими словами детальніше розглядає кожен фільтр.

Де слухати насамперед

Не кожна платформа дає однаковий зворотний зв'язок. З мого досвіду, Reddit та Hacker News — це місця, де люди пишуть довгі та детальні скарги. На X публікації коротші та гостріші, що зручно для швидкого виявлення проблемного релізу. Linkedin здебільшого містить похвалу та анонси, тому він займає нижче місце в цьому списку, якщо ви не продаєте інструменти людям, які пишуть про свої робочі процеси саме там.

Швидкість також різниться залежно від платформи, і це змінює спосіб використання кожного сповіщення. Ось частота оновлення з нашої документації:

Для зворотного зв'язку жодна з цих швидкостей не є повільною. Таблиця показує, що обговорення на Hacker News може надійти до вас, поки воно все ще на головній сторінці, тобто в момент, коли відповідь від учасника команди має найбільшу вагу.

Передача інформації продуктовій команді

Сповіщення, яке ніхто не читає, — це просто дещо зручніший пошук. Етап, який команди зазвичай пропускають, — це визначення того, куди потрапляє зворотний зв'язок і хто його бачить.

Найпростіший варіант — окремий канал у Slack. KWatch дозволяє налаштувати вебхук Slack для кожного сповіщення, причому вебхук для окремого сповіщення перевизначає загальний вебхук облікового запису. Таким чином, сповіщення для відділу продажів можуть і надалі надходити в канал продажів, а сповіщення про зворотний зв'язок — у канал на зразок #product-feedback. Продакт-менеджери та інженери, яким потрібно лише читати, можуть приєднатися до вашої команди KWatch із роллю Reader: вона отримує сповіщення, але не може створювати або видаляти їх.

Якщо ви хочете відстежувати кількість запитів із плином часу, надсилайте ті самі сповіщення на вебхук API. Кожен збіг надходить як корисне навантаження JSON. Ось приклад із нашої документації:

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

Спрямуйте його на вебхук Zapier або n8n та додавайте рядок до електронної таблиці, виділивши по стовпцю для кожного поля. Поле query показує, яке саме сповіщення спрацювало, тож сповіщення про запит і повідомлення про помилку сортуються самі собою. Поле sentiment (позитивне, негативне або нейтральне) дає змогу швидко виокремити спочатку найбільш критичні дописи. Ми детально описали налаштування Zapier та n8n покроково, якщо ви раніше такого не підключали.

Сповіщення електронною поштою також працюють, але довгі дописи в листах обрізаються. Запити на функції зазвичай бувають довгими, тому Slack або вебхук підходять тут набагато краще.

Що робити зі знайденою інформацією

Коли надходить зворотний зв'язок, виникає спокуса відповідати на все поспіль. Я б радив трохи стриматися. Коротка корисна відповідь від того, хто явно працює над продуктом («це є в наших планах, а ось тимчасове рішення на цей час»), дає чудовий ефект. Натомість низка відповідей, які закінчуються посиланням на реєстрацію, призведе до мінусів, а на деяких сабреддітах — і до бану.

Набагато цінніша звичка — щотижневий огляд. Раз на тиждень хтось із продуктової команди переглядає канал або таблицю і позначає кожен пункт: запит, помилка, причина відтоку або не має відношення. Через місяць ви матимете приблизну кількість того, про що люди просять публічно, поруч із тим, про що вони пишуть у тікетах. Коли ці два списки розходяться, це зазвичай найцікавіший момент.

Якщо найкорисніший зворотний зв'язок надходить від кількох конкретних людей (активних користувачів, аналітиків, засновника компанії-конкурента), а не за ключовими словами, наш партнерський продукт MultiFollow відстежує певні облікові записи в Linkedin та X і сповіщає вас, коли вони публікують дописи, що чудово доповнює сповіщення за ключовими словами.