Para priorizar pedidos de recursos, agrupe-os pelo problema por trás deles, dê a cada problema uma nota de alcance, dor, encaixe e esforço e converse com algumas das pessoas que pediram antes de se comprometer. Esse último passo é o que a maioria das equipes pula, e é o lugar mais barato para evitar uma aposta ruim. Desenvolver a coisa errada é comum: o relatório de adoção de recursos de 2019 da Pendo, baseado em três meses de dados de uso de 615 assinaturas de clientes da Pendo, concluiu que 80% dos recursos de um software médio são raramente ou nunca usados.
Principais pontos
- Um pedido de recurso é o palpite de um cliente sobre uma solução. Priorize o problema por trás dele.
- A contagem de votos mostra quem se manifestou, não o quanto o problema dói.
- Escolha qualquer framework simples, mas alimente-o com o que você aprende conversando com quem pediu.
- Decida e depois conte às pessoas o que decidiu, inclusive quando a resposta é não.
Por que a contagem de votos engana
A maioria das equipes registra os pedidos em algum lugar: um quadro, uma planilha, um canal no Slack. Depois desenvolve o que tiver mais votos. Parece justo, mas é arriscado.
- Clientes barulhentos entram na conta. Os quietos, não. Quem publica pedidos nem sempre é quem você mais quer manter.
- Pedidos são soluções, não problemas. “Adicionem exportação em CSV” pode significar, na verdade, “meu gestor quer um relatório semanal”. Um e-mail de resumo agendado talvez resolva melhor.
- Duplicatas dividem os votos. Cinco pedidos escritos de cinco jeitos parecem cinco problemas pequenos, e não um grande.
- Votos não têm peso. Um pedido que manteria uma conta grande vale o mesmo que um “seria bom ter”.
- Votos não expiram. Pedidos antigos ficam no topo muito depois de a necessidade ter acabado.
Um voto é um sinal para ir perguntar. Não é a resposta.
Os frameworks de priorização, em resumo
Você vai ver o mesmo punhado de frameworks em todo guia. Veja para que cada um serve.
| Framework | Como funciona | Ideal para | Cuidado com |
|---|---|---|---|
| Contagem de votos | Ordena pelo número de pedidos | Um primeiro sinal | Clientes barulhentos, duplicatas divididas |
| RICE | Alcance × Impacto × Confiança ÷ Esforço | Comparar muitas ideias | A confiança muitas vezes é um chute |
| ICE | Impacto × Confiança × Facilidade | Triagem rápida | Muito subjetivo |
| MoSCoW | Must, Should, Could, Won’t (precisa, deveria, poderia, não terá) | Um prazo ou lançamento fixo | Não há ordem dentro de cada grupo |
| Impacto vs. esforço | Uma matriz simples 2×2 | Achar ganhos rápidos | Ignora quantas pessoas são afetadas |
| Kano | Recursos básicos, de desempenho e de encantamento | Entender expectativas | Precisa de uma pesquisa para ser feito direito |
| Peso por receita | Pesa cada voto pelo valor da conta | B2B com poucas contas grandes | Pode atender demais a poucos clientes grandes |
O RICE, descrito pela primeira vez por Sean McBride, da Intercom, é um bom padrão para a maioria das equipes de produto. Mas todo framework tem o mesmo ponto fraco: alcance, impacto e confiança dependem de o quanto você entende o problema. Os passos abaixo servem para acertar essa parte.
Passo 1: reúna todos os pedidos em um só lugar
Os pedidos chegam por chamados de suporte, ligações de vendas, mensagens no app, e-mails e avaliações. Coloque todos em uma lista para ver lado a lado.
Para cada pedido, registre:
| Campo | Exemplo |
|---|---|
| Pedido | Exportar relatórios em CSV |
| Quem pediu | Líder de operações em um cliente de porte médio |
| As palavras exatas | “Toda segunda eu copio números para uma planilha para o meu chefe.” |
| Plano ou segmento | Plano Business, 40 usuários |
| Origem e data | Chamado de suporte, 3 de março |
As palavras exatas são o mais importante. Muitas vezes mostram o problema com mais clareza do que o próprio pedido.
Não esqueça as fontes silenciosas. Anotações de vendas perdidas e respostas de clientes que cancelaram muitas vezes trazem pedidos que nunca chegam ao seu quadro.
Passo 2: encontre o problema por trás de cada pedido
Reescreva cada pedido como um problema, usando uma frase simples:
Quem está tentando objetivo, mas obstáculo.
No exemplo do CSV: “Líderes de equipe estão tentando compartilhar os números semanais com o gestor, mas precisam copiá-los à mão.”
Agora agrupe os pedidos que têm o mesmo problema. Cinco pedidos diferentes (exportação em CSV, e-mails agendados, um link público para o painel, um botão de PDF e um endpoint de API) podem ser todos o mesmo problema. Juntos, ele é muito maior do que qualquer pedido isolado parecia.
Essa é a ideia central do jobs to be done: as pessoas não querem o recurso em si. Querem o progresso que ele traz.
Passo 3: converse com quem pediu
Antes de dar qualquer nota, converse com algumas das pessoas por trás dos seus maiores grupos. Uma conversa curta diz mais do que uma pilha de votos.
Pergunte sobre a situação real delas, não sobre a sua ideia:
- “O que você estava tentando fazer quando pediu isso?”
- “Como você resolve isso hoje?”
- “Com que frequência isso acontece?”
- “O que acontece quando isso não é feito?”
- “Quem mais é afetado?”
Evite “Você usaria se a gente desenvolvesse?”. Quase todo mundo diz que sim, então isso não diz nada. Nosso guia sobre perguntas tendenciosas tem mais exemplos do que evitar.
Como soa uma boa conversa
Você: O que você estava tentando fazer quando pediu a exportação em CSV?
Cliente: Colocar nossos números no relatório de segunda.
Você: Quem lê esse relatório?
Cliente: Minha gestora. Ela só quer três números e a tendência. Toda semana eu copio tudo para os slides.
Você: Quanto tempo isso leva?
Cliente: Quase uma hora, toda segunda.
O pedido era “exportação em CSV”. A necessidade é “mostrar três números para minha gestora toda semana sem trabalho braçal”. Um e-mail de resumo agendado poderia resolver isso em uma fração do tempo de desenvolvimento, e ajudaria todos os clientes com o mesmo ritual de segunda-feira.
Evidência forte e evidência fraca
| Sinal fraco | Sinal forte |
|---|---|
| “Seria bom ter.” | “Gasto uma hora com isso toda segunda.” |
| “Claro, eu usaria.” | “A gente paga outra ferramenta só para fazer isso.” |
| Um único voto | Uma solução improvisada que eles mesmos criaram |
| “Todo mundo quer isso.” | Nomes, datas e quanto isso custou |
Quantas conversas bastam
Continue conversando até conseguir prever o que a próxima pessoa vai dizer. Quando as histórias começam a se repetir, você entende o problema bem o bastante para dar uma nota.
Se as histórias continuam mudando, isso também é uma descoberta. Um pedido pode cobrir vários problemas diferentes, e você deve dividir o grupo. Para mais perguntas, veja nossas perguntas para entrevistas com clientes.
Passo 4: dê uma nota a cada problema
Agora dê notas aos problemas, não aos pedidos. Mantenha simples. Uma nota que sua equipe realmente atualiza vale mais que uma perfeita que ninguém toca.
Dê a cada problema uma nota de 1 a 3 em quatro critérios:
- Alcance: quantos dos clientes que importam para você têm esse problema.
- Dor: o quanto isso machuca, com base no que você ouviu.
- Encaixe: o quanto resolvê-lo combina com o rumo do seu produto.
- Esforço: quanto trabalho exige. Maior significa mais trabalho.
Depois calcule: Alcance × Dor × Encaixe ÷ Esforço.
| Problema | Alcance | Dor | Encaixe | Esforço | Nota |
|---|---|---|---|---|---|
| Compartilhar números semanais com gestores | 3 | 2 | 3 | 2 | 9 |
| Login único (SSO) para equipes maiores | 1 | 3 | 3 | 3 | 3 |
| Modo escuro | 2 | 1 | 1 | 2 | 1 |
O problema de compartilhamento ganha, mesmo que o modo escuro tivesse mais votos sozinho. Os pedidos de compartilhamento estavam espalhados por cinco ideias de recurso diferentes, então nenhum parecia grande.
Pese pela receita, com cuidado
Em B2B, é justo dar mais peso a problemas que afetam suas contas maiores ou que crescem mais rápido. Só não deixe o peso por receita comandar o roadmap. Alguns clientes grandes podem puxar você para recursos de que ninguém mais precisa, e os segmentos novos que você quer conquistar ainda não geram receita.
Quando um cliente grande pede
Às vezes uma conta grande quer algo que ninguém mais pediu. A tentação é dizer sim na hora.
Primeiro, encontre o problema por trás, como em qualquer outro pedido. Depois pergunte se clientes menores parecidos com ela vão esbarrar no mesmo problema à medida que crescerem. Se sim, talvez ele mereça entrar no roadmap. Se só servir para aquela conta, trate como um acordo personalizado, com preço e prazo claros.
Deixe espaço para suas próprias apostas
Os pedidos dos clientes mostram os problemas de hoje. Raramente mostram para onde o mercado está indo. Decida de antemão quanto do tempo da equipe vai para problemas dos clientes, para suas próprias apostas estratégicas e para correções e manutenção. Depois priorize os pedidos dentro da fatia deles, para que um quadro cheio não tome conta do roadmap inteiro sem ninguém perceber.
Passo 5: decida e feche o ciclo
Escolha o principal problema, defina uma solução e avise quem pediu. Clientes que recebem retorno continuam contando do que precisam. Nosso guia sobre o ciclo de feedback do cliente mostra como transformar isso em hábito.
Dizer não faz parte do trabalho. Dois modelos para adaptar:
Agora não
Olá, nome,
Obrigado por perguntar sobre recurso. Não vamos desenvolvê-lo neste trimestre.
Vamos focar primeiro em outro problema, porque mais clientes esbarram nele.
Você comentou que está tentando objetivo da pessoa. Enquanto isso, veja como
alguns clientes resolvem: solução alternativa ou artigo de ajuda.
Guardei sua mensagem com as suas palavras exatas e aviso você se isso mudar.
Fora dos planos
Olá, nome,
Obrigado pela ideia sobre recurso. Quero ser sincero com você:
ela não combina com o rumo que estamos dando ao produto, então não pretendemos desenvolvê-la.
Para objetivo da pessoa, outra ferramenta ou solução alternativa pode servir melhor.
Se suas necessidades mudarem, ainda quero saber.
Uma rotina simples que mantém a lista honesta
Priorizar uma vez só não ajuda muito. Uma rotina leve, sim.
| Frequência | O que fazer |
|---|---|
| Toda semana | Adicione pedidos novos com as palavras exatas, junte duplicatas e ligue cada um a um problema |
| Todo mês | Converse com três a cinco pessoas por trás dos seus maiores grupos de problemas |
| Todo trimestre | Refaça as notas da lista, escolha o próximo passo e conte a quem pediu o que você decidiu |
Vinte minutos por semana bastam para a maioria das equipes. São as conversas mensais que mantêm suas notas ligadas a clientes reais, e não a quem postou por último.
Erros a evitar ao priorizar pedidos de recursos
- Desenvolver para o cliente mais barulhento. Primeiro veja se outros têm o mesmo problema.
- Dar notas a recursos em vez de problemas. Você vai dividir um problema grande em pedidos pequenos que parecem todos secundários.
- Perguntar se as pessoas usariam. Pergunte como elas lidam com o problema hoje.
- Nunca olhar para trás. Refaça as notas da lista a cada trimestre. As necessidades mudam, e seu produto também.
Como o Diaform ajuda
Conversar com todo mundo por trás de um pedido leva tempo, e a maioria não vai marcar uma chamada. Com o Diaform, você envia um link. Um agente de IA faz suas perguntas por voz ou texto, faz follow-up quando alguém diz “seria bom ter” e resume cada conversa quando ela termina.
Envie o link por e-mail ou mostre dentro do seu app. A partir do plano Pro, links só para convidados podem levar o e-mail ou o ID de usuário de cada pessoa, para você saber qual conta disse o quê. Exporte as respostas em CSV e adicione à sua planilha de notas. Veja como o Diaform lida com feedback de produto ou comece um teste grátis de 14 dias.
