Comece pela objeção, porque ela é a certa. Canny e Productboard hoje leem as mesmas fontes. O Autopilot do Canny puxa feedback de Zendesk, Intercom, Slack, Gong, Help Scout, Freshdesk, Zoom e tl;dv, além de reviews públicos no G2, Capterra, Trustpilot, App Store e Google Play. O Productboard também ingere Zendesk, Intercom, Slack, Gong, G2, App Store e Google Play. Os dois agrupam o que encontram com AI e os dois deduplicam. Comprar os dois parece comprar duas vezes o mesmo motor de ingestão.
A parte que não se sobrepõe é a razão de este stack existir. O Canny opera um board onde seus clientes fazem login, publicam e votam, e um changelog que avisa cada votante quando aquilo que ele pediu foi lançado. O Portal do Productboard publica um roadmap: é uma superfície de difusão, não uma comunidade de votação. O Productboard, em troca, concentra o aparato de priorização — pontuação contra objetivos, definição de features e o repasse para engenharia. Uma ferramenta é onde os clientes discutem o que importa. A outra é onde seu time de produto decide. Se você só precisa de uma dessas coisas, compre uma só, e esta página não é para você.
O que cada ferramenta faz aqui
Zendesk é a fonte de volume, não o sistema de feedback. A maioria dos pedidos de feature chega como o segundo parágrafo de um ticket de suporte sobre outra coisa, e morre ali. O trabalho do Zendesk neste stack é continuar existindo: o agente resolve o ticket e não muda o workflow dele em nada.
Canny é a camada voltada ao cliente e o ponto de deduplicação. O Autopilot lê a conversa do Zendesk, extrai o pedido, funde com um post existente se houver e arquiva numa área de produto. O board público é onde o pedido fica visível e contável, e o changelog é como o ciclo se fecha.
Productboard é a camada interna de ranking. Ele ingere a própria cópia das conversas de suporte e vendas, anexa a features, pontua essas features contra objetivos e empurra o trabalho comprometido para Jira, Azure DevOps, GitHub, Trello ou Shortcut. O Spark é a camada de AI sobre tudo isso e está incluído em todos os planos, inclusive o gratuito.
Slack é onde o ciclo fica visível para pessoas que não vão abrir nenhuma das duas ferramentas. O Canny publica notificações de novos posts, comentários, marcos de votos e mudanças de status; além disso, tanto Canny quanto Productboard tratam o Slack como fonte de captura, então um pedido digitado no #customer-feedback não evapora.
Os repasses
- Entra um ticket no Zendesk com um pedido de feature → o Autopilot do Canny captura, deduplica contra posts existentes e arquiva numa área de produto.
- O pedido aparece no board do Canny → outros clientes votam; marcos de votos e mudanças de status vão para o Slack.
- Um post atinge o limite que você definiu → é empurrado para Jira ou Linear com sincronização de status nos dois sentidos.
- O Productboard ingere diretamente as mesmas conversas de Zendesk e Gong, anexa a features e prioriza contra objetivos.
- O trabalho é lançado → o status do Jira ou Linear sincroniza de volta para o post do Canny → o changelog do Canny notifica cada cliente que votou.
O passo 4 é onde este stack tem um buraco, e fingir o contrário deixaria o resto da página inútil. Canny e Productboard não têm integração nativa em nenhuma direção. O diretório de integrações do Canny não lista o Productboard, e o do Productboard não lista o Canny. Verificado em 16 de agosto de 2026.
A proteção é parar de tentar conectar os dois diretamente e transformar o issue tracker na espinha dorsal compartilhada. As duas ferramentas sincronizam nativamente com o Jira, e as duas anexam ao mesmo issue, então uma chave do Jira vira a junção entre o post público e a feature interna. As alternativas são piores: uma ponte em Zapier ou Make que agora é você quem mantém, ou a API do Canny contra a do Productboard, que é uma integraçãozinha interna sem dono no terceiro mês.
Linha de base de custo
Verificado em 16 de agosto de 2026. Pegue um time com 8 agentes de suporte e 4 pessoas que precisam escrever na ferramenta de roadmap.
Uma configuração enxuta: Zendesk Suite Team a $55/agente/mês anual ($440), Canny Pro a $79/mês faturado anualmente e Productboard Plus a $19/maker/mês anual ($76). Dá $595/mês, cerca de $7.140/ano.
Uma mais completa: Zendesk Suite Professional a $115/agente/mês ($920), Canny Pro a $79, Productboard Business a $59/maker/mês anual com mínimo de 2 makers ($236). Dá $1.235/mês, cerca de $14.820/ano. O add-on Copilot do Zendesk custa mais $50/agente/mês no Professional e acima, e o Zendesk cobra seus agentes de AI por resolução automatizada em vez de por assento.
A camada de feedback é mais ou menos um quarto da conta nas duas configurações. A quantidade de assentos de suporte define o resto, o que vale saber antes de a negociação ir para o fornecedor errado.
Dois detalhes de medição decidem se esses números se sustentam. O Canny não cobra por assentos de time: o Free cobre 25 tracked users e 5 managers, o Pro cobre 100 ou mais tracked users e 10 managers, e o Business começa em 5.000. O que sobe de tier é o crescimento no número de usuários finais que você rastreia, não o crescimento do seu time. O Productboard mede créditos de AI por maker por mês: 50 no Free, 250 no Plus, 500 no Business, 800 mais 1.500 créditos base no Enterprise. Confira o consumo de créditos durante um teste antes de dimensionar a quantidade de makers, porque o Spark está em todos os planos e os créditos são o que de fato o racionam.
Variações
Corte o Canny quando o board não é público. Se os clientes nunca veem nem votam em pedidos, a metade não sobreposta do Canny some e o Portal do Productboard cobre a publicação do roadmap. Isso economiza cerca de $948/ano e elimina a costura do conector. A regra: se você não consegue nomear os clientes que vão fazer login e votar, está comprando um motor de deduplicação que já tem.
Corte o Productboard quando o time é pequeno. Abaixo de umas dez pessoas, a priorização cabe no Jira ou Linear com um campo de pontuação, e Canny mais o issue tracker é o ciclo inteiro.
Troque Zendesk por Intercom ou Pylon. Tanto Canny quanto Productboard ingerem Intercom nativamente, então os repasses sobrevivem intactos à substituição.
O que este stack não substitui
Ele não diz o que os clientes fizeram, só o que pediram. Comportamento pertence ao product adoption stack. Ele não deflete tickets: isso é o AI support agent stack. Não é uma prática de discovery: contagem de votos mede o entusiasmo dos clientes que se dão ao trabalho de votar, o que correlaciona com o quão barulhento um segmento é mais do que com quanta receita ele concentra. E não é um sistema de health nem de renovação de CS.
Dois pontos de atenção com suas proteções. As duas ferramentas ingerindo Zendesk de forma independente produzem dois agrupamentos diferentes dos mesmos tickets, e na primeira vez que PM e CS levarem contagens diferentes do mesmo pedido para a mesma reunião, a confiança nos dois números acabou; a proteção é dar a cada fonte um único sistema de registro, deixando o Canny dono de tudo que é visível ao cliente e apontando o Productboard para calls de vendas e notas internas. O Productboard está no meio de um pivô — Hubert Palan anunciou em 15 de abril de 2026 que a empresa passaria a ser AI-only e se separaria de mais de 30% do time, se reconstruindo em torno do Spark; a proteção é manter os verbatims crus no Canny e no Zendesk, onde você consegue exportá-los, e tratar o Productboard como uma camada de ranking sobre um corpus que ele não possui sozinho.
Quando este é o stack certo
Escolha quando você tem clientes suficientes para um board público receber votos reais, volume de suporte alto o bastante para pedidos ficarem enterrados em tickets, um PM e um líder de CS que hoje discordam sobre prioridades sem uma lista rankeada compartilhada, e alguém que de fato vá manter o changelog.
Pule quando seu número de clientes é pequeno o suficiente para simplesmente ligar para eles — um board de votação espalhado por 30 contas enterprise produz ruído e um mandato falso — ou quando ninguém é dono do ciclo. Um board público mostrando um pedido como “em análise” por dois anos é pior do que nunca ter aberto um, porque é um registro durável, indexado e visível ao cliente que você não responde.