O que fazer quando o seu roadmap e os seus clientes discordam
← Todos os artigos Construa a coisa certa

O que fazer quando o seu roadmap e os seus clientes discordam

Pela Equipe FabricLoop  ·  Maio 2026  ·  4 min de leitura

Toda equipe de produto passa por isso. Um cliente — muitas vezes um dos importantes — quer algo que não está no roadmap. Ele precisa com urgência. Pode até insinuar que a renovação depende disso. O seu time de vendas encaminha a mensagem com dois pontos de exclamação. De um lado, o seu roadmap, construído com cuidado ao longo de dois ciclos de planejamento. Do outro, o cliente. O que você faz?

Isso não é um caso isolado. Acontece com regularidade em qualquer produto com clientes pagantes, e a forma como você lida com a situação revela muito sobre como o seu processo de desenvolvimento de produto realmente funciona. O objetivo não é sempre dizer sim, nem sempre dizer não — é ter um método consistente para tomar a decisão.

“O pior resultado é o caminho da menor resistência: dizer sim para evitar a conversa desconfortável e, em silêncio, rebaixar a prioridade de todo o resto para cumprir uma promessa que você não deveria ter feito.”

Um framework de decisão para conflitos entre clientes e roadmap

Fluxograma de decisão: pedido do cliente vs. roadmap
O pedido vem de um único cliente ou de vários?
Um cliente
Esse cliente é estrategicamente importante para o seu segmento-alvo?
Não
Recuse com educação. Registre o pedido. Não construa.
Sim
O pedido se alinha a um resultado planejado no roadmap?
Vários clientes
O pedido se encaixa em um resultado estratégico do seu roadmap?
Não
Indica uma lacuna na estratégia. Discuta com a equipe antes de decidir.
Sim
Acelere. É uma validação forte — avance com isso.

A pergunta “um cliente ou vários?” é o primeiro filtro

Se vários clientes pedem a mesma coisa de forma independente, esse é um sinal que merece ser levado a sério — sobretudo se usam uma linguagem parecida para descrever o problema. Isso sugere que a necessidade é real e disseminada, e não pontual.

Se é um único cliente, a conta é outra. As necessidades de um cliente não representam o seu mercado, mesmo que seja a sua maior conta. Construir funcionalidades para um único cliente é um custo para a estratégia de produto que se acumula com o tempo: cada funcionalidade sob medida acrescenta complexidade, cria carga de manutenção e reduz o apelo do produto para o mercado em geral.

A armadilha do enterprise Clientes enterprise costumam ter os pedidos mais específicos e o maior poder de barganha. Mas otimizar o produto para o fluxo de trabalho da sua maior conta é o caminho para um produto impossível de vender a qualquer outra pessoa. Trate os pedidos específicos de clientes enterprise como trabalho sob medida — e não como insumo para o roadmap.

Como dizer não sem prejudicar o relacionamento

A chave para recusar o pedido de um cliente sem causar danos é reconhecer o problema, e não apenas o pedido. “Não vamos construir isso” cai mal. “Entendemos que você está com dificuldade para fazer X — veja como estamos pensando nesse problema e o que há no nosso roadmap que atende à mesma necessidade” cai muito melhor.

Os clientes raramente precisam da funcionalidade exata que pediram. Precisam que o problema de fundo seja resolvido. Se você consegue mostrar um caminho para isso — mesmo que não seja a funcionalidade que eles propuseram —, a maioria aceita. Se um cliente não aceita nenhum caminho além da sua especificação exata, isso diz algo importante sobre ele ser ou não um bom perfil para o seu produto.

A fórmula da resposta Reconheça o problema → explique por que você não vai construir isso agora → mostre o que você está construindo que atende à mesma necessidade → convide o cliente a continuar na conversa enquanto você desenvolve. Isso leva cinco minutos a mais do que um “não” e preserva muito mais boa vontade.

Quando o cliente tem razão e o roadmap precisa ser atualizado

Às vezes o conflito com o cliente revela uma lacuna real no seu raciocínio. Vários clientes pedindo algo que você não tinha planejado é sinal de que o seu roadmap deixou algo passar. A resposta certa não é sair construindo de imediato o que pediram — é investigar se o problema de fundo deve entrar no roadmap e, em caso afirmativo, em que posição.

Essa distinção importa. O cliente costuma ter razão sobre o problema; raramente tem razão sobre a solução. Use o feedback dele para refinar a sua compreensão do problema, e não para copiar e colar o pedido de funcionalidade no backlog.

Como o FabricLoop ajuda a acompanhar o sinal dos clientes Quando o mesmo pedido chega de vários clientes ao longo de alguns meses, o padrão é fácil de passar despercebido se o feedback está espalhado em threads de e-mail e anotações de CRM. O FabricLoop reúne os temas recorrentes em um só lugar para que você veja se o “pedido de um cliente” é, na verdade, uma tendência — antes de já ter dito não cinco vezes.

10 lições para levar deste artigo

  1. Conflitos entre clientes e roadmap são rotina, não exceção. Ter um método consistente para lidar com eles é mais importante do que qualquer decisão individual.
  2. A pior resposta é dizer sim para evitar a conversa e, em silêncio, rebaixar a prioridade de todo o resto para compensar.
  3. O primeiro filtro: é um cliente ou são vários? Vários pedidos independentes com linguagem parecida são um sinal que merece investigação.
  4. Construir funcionalidades para um único cliente — mesmo um grande — é um custo para a estratégia de produto que se acumula com o tempo.
  5. Clientes enterprise com pedidos específicos devem ser tratados como trabalho sob medida, e não como insumo para o roadmap.
  6. Recusar um pedido soa melhor quando você reconhece o problema de fundo, e não apenas a funcionalidade.
  7. A maioria dos clientes precisa que o problema seja resolvido, não que a sua especificação exata seja construída. Mostre o caminho, e não apenas o “não”.
  8. Se um cliente só aceita a sua especificação exata, isso diz algo importante sobre o encaixe entre ele e o seu produto.
  9. Quando vários clientes revelam uma lacuna real, investigue o problema de fundo — não copie simplesmente o pedido de funcionalidade para o backlog.
  10. Os clientes costumam ter razão sobre o problema. Raramente têm razão sobre a solução.