Como recolher feedback sobre o produto e pedidos de funcionalidades no Reddit, X e Hacker News

Porque é que os canais habituais de feedback não o detetam

A maioria das equipas recolhe feedback a partir de três locais: tickets de suporte, um widget na aplicação e chamadas comerciais. Todos os três têm o mesmo enviesamento: apenas ouvem quem já está a falar consigo.

Os tópicos públicos são diferentes. Alguém que cancelou a subscrição no mês passado não preencherá o seu inquérito, mas explicará de bom grado no Reddit porque foi embora. Um potencial cliente que esteja a comparar ferramentas listará o que falta à sua numa publicação do género «qual devo escolher?». Trata-se de um feedback que nunca obteria de outra forma, e muitas vezes vem acompanhado de respostas de outros utilizadores a concordar ou discordar, o que lhe mostra quão comum é o problema.

O problema reside no volume. Se pesquisar pelo nome do seu produto uma vez por semana, encontrará uma mão-cheia de tópicos, habitualmente tarde demais para responder. Se configurar um alerta simples com o seu nome, receberá todas as menções, incluindo aquelas que não têm nada a ver com o produto. O segredo consiste em criar alertas que procurem feedback especificamente.

Criar alertas focados em feedback

Um alerta do KWatch faz a correspondência com todas as palavras-chave da sua lista, pelo que as vírgulas funcionam como AND. É isso que faz os alertas de feedback funcionar. Em vez de um único alerta com o nome do seu produto, junta o nome às palavras que as pessoas usam quando querem que algo seja alterado.

Eis um conjunto inicial, com «acme» a representar o nome do seu produto:

1. acme, wish e acme, would be nice para pedidos de funcionalidades
2. acme, bug e acme, broken para relatórios de erros
3. acme, switched e acme, cancelled para motivos de cancelamento
4. acme, missing e acme, doesn't support para lacunas com que os utilizadores se deparam durante a avaliação

Cada linha é um alerta separado, pois um alerta com todas essas palavras exigiria que todas elas constassem da mesma publicação. Provavelmente irá ajustar a formulação ao fim de uma semana, assim que perceber como comunicam os seus próprios utilizadores. As pessoas raramente escrevem as palavras «feature request», por isso procure as expressões que realmente usam, como «seria ótimo se».

Alguns filtros tratam da maior parte da limpeza. No Reddit e no Hacker News, ative Apenas palavras inteiras se o nome do seu produto for curto ou comum, para que «acme» não corresponda a «acmeplex». Adicione as contas da sua própria equipa como Utilizadores excluídos, para que as suas respostas e publicações de lançamento não acionem alertas. Se tiver um subreddit do seu produto, pode criar um alerta separado restrito ao mesmo com Subreddits incluídos e dispensar totalmente a segunda palavra-chave, dado que quase tudo o que ali é publicado já é feedback de qualquer forma.

As palavras-chave excluídas funcionam de forma inversa às incluídas. As palavras-chave incluídas têm de corresponder todas, mas uma publicação é descartada assim que qualquer uma das palavras-chave excluídas aparece. Mantenha essa lista curta e específica, caso contrário filtrará feedback real juntamente com o ruído. O nosso artigo sobre reduzir o ruído nos alertas de palavras-chave analisa cada filtro com maior detalhe.

Onde começar a escutar

Nem todas as plataformas oferecem o mesmo tipo de feedback. Noto que é no Reddit e no Hacker News que as pessoas escrevem as reclamações mais longas e específicas. O X é mais curto e assertivo, o que é útil para detetar rapidamente uma versão com problemas. O Linkedin é sobretudo elogios e anúncios, pelo que fica mais abaixo nesta lista, a não ser que venda a profissionais que publiquem ali sobre as suas ferramentas de trabalho.

A velocidade também varia consoante a plataforma, e isso muda a forma como utilizará cada alerta. Estas são as frequências de atualização da nossa documentação:

Para feedback, nenhuma destas opções é lenta. O que a tabela lhe mostra é que um tópico do Hacker News pode chegar até si enquanto ainda está na página principal, que é precisamente o momento em que a resposta de alguém da equipa tem mais peso.

Fazer chegar o feedback à equipa de produto

Um alerta que ninguém lê não passa de uma pesquisa mais agradável. A parte que as equipas costumam ignorar é decidir onde o feedback vai parar e quem o consulta.

A configuração mais simples é um canal dedicado no Slack. O KWatch permite-lhe configurar um webhook do Slack por alerta, e um webhook individual por alerta tem prioridade sobre o configurado a nível de conta. Assim, os seus alertas de vendas podem continuar a ir para o canal de vendas enquanto os alertas de feedback vão para algo como #product-feedback. Os gestores de produto e engenheiros que apenas precisem de ler podem juntar-se à sua equipa no KWatch com a função Reader, que recebe notificações mas não pode criar nem eliminar alertas.

Se quiser contabilizar os pedidos ao longo do tempo, envie esses mesmos alertas para um webhook de API. Cada correspondência chega como um payload JSON. Eis o exemplo da nossa documentação:

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

Aponte isso para um webhook do Zapier ou do n8n e adicione uma linha a uma folha de cálculo, com uma coluna por campo. O campo query indica que alerta foi acionado, pelo que um alerta de pedido e um alerta de erro se organizam sozinhos. O campo sentiment (positivo, negativo ou neutro) oferece-lhe uma forma rápida de isolar primeiro as publicações mais críticas. Descrevemos a configuração do Zapier e do n8n passo a passo, caso nunca tenha feito esta integração antes.

Os alertas por e-mail também funcionam, mas as publicações longas ficam truncadas no e-mail. Os pedidos de funcionalidades tendem a ser longos, pelo que o Slack ou um webhook são uma opção bem melhor aqui.

O que fazer com o que encontrar

Assim que o feedback começar a entrar, a tentação é responder a tudo. Eu conteria um pouco o impulso. Uma resposta breve e útil de alguém que claramente trabalha no produto («está na nossa lista, eis uma solução temporária por agora») faz toda a diferença. Uma sucessão de respostas que terminam todas num link de registo atrai votos negativos e, em alguns subreddits, a expulsão.

O hábito mais valioso é a leitura semanal. Uma vez por semana, alguém da equipa de produto revê o canal ou a folha de cálculo e etiqueta cada item: pedido, erro, motivo de cancelamento ou irrelevante. Ao fim de um mês, terá uma contagem aproximada daquilo que as pessoas pedem em público, lado a lado com o que pedem nos tickets. Quando as duas listas divergem, é aí que reside a parte mais interessante.

Se algum do seu feedback mais útil provier de um conjunto restrito de pessoas conhecidas (utilizadores avançados, analistas, o fundador de um concorrente) em vez de palavras-chave, o nosso produto irmão MultiFollow segue contas específicas de Linkedin e X e avisa-o quando estas publicam, o que complementa perfeitamente os alertas de palavras-chave.