Estou usando o WPFeatureLoop nos meus próprios plugins há pouco mais de um mês. Nesse período, coletei mais de 150 votos em 11 feature requests, e isso já mudou o que vou construir a seguir.
Aqui vai como os dados realmente são, e o que eles me ensinaram sobre meus próprios pontos cegos como desenvolvedor.
Os Números Brutos
Dois plugins, duas bases de usuários diferentes, um mês de dados:
| Feature request | Votos | Comentários |
|---|---|---|
| Feature A | 41 up · 9 down | — |
| Feature B | 51 up · 29 down | — |
| Feature C | 4 up | — |
| Feature D | 14 up · 4 down | 2 comentários |
| Feature E | 8 up · 1 down | — |
| Feature F | 7 up · 1 down | — |
| Feature G | 5 up · 1 down | — |
| Feature H | 6 up | — |
| Feature I | 5 up | — |
| Feature J | 4 up · 1 down | — |
| Feature K | 1 up | — |
Nada revolucionário à primeira vista. Mas a parte interessante não é a tabela, é o que ela me disse que eu estava errado.
Eu ia pular a feature mais pedida
Um desses plugins é um sistema de delivery pra WordPress. Quando o cliente faz um pedido, o fluxo termina com uma mensagem de WhatsApp pro dono da loja. Simples, efetivo.
Eu estava considerando adicionar uma tela de confirmação de pedido, daquelas que você vê em qualquer checkout de e-commerce: “Seu pedido foi realizado, aqui está o número, aqui está o que você pediu.”
Quase não construí. Minha premissa era que adicionaria fricção no fluxo de checkout. O usuário já recebe a confirmação pelo WhatsApp. Pra que mais uma etapa?
Aí vieram os votos. Mais de 20 upvotes pra tela de confirmação de pedido. Era uma das features mais pedidas, bem mais do que coisas que eu achava que tinham prioridade maior, como regras avançadas de cupom.
O sinal foi claro. Meus usuários não viam como fricção. Viam como confiança. Uma tela de confirmação diz pro cliente “seu pedido foi feito”. Sem ela, alguns clientes não tinham certeza se a mensagem de WhatsApp realmente foi enviada.
Movi pro topo do roadmap. Já está construída e sendo entregue.
O ponto não é que eu estava errado. O ponto é que sem os dados, eu teria pulado com confiança uma feature que meus usuários ativamente queriam. Esse é o tipo mais perigoso de erro de produto: o que você nem sabe que está cometendo.
Um feature request que virou sinal de negócio
O segundo plugin é uma extensão pra WooCommerce. Um feature request se destacou imediatamente: integração com a API oficial do WhatsApp Business.
Mais de 50 upvotes. E não foram só votos, usuários se inscreveram pra ser notificados quando a feature estivesse pronta.
Isso não é só “as pessoas querem isso”. Isso é validação de demanda. Quando usuários ativamente se inscrevem numa feature que ainda não podem usar, estão dizendo: “vou prestar atenção quando isso lançar. Talvez eu pague por isso.”
Isso muda a conversa. Não é mais uma questão de se construir. É uma questão de como monetizar e quando lançar.
Sem os dados de votação, isso seria mais um item no backlog. Com eles, virou uma prioridade estratégica com um sinal claro de disposição pra engajar.
Por que isso importa pra devs de plugin
Se você constrói plugins WordPress, provavelmente está tomando decisões de roadmap baseado numa combinação de tickets de suporte, intuição e o que os concorrentes estão fazendo.
Tickets de suporte são enviesados pra problemas, não oportunidades. Intuição é pouco confiável em escala. Análise de concorrentes diz o que outros estão construindo, não o que seus usuários querem.
Votação de features preenche um gap específico: diz o que seus usuários valorizam antes de você construir.
O que eu aprendi em um mês:
Downvotes são dados também. A Feature B teve 51 upvotes mas também 29 downvotes. Isso não é consenso, é uma feature polarizante. Construir significa agradar parte dos usuários e frustrar outros. Esse contexto importa pra priorização e pra como você entrega (talvez como configuração opcional, não padrão).
Volume não é tudo. A Feature K teve 1 upvote. Não significa que não tem valor, significa que é nicho. Se aquele usuário é high-value ou representa um segmento que você quer crescer, ainda pode valer construir. Mas você sabe que não deve priorizar sobre um request com 40 votos.
Silêncio é um sinal. As features em que ninguém vota são igualmente informativas. Se você estava planejando construir algo e tem zero engajamento da sua base, isso é informação útil antes de gastar três semanas nisso.
O valor real está nas premissas que você pega
A história da tela de confirmação é a que fica voltando na minha cabeça. Eu tinha uma opinião forte. Parecia a decisão certa. E sem dado nenhum, teria entregue um roadmap que pulava uma das features mais desejadas.
É isso que votação de features realmente faz. Não substitui seu julgamento, desafia suas premissas antes que elas virem decisões caras.
Um mês. Dois plugins. Mais de 150 votos. Duas mudanças de roadmap que eu não teria feito de outra forma.
Esse é o caso pra colocar um loop de feedback dentro do seu plugin, não numa página separada que seus usuários nunca vão visitar.
WPFeatureLoop é uma plataforma de votação de features pra devs de plugins WordPress. Adicione um widget de votação direto no admin do seu plugin — sem páginas externas, sem fricção. Experimente grátis.
Deixe um comentário