Um pedido de nova funcionalidade pode apontar para uma necessidade real — mas a solução sugerida nem sempre é a única, a mais simples ou a que atende mais pessoas. Quando solicitações parecidas se repetem, vale investigar o trabalho que alguém tenta concluir antes de transformar cada pedido em item de roadmap.
Isso não significa ignorar feedback ou adiar decisões indefinidamente. Significa entender o contexto, comparar evidências e escolher uma resposta coerente com a tarefa, as prioridades do negócio e os limites do produto.
Pedido é evidência, não especificação completa
Quando alguém diz “precisamos de um botão para exportar”, há uma observação explícita — o botão desejado — e uma pergunta aberta: por que a pessoa precisa exportar? Talvez queira compartilhar um relatório, conferir dados offline, cumprir uma rotina de auditoria, migrar informações ou evitar repetir trabalho.
Essas necessidades podem pedir soluções diferentes: relatório configurável, integração, permissão, busca melhor ou exportação. Implementar a primeira solução citada pode resolver o caso de quem pediu e ainda deixar intacta a dificuldade original de outras pessoas.
O GOV.UK Service Manual recomenda focar no problema da pessoa, não numa solução pré-escolhida. A orientação sugere combinar evidências existentes, como analytics, buscas e dados de atendimento, com entrevistas e observação. Sugestões ainda não verificadas permanecem hipóteses.
Por que recorrência merece atenção — e cuidado
Repetição pode indicar atrito relevante, mas não mede sozinha alcance nem impacto. Uma solicitação pode aparecer muitas vezes porque um cliente tem alto volume de uso, porque um grupo vocal está mais próximo da equipe ou porque o canal registra melhor determinado problema.
Também pode haver pedidos diferentes para a mesma necessidade. Pessoas com rotinas e vocabulários distintos podem descrever uma dificuldade de modos diferentes. Agrupe por trabalho, objetivo ou obstáculo observado, não apenas pelo nome da função solicitada.
- Quem pediu e em qual contexto de uso?
- Que tarefa a pessoa tentava realizar?
- O que fez antes e depois do pedido?
- Qual é a consequência de não concluir a tarefa?
- Há uma alternativa ou contorno usado hoje?
- O problema aparece em suporte, vendas, pesquisa ou dados de uso?
- Quais perfis ainda não foram ouvidos?
Um método para investigar o pedido
1. Registre o pedido sem convertê-lo imediatamente em requisito
Guarde as palavras originais, a data, a origem e o contexto. Evite reescrever a fala como especificação técnica antes de compreender o motivo. Se o pedido veio de vendas ou suporte, preserve a diferença entre o que a pessoa disse e a interpretação de quem registrou.
2. Descreva a tarefa que está por trás
Uma formulação como “Quando preciso comparar pedidos de períodos diferentes, quero reunir os dados para conferir a variação antes de fechar o mês” ajuda a esclarecer contexto e resultado sem decidir se a resposta será um dashboard, exportação ou integração. O GOV.UK recomenda escrever necessidades a partir da perspectiva da pessoa e validá-las com evidência.
3. Procure evidências em mais de um lugar
- Suporte: dúvidas recorrentes, contornos, reclamações e tarefas que exigem ajuda.
- Analytics e logs: caminhos interrompidos, buscas sem resultado, ações repetidas e abandono.
- Pesquisa: objetivo, contexto, restrições e palavras usadas pelas pessoas.
- Vendas e sucesso: cenário de compra, expectativa e diferença entre promessa e uso.
- Operação: retrabalho, erros, tempo, planilhas paralelas e solicitações manuais.
Não trate volume de tickets como substituto automático para frequência em toda a base. Registre período, perfil, canal, denominador quando houver e limites da amostra. Dados quantitativos podem mostrar onde investigar; conversas e observação ajudam a compreender por quê.
4. Converse sobre uma ocorrência concreta
Pergunte “conte sobre a última vez que isso aconteceu” antes de “você usaria a função X?”. A primeira pergunta convida a descrever comportamento passado. A segunda pode gerar uma intenção hipotética que não revela prioridade real.
- O que você tentava concluir naquele momento?
- O que iniciou a tarefa?
- O que fez quando o caminho esperado não funcionou?
- Que ferramentas, planilhas ou pessoas ajudaram a contornar?
- O que acontece se a tarefa atrasa ou não pode ser concluída?
- Com que frequência isso ocorre e para quais casos?
- Como você reconhece que terminou corretamente?
Evite apresentar a solução desejada cedo demais. Ela pode influenciar a resposta e confirmar a primeira hipótese em vez de revelar alternativas.
5. Agrupe oportunidades, não nomes de funcionalidades
“Exportar PDF”, “baixar relatório” e “enviar para o financeiro” podem apontar para uma oportunidade de compartilhar informação. Ainda assim, podem envolver públicos, permissões e critérios diferentes.
Um mapa simples pode ligar resultado de negócio, necessidades ou oportunidades, soluções possíveis e experimentos. A abordagem de Opportunity Solution Trees, da Product Talk, visualiza essa relação. O mapa deixa hipóteses explícitas; não substitui pesquisa nem garante que uma solução funcionará.
6. Avalie alcance, impacto, confiança e custo
- Alcance: quantas pessoas ou contas encontram essa situação?
- Frequência: com que regularidade a tarefa ocorre?
- Impacto: o que acontece quando falha ou atrasa?
- Evidência: quantas fontes independentes sustentam a hipótese?
- Alternativas: existe forma mais simples de remover o obstáculo?
- Alinhamento: como a melhoria contribui para objetivos do produto?
- Custo e dependências: que esforço, integração, suporte e manutenção serão necessários?
- Inclusão e risco: quem pode se beneficiar ou ser prejudicado?
Não esconda incerteza em uma pontuação. Uma nota pode organizar a conversa, mas não transforma suposições em dados. Registre premissas, evidências e o que falta aprender.
A próxima ação nem sempre é construir
- Resolver agora, quando a necessidade está compreendida, o impacto é relevante e a solução combina com a estratégia.
- Investigar, quando há sinais promissores, mas faltam dados sobre público, frequência ou consequência.
- Testar uma alternativa menor, como ajuste de conteúdo, fluxo, configuração ou protótipo.
- Acompanhar, quando o problema é real, mas pouco frequente ou de menor impacto diante de outras prioridades.
- Não priorizar agora, explicando o motivo e registrando o que poderia mudar a decisão.
O GOV.UK orienta a desenhar serviços em torno das necessidades, não de tecnologia ou solução pré-selecionada, e a considerar o problema de ponta a ponta no escopo apropriado. Veja Solve a whole problem for users. Isso não significa construir um sistema enorme: a orientação também fala em escopo coerente e melhoria incremental.
Como comunicar a decisão a quem pediu
Fechar o ciclo é parte do trabalho. Diga o que foi entendido, qual decisão foi tomada e por quê. Se a equipe ainda está investigando, informe que evidência busca e quando revisitará o tema, sem prometer uma entrega que não foi aprovada.
- Entendemos: a tarefa e a dificuldade descritas.
- Estamos avaliando: alternativas, alcance e impacto.
- Decidimos: construir, investigar, testar, acompanhar ou não priorizar agora.
- Próximo passo: o que acontecerá e como enviar contexto adicional, se necessário.
Evite “está no roadmap” se não houver compromisso e prazo definidos. Transparência protege a confiança e ajuda a equipe a aprender com retornos futuros.
Checklist antes de colocar uma funcionalidade no roadmap
- O pedido está ligado a uma tarefa e contexto específicos?
- A equipe ouviu pessoas além de quem sugeriu a função?
- A hipótese tem evidências de mais de uma fonte?
- A solução pedida é necessária ou há alternativas mais simples?
- Alcance, frequência, impacto e incertezas estão registrados?
- Dependências, manutenção, riscos e efeitos em outros fluxos foram considerados?
- Há uma forma pequena de testar a hipótese?
- A decisão e os próximos passos serão comunicados a quem contribuiu?
Conclusão
Pedidos recorrentes são sinais que merecem investigação, não especificações completas. A equipe aprende mais quando pergunta que tarefa está por trás, observa como acontece hoje, combina fontes de evidência e compara alternativas antes de definir a solução.
O resultado pode ser uma nova funcionalidade. Também pode ser uma mudança menor, conteúdo mais claro, uma configuração ou a decisão de não priorizar agora. O critério é se a resposta atende uma necessidade relevante com escopo coerente — e se a equipe consegue explicar a escolha.
Qual pedido recorrente do seu produto talvez esconda uma necessidade diferente da solução sugerida?
