Existe uma planilha. Ela tem 400 linhas, três das quais foram lidas neste trimestre, e as colunas se chamam "cliente", "pedido" e "observações". Em algum lugar dela está o único problema que, bem resolvido, mudaria a renovação de um segmento inteiro, e ninguém nunca vai encontrá-lo, porque a fila foi desenhada para guardar pedidos, não para respondê-los.
Gerenciar solicitações de funcionalidades (as famosas feature requests) direito não é coletar mais delas. São três disciplinas pouco glamorosas: traduzir cada pedido de uma solução proposta de volta para o problema por trás dela, saber o quanto cada canal de entrada é enviesado e voltar à pessoa que pediu, tanto quando você decide quanto quando você entrega.
Este guia cobre o pipeline completo, os vieses de canal que ninguém leva em conta, o que fazer com a enorme pilha de pedidos que você nunca vai construir e por que fechar o ciclo é a etapa que define se alguém vai se dar ao trabalho de contar alguma coisa para você no próximo trimestre.
Principais aprendizados
- Um pedido é uma solução proposta, não uma necessidade. O trabalho é recuperar o problema por baixo dele antes que chegue a um roadmap.
- Todo canal é enviesado. Pedidos de vendas pendem para negócios em aberto, os de suporte para o que está quebrado, os quadros públicos para quem está acompanhando o quadro.
- Contagem de votos não é prioridade. Ela mede o engajamento com o seu sistema de feedback, não o tamanho do problema.
- Um responsável, uma fila, uma cadência. Triagem que é de todo mundo acaba sendo de ninguém.
- Diga não rápido e de forma específica. O silêncio prejudica o relacionamento muito mais do que uma recusa clara.
- Fechar o ciclo quando você entrega é a etapa de maior retorno. Ela converte um pedido em adoção e mantém o pipeline cheio.
Uma solicitação de funcionalidade é uma solução proposta
Solicitação de funcionalidade, em um parágrafo
Uma solicitação de funcionalidade é um cliente ou colega pedindo que uma capacidade específica seja adicionada ou alterada. O que as torna difíceis de gerenciar não é o volume, mas o formato: as pessoas relatam a correção que imaginaram, não o problema que enfrentaram. O pedido é uma codificação comprimida e com perdas de uma necessidade, e a compressão descarta justamente a informação de que você precisa para decidir bem. Recuperar a necessidade é a primeira e mais valiosa etapa de todo o processo.
O exemplo clássico é o pedido de exportação. Seis clientes pedem exportação em CSV, e existe uma versão dessa história em que o time constrói a exportação em CSV, entrega e descobre que o uso é quase zero, porque quando finalmente alguém pergunta, os seis queriam outra coisa.
Cada coluna da direita sugere soluções que a da esquerda não sugere: um resumo agendado, uma correção no campo que continua gerando o erro, um tema que se adapta à luminosidade. É o mesmo movimento por trás dos jobs to be done: pergunte o que a pessoa estava tentando realizar e o que ela fez no lugar quando não funcionou.
A pergunta que faz a maior parte do trabalho. "O que você estava fazendo quando precisou disso, e o que fez no lugar?" Leva uma frase para perguntar, transforma um pedido em uma história com contexto e muitas vezes revela que dois pedidos registrados com nomes diferentes são o mesmo problema.
De onde vêm os pedidos, e como cada canal engana
Os pedidos não chegam como uma amostra representativa. Cada canal super-representa um tipo de usuário e um tipo de problema, e tratar essa mistura como dados sobre a sua base de usuários é o erro estrutural mais comum na gestão de solicitações de funcionalidades.
| Canal | O que ele super-representa | Para que ele realmente serve | Viés |
|---|---|---|---|
| Tickets de suporte | O que está quebrado ou confuso agora | Atritos que estão gerando tickets hoje | Médio |
| Calls de vendas | Requisitos atrelados a um negócio que ainda não fechou | Lacunas que impedem um segmento inteiro de comprar | Alto |
| Reuniões de customer success | As contas maiores e mais barulhentas | Risco de renovação com nome e sobrenome | Alto |
| Quadro público de votação | Usuários que acompanham o seu roadmap por esporte | Transparência e detecção de duplicados | Alto |
| Prompts in-app | A tela em que você colocou o prompt | Contexto: você sabe exatamente o que a pessoa estava fazendo | Menor |
| Pesquisas de churn e de saída | Os motivos que as pessoas dão ao sair | O que faltou a ponto de perder a conta | Médio |
O canal com menor viés é o in-app, por um motivo estrutural: ele pega o usuário no momento do problema, na tela em que aconteceu, sem exigir que ele se importe o bastante para abrir um quadro ou mandar e-mail para o suporte. Nossos guias de pesquisas in-app e de pesquisas de saída cobrem a mecânica; o ponto aqui é que um pedido capturado em contexto chega com metade do trabalho de esclarecimento já feito.
O problema da maioria silenciosa. Os usuários mais propensos a registrar um pedido são os mais investidos no seu produto, os seus power users. Também são aqueles cujos problemas já são os menores, porque eles aprenderam os atalhos e contornos. Um backlog construído só a partir de pedidos recebidos é, portanto, uma máquina de atender demais quem menos precisa de você, que é um dos mecanismos por trás do feature bloat.
O pipeline em quatro etapas
Um sistema que funciona tem quatro etapas e um responsável. O responsável não decide tudo; ele responde por fazer a fila andar, que é um trabalho diferente e mais raro.
Todo canal cai em uma única fila, com os mesmos campos. Nada de planilhas paralelas.
Transforme o pedido em uma declaração de problema, mescle duplicados, anexe quem e quantos.
Agora, depois ou não, em uma cadência fixa, com o motivo registrado por escrito.
Diga a quem pediu o que você decidiu. Diga de novo quando for entregue.
Quatro etapas, uma fila, um responsável. A maioria dos processos quebrados não tem as etapas dois e quatro.
1. Capturar: uma fila, campos consistentes
Não importa muito qual ferramenta guarda a fila. Importa enormemente que exista uma só e que cada entrada tenha o mesmo punhado de campos: o pedido nas palavras de quem pediu, quem pediu, o segmento ou plano, a tela ou o fluxo a que se refere, a data e o canal por onde chegou. Esse último campo é o que depois permite perceber que um "pedido campeão" é, na verdade, oito pessoas em um quadro público e um único cliente pagante.
2. Esclarecer: reescreva como um problema
Toda semana, em um horário fixo, pegue as novas entradas e reescreva cada uma em uma frase no formato "[quem] não consegue [fazer o quê] porque [por quê], então hoje [contorno]." Quando o pedido for vago demais para reescrever, vá perguntar; quem pediu quase sempre responde, porque alguém de fato leu o que escreveu. Depois, mescle: pedidos que compartilham uma declaração de problema são um único item, por mais diferente que tenham sido formulados. É aqui que uma fila de 400 linhas costuma virar 60 problemas reais, e também é o momento natural para fazer uma análise estruturada de feedback sobre o texto que você coletou.
3. Decidir: agora, depois ou não
Apenas três resultados. "Em análise" não é um estado, é uma forma de evitar um, e uma fila cheia deles é o que os clientes acabam lendo como indiferença. Pese quatro coisas: quantos usuários são afetados e com que gravidade, o quanto o problema combina com a direção do produto, o custo real, incluindo manutenção e a coisa a mais que todo futuro usuário vai ter que aprender, e o que acontece se você não fizer nada. O modelo Kano é útil justamente aqui, porque separa pedidos que são expectativas básicas não atendidas, cuja ausência causa insatisfação real, de "encantadores" que soam empolgantes e não mudam nada.
4. Feche o ciclo, duas vezes
Uma vez no momento da decisão, para que a pessoa saiba que foi ouvida e o que acontece em seguida. Outra vez no momento da entrega, para que quem pediu há seis meses descubra que a coisa existe. O segundo contato é o que quase todo mundo pula e o que tem mais valor; veja a próxima seção.
Fechar o ciclo é o objetivo de tudo
Um sistema de solicitações de funcionalidades tem um ciclo de feedback próprio: as pessoas registram pedidos na medida em que acreditam que isso adianta alguma coisa. Times que nunca respondem veem os envios secarem e concluem que os clientes não têm feedback, enquanto esses mesmos clientes descrevem a mesma capacidade que falta em uma pesquisa de churn oito meses depois.
A frase menos usada no SaaS é "você pediu isso no trimestre passado; já está no ar, está aqui". Não custa nada, chega a alguém que já disse que quer aquilo e converte um pedido em uso de verdade, em vez de uma linha em um changelog que ninguém leu.
o argumento a favor de anúncios segmentadosA versão prática tem duas partes. Primeiro, publique o que foi entregue, do jeito certo; nosso guia sobre como escrever release notes cobre o formato. Segundo, e separadamente, avise as pessoas específicas que pediram, dentro do produto, na tela onde a nova capacidade está. Um anúncio geral alcança todo mundo de forma fraca; um anúncio segmentado alcança quem pediu no momento em que essa pessoa pode agir, e essa é a diferença entre conhecimento e adoção. Nosso guia de anúncio de novas funcionalidades cobre a sequência.
Pedidos capturados in-app chegam com o contexto anexado, e o mesmo canal pode ser usado depois para fechar o ciclo.
A pilha do "não" é a maior parte da fila
Todo produto saudável recusa a grande maioria do que lhe pedem, e fazer isso bem é uma habilidade. Três padrões se sustentam:
- Recuse rápido. Um não em uma semana é respeitado. Um não depois de seis meses de silêncio soa como desprezo, e a essa altura o cliente geralmente já criou um contorno e perdeu o interesse em contar qualquer outra coisa para você.
- Dê o motivo, não a política. "Isso está fora do que vamos construir este ano, porque estamos focados em X" é um motivo. "Não está no roadmap" é um muro. O primeiro mantém a conversa aberta; o segundo a encerra.
- Ofereça a resposta de hoje. A maioria dos pedidos recusados já tem um contorno parcial no produto. Enviá-lo, de preferência como link para o artigo de ajuda certo ou um guia in-app na tela certa, transforma um não em uma pequena vitória.
Uma nuance que vale guardar: um pedido recusado continua sendo dado. Dez pedidos recusados que compartilham uma declaração de problema são um sinal de lacuna, mesmo que nenhuma das dez soluções propostas estivesse certa. Mantenha as declarações de problema pesquisáveis, porque o grupo que parece ruído neste trimestre muitas vezes é o item de roadmap do ano que vem.
Uma observação sobre quadros públicos de votação
Quadros públicos são realmente úteis para duas coisas: mostrar aos clientes que a fila existe e permitir que as pessoas descubram que o pedido delas já foi registrado. Eles são fracos naquilo para que normalmente são adotados, que é a priorização. Os votos medem quem está olhando o quadro: usuários individuais engajados votam, compradores enterprise praticamente nunca votam, e um pedido de um segmento que representa a maior parte da sua receita pode ficar abaixo de um pedido de seis entusiastas.
Se você mantém um, trate os votos como mecanismo de detecção de duplicados, não como ranking, faça a curadoria sem dó para que ele não vire um arquivo de pedidos sem resposta e mantenha os critérios reais de priorização (segmento, receita, gravidade, encaixe estratégico) na fila interna, onde é o lugar deles.
Seis formas como os processos de solicitações de funcionalidades falham
- Guardar sem triar. Uma fila que ninguém cuida não é um backlog, é um aterro, e o esforço gasto para alimentá-la é desperdiçado desde o primeiro dia.
- Ranquear pela contagem bruta. Frequência é um critério. Usada sozinha, ela entrega o seu roadmap a quem se sente mais à vontade abrindo tickets.
- Construir o pedido ao pé da letra. Entregar a solução proposta sem recuperar o problema produz funcionalidades usadas uma vez e mantidas para sempre.
- Deixar o negócio mais barulhento definir o roadmap. A lista de requisitos de um único prospect grande é, na melhor das hipóteses, um sinal de segmento e, na pior, uma distração. Pergunte quantos clientes atuais têm o mesmo problema antes de se comprometer.
- Nenhuma resposta no momento da decisão. A forma mais rápida de parar de receber feedback, e ela é invisível até a fila secar em silêncio.
- Entregar em silêncio. Construir a coisa certa e nunca contar para quem pediu é o erro mais caro desta lista, porque você pagou o custo inteiro e não recebeu nenhum crédito.
Solicitações de funcionalidades: faça vs. não faça
✅ Faça
- Canalize todos os canais para uma única fila com campos consistentes
- Reescreva cada pedido como uma declaração de problema antes de decidir
- Registre por qual canal cada pedido chegou
- Faça a triagem em uma cadência semanal fixa, com um responsável nomeado
- Recuse de forma explícita, com um motivo e qualquer contorno existente
- Avise in-app quem fez o pedido original quando for entregue
❌ Não faça
- Ranquear pela contagem de votos
- Usar "em análise" como estado permanente
- Construir a solução proposta sem perguntar para que ela servia
- Deixar um único negócio reescrever o trimestre
- Manter listas de pedidos paralelas em três ferramentas
- Supor que uma fila silenciosa significa clientes satisfeitos
Coletar e fechar o ciclo dentro do produto
Tudo o que foi dito acima fica mais fácil quando as duas pontas do ciclo vivem onde o usuário já está. A captura é melhor in-app porque o contexto vem de graça: você sabe a tela, o segmento e o que a pessoa tinha acabado de fazer. Fechar o ciclo é melhor in-app porque o anúncio aparece na tela em que a nova capacidade realmente existe, e não em uma caixa de entrada dois dias depois.
É um trabalho simples e no-code: uma micropesquisa na tela em que um fluxo vive travando e um anúncio segmentado para o grupo que pediu, publicado sem esperar um release. Combine isso com um walkthrough curto da nova capacidade e um pedido vira adoção no mesmo dia em que vira uma funcionalidade entregue.
Pergunte onde o problema acontece. Responda onde a solução está.
Com o Kompassify, você roda pesquisas in-app para capturar pedidos em contexto e depois anuncia o que construiu exatamente para os usuários que pediram, com tooltips, walkthroughs e anúncios publicados sobre o seu produto atual, sem precisar de tempo de engenharia. Grátis até 100 usuários ativos mensais, planos a partir de US$ 129/mês, em conformidade com o GDPR e hospedado na UE.
Comece grátis →A versão em um parágrafo
Trate cada solicitação de funcionalidade como uma solução proposta que precisa ser traduzida de volta para um problema, lembre que cada canal de entrada super-representa um tipo diferente de usuário, mantenha uma fila com um responsável e uma triagem semanal, decida em três estados em vez de estacionar as coisas para sempre e volte a quem pediu, uma vez quando decidir e outra quando entregar. A última etapa é a que mantém a fila viva.
Perguntas frequentes
O que é uma solicitação de funcionalidade?
Uma solicitação de funcionalidade (feature request) é um cliente ou colega pedindo que uma capacidade específica seja adicionada ou alterada. O importante nessa definição é o que ela deixa de fora: um pedido é uma solução proposta, não uma declaração de necessidade. Quem pede uma exportação em CSV pode precisar de um relatório agendado, de uma integração ou simplesmente de um jeito de mostrar um número para a gestora. Gerenciar bem as solicitações de funcionalidades é, sobretudo, a disciplina de recuperar o problema de fundo antes que a solução proposta vá parar em um roadmap.
Como coletar solicitações de funcionalidades?
Colete onde o usuário já está e canalize todos os canais para um único lugar. Prompts in-app pegam o pedido no momento da frustração, com todo o contexto do que a pessoa estava fazendo; conversas de suporte capturam o problema nas palavras do próprio usuário; calls de vendas e de customer success trazem pedidos ligados a receita. O que importa não é adicionar mais canais, e sim garantir que todos caiam em uma única fila com os mesmos campos, porque pedidos espalhados entre um helpdesk, uma planilha e três canais do Slack não podem ser contados, comparados nem respondidos.
Como priorizar solicitações de funcionalidades?
Não pela contagem de votos. Pese quantos usuários são afetados e com que gravidade, o quanto o pedido combina com a direção do seu produto, quanto custa construir e manter e o que significaria não fazer nada. Frequência é um critério entre vários, e uma contagem bruta pende fortemente para os usuários mais barulhentos e engajados, as pessoas que já têm sucesso com o produto. Frameworks como o modelo Kano ajudam ao classificar se um pedido é uma expectativa básica, uma melhoria de desempenho ou um encantador, o que muda o valor de construí-lo.
Vale a pena ter um quadro público de solicitações de funcionalidades?
Só se você for mantê-lo. Um quadro público com votação visível é excelente para transparência e péssimo como critério de priorização: os votos medem quem está olhando o seu quadro, não quem tem o problema, e clientes enterprise quase nunca votam. Ele também cria uma obrigação: um quadro cheio de pedidos de dois anos atrás marcados como "em análise" é um registro público de que você não escuta. Se você não pode se comprometer a responder e a fazer a curadoria, uma fila interna com acompanhamento proativo atende melhor os clientes.
Como dizer não a uma solicitação de funcionalidade?
Rápido, de forma específica e com o motivo. A maioria dos clientes aceita um não muito melhor do que o silêncio, e o que prejudica o relacionamento é um pedido que some por seis meses antes de morrer discretamente. Diga qual problema você entendeu, o que decidiu e por quê (fora da estratégia, já atendido por uma capacidade existente, específico demais para a base de usuários) e ofereça qualquer contorno que exista hoje. Um não claro também faz as pessoas continuarem enviando pedidos, que é o resultado que você realmente quer.
O que significa fechar o ciclo das solicitações de funcionalidades?
Fechar o ciclo significa voltar a quem pediu duas vezes: uma quando você decide e outra quando entrega. A maioria dos times não faz nenhuma das duas, e é por isso que os clientes param de relatar problemas. O segundo contato é o valioso: dizer a alguém que aquilo que pediu no trimestre passado já está no ar, no produto, no momento em que pode usar, converte um pedido em adoção e em boa vontade. Um anúncio in-app segmentado para quem fez o pedido é a forma confiável mais barata de fazer isso.
Quem deve ser o responsável pelas solicitações de funcionalidades?
Uma pessoa ou função nomeada deve ser dona da fila em si, normalmente um gerente de produto, às vezes alguém de product operations ou uma liderança de customer success, mesmo que todos contribuam com ela. Ser dono significa responder para que a triagem aconteça em uma cadência, para que os campos sejam preenchidos e para que as respostas voltem a quem pediu. Uma fila de pedidos com responsabilidade compartilhada gera, quase sempre, um backlog não lido, porque triagem é o tipo de trabalho que está sempre um pouco menos urgente do que todo o resto.
Quantas solicitações de funcionalidades você deve realmente construir?
Bem menos do que recebe. Uma fila é um insumo para a estratégia, não um substituto dela, e um roadmap montado a partir dos itens mais pedidos tende ao feature bloat: muitas capacidades, cada uma atendendo um grupo pequeno, e todas precisam ser mantidas e ensinadas a cada futuro usuário. O padrão mais saudável é procurar o problema recorrente por trás de grupos de pedidos e resolvê-lo uma vez, o que muitas vezes atende uma dúzia de pedidos com uma única mudança bem desenhada.