Cómo recopilar feedback sobre el producto y solicitudes de funciones en Reddit, X y Hacker News

Por qué los canales habituales de feedback no lo detectan

La mayoría de los equipos recopilan feedback de tres fuentes: tickets de soporte, un widget en la aplicación y llamadas de ventas. Las tres tienen el mismo sesgo: solo escuchan a personas que ya están hablando contigo.

Los hilos públicos son diferentes. Alguien que canceló su suscripción el mes pasado no completará tu encuesta, pero explicará con gusto en Reddit por qué se fue. Un cliente potencial que compara herramientas enumerará lo que le falta a la tuya en una publicación de «¿cuál debería elegir?». Es un feedback que nunca obtendrías de otra manera, y a menudo viene acompañado de respuestas de otros usuarios que están de acuerdo o en desacuerdo, lo que te indica qué tan común es el problema.

El problema es el volumen. Si buscas el nombre de tu producto una vez a la semana, encontrarás un puñado de hilos, normalmente demasiado tarde para responder. Si configuras una alerta básica con tu nombre, recibirás todas las menciones, incluidas las que no tienen nada que ver con el producto. El truco consiste en crear alertas que busquen feedback específicamente.

Cómo redactar alertas que busquen feedback

Una alerta de KWatch coincide con cada palabra clave de su lista, por lo que las comas actúan como un AND. Eso es lo que hace que las alertas de feedback funcionen. En lugar de una sola alerta sobre el nombre de tu producto, combinas el nombre con las palabras que la gente usa cuando quiere que se cambie algo.

Aquí tienes un conjunto inicial, donde «acme» representa el nombre de tu producto:

1. acme, wish y acme, would be nice para solicitudes de funciones
2. acme, bug y acme, broken para informes de errores
3. acme, switched y acme, cancelled para motivos de cancelación
4. acme, missing y acme, doesn't support para carencias que los usuarios encuentran al evaluar

Cada línea es una alerta independiente, ya que una alerta con todas esas palabras requeriría que aparecieran todas en la misma publicación. Es probable que ajustes la redacción después de una semana, una vez que veas cómo se expresan tus propios usuarios. La gente rara vez escribe las palabras «feature request», así que busca las frases que sí usan, como «sería genial si».

Unos pocos filtros hacen la mayor parte de la limpieza. En Reddit y Hacker News, activa Solo palabras completas si el nombre de tu producto es corto o común, de modo que «acme» no coincida con «acmeplex». Añade las cuentas de tu propio equipo como Usuarios excluidos, para que tus respuestas y publicaciones de lanzamiento no activen alertas. Si tienes un subreddit de tu producto, puedes crear una alerta específica para él con Subreddits incluidos y prescindir por completo de la segunda palabra clave, ya que casi todo lo que se publica allí es feedback de todos modos.

Las palabras clave excluidas funcionan al revés que las incluidas. Las palabras clave incluidas deben coincidir todas, pero una publicación se descarta en cuanto aparece cualquiera de las palabras clave excluidas. Mantén esa lista corta y específica, o filtrarás feedback real junto con el ruido. Nuestro artículo sobre cómo reducir el ruido en las alertas por palabras clave repasa cada filtro con más detalle.

Dónde escuchar primero

No todas las plataformas te ofrecen el mismo tipo de feedback. Me parece que en Reddit y Hacker News es donde la gente escribe las quejas largas y específicas. En X es más breve y directo, lo que resulta útil para detectar rápidamente una versión con errores. En Linkedin predominan los elogios y los anuncios, por lo que está más abajo en esta lista a menos que vendas a personas que publiquen allí sobre sus herramientas de trabajo.

La velocidad también varía según la plataforma, y eso influye en cómo usarás cada alerta. Estas son las frecuencias de actualización de nuestra documentación:

Para el feedback, ninguna de estas opciones es lenta. Lo que te muestra la tabla es que un hilo de Hacker News puede llegarte mientras aún está en la página principal, que es el momento en que una respuesta de alguien del equipo tiene más peso.

Hacer llegar el feedback al equipo de producto

Una alerta que nadie lee no es más que una búsqueda más bonita. La parte que los equipos suelen pasar por alto es decidir dónde aterriza el feedback y quién lo ve.

La configuración más sencilla es un canal de Slack dedicado. KWatch te permite configurar un webhook de Slack por alerta, y un webhook específico por alerta anula el general de tu cuenta. Así, tus alertas de ventas pueden seguir yendo al canal de ventas mientras que las alertas de feedback van a algo como #product-feedback. Los gerentes de producto e ingenieros que solo necesiten leer pueden unirse a tu equipo de KWatch con el rol Reader, que recibe notificaciones pero no puede crear ni eliminar alertas.

Si quieres contabilizar las solicitudes a lo largo del tiempo, envía las mismas alertas a un webhook de API. Cada coincidencia llega como una carga útil JSON. Aquí tienes el ejemplo de nuestra documentación:

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

Apunta eso a un webhook de Zapier o n8n y añade una fila a una hoja de cálculo, con una columna por campo. El campo query te indica qué alerta se activó, de modo que una alerta de solicitud y una de error se ordenan solas. El campo sentiment (positivo, negativo o neutro) te permite extraer rápidamente las publicaciones de usuarios descontentos en primer lugar. Hemos documentado la configuración de Zapier y n8n paso a paso si no has conectado uno antes.

Las alertas por correo electrónico también funcionan, pero las publicaciones largas se truncan en el correo. Las solicitudes de funciones tienden a ser extensas, por lo que Slack o un webhook son una mejor opción en este caso.

Qué hacer con lo que encuentres

Una vez que el feedback empiece a llegar, la tentación es responder a todo. Yo me contendría un poco. Una respuesta breve y útil de alguien que claramente trabaja en el producto («está en nuestra lista, aquí tienes una solución provisional por ahora») ayuda muchísimo. Una serie de respuestas que terminan todas con un enlace de registro te generará votos negativos y, en algunos subreddits, la expulsión.

El hábito más valioso es la revisión semanal. Una vez a la semana, alguien del equipo de producto revisa el canal o la hoja de cálculo y etiqueta cada elemento: solicitud, error, motivo de cancelación o irrelevante. Después de un mes, tendrás un recuento aproximado de lo que la gente pide en público, junto a lo que piden en los tickets. Cuando las dos listas no coinciden, ahí suele estar lo más interesante.

Si parte del feedback más útil proviene de un puñado de personas conocidas (usuarios avanzados, analistas, el fundador de un competidor) en lugar de palabras clave, nuestro producto hermano MultiFollow sigue cuentas específicas de Linkedin y X y te avisa cuando publican, lo que complementa muy bien las alertas por palabras clave.