← Todos os artigos
Construir a coisa certa
O que fazer quando o roadmap e os clientes não estão de acordo
Pela equipa FabricLoop · maio de 2026 · 4 min de leitura
Todas as equipas de produto recebem o telefonema. Um cliente — muitas vezes um dos importantes — quer algo que não está no roadmap. Precisa disso com urgência. Pode até insinuar que a renovação depende disso. A equipa comercial reencaminha a mensagem com dois pontos de exclamação. O roadmap, cuidadosamente construído ao longo de dois ciclos de planeamento, está de um lado. O cliente está do outro. O que faz?
Isto não é um caso excecional. Acontece regularmente em qualquer produto com clientes pagantes, e a forma como o gere revela muito sobre o modo como o seu processo de desenvolvimento de produto funciona de facto. O objetivo não é dizer sempre que sim, nem dizer sempre que não — é ter um método consistente para decidir.
"O pior resultado é o caminho de menor resistência: dizer que sim para evitar a conversa incómoda e depois despriorizar tudo o resto em silêncio para cumprir uma promessa que nunca devia ter sido feita."
Um framework de decisão para conflitos entre clientes e roadmap
Fluxograma de decisão: pedido de cliente vs. roadmap
Este pedido vem de um cliente ou de vários?
Um cliente
Este cliente é estrategicamente importante para o seu segmento-alvo?
Não
Recuse com cortesia. Registe o pedido. Não o construa.
Sim
Isto alinha-se com um resultado previsto no roadmap?
Vários clientes
Isto enquadra-se num resultado estratégico do seu roadmap?
Não
Sinaliza uma lacuna estratégica. Discuta com a equipa antes de decidir.
Sim
Acelere. É uma validação forte — avance com isto.
A questão "um cliente ou vários" é o primeiro filtro
Se vários clientes pedem a mesma coisa de forma independente, é um sinal que merece ser levado a sério — sobretudo se usam uma linguagem semelhante para descrever o problema. Sugere que a necessidade é real e generalizada, e não idiossincrática.
Se é um só cliente, a conta é diferente. As necessidades de um cliente não são representativas do mercado, mesmo que seja a maior conta. Desenvolver funcionalidades para um único cliente é um imposto sobre a estratégia de produto que se acumula ao longo do tempo: cada funcionalidade à medida acrescenta complexidade, cria encargos de manutenção e estreita o apelo do produto junto do mercado mais amplo.
A armadilha empresarial
Os clientes empresariais têm muitas vezes os pedidos mais específicos e o maior poder de pressão. Mas otimizar o produto para o fluxo de trabalho da maior conta é como os produtos se tornam impossíveis de vender a qualquer outro cliente. Trate os pedidos específicos de clientes empresariais como trabalho personalizado — e não como contributo para o roadmap.
Como dizer não sem prejudicar a relação
A chave para recusar um pedido de um cliente sem o magoar é reconhecer o problema, e não apenas o pedido. "Não vamos construir isto" soa mal. "Compreendemos que tem dificuldade em fazer X — eis como estamos a pensar nesse problema e eis o que está no nosso roadmap para dar resposta à mesma necessidade" soa muito melhor.
Os clientes raramente precisam da funcionalidade exata que pediram. Precisam que o problema de fundo seja resolvido. Se lhes puder mostrar um caminho para isso — mesmo que não seja a funcionalidade que propuseram —, a maioria aceitá-lo-á. Se não aceitarem outro caminho que não seja a sua especificação exata, isso diz-lhe algo importante sobre se este cliente é uma boa opção para o seu produto.
A fórmula de resposta
Reconheça o problema → explique porque não está a construir isto agora → mostre o que está a construir que dá resposta à mesma necessidade → convide-os a manterem-se na conversa à medida que o desenvolve. Demora mais cinco minutos do que um "não" e preserva muito mais boa vontade.
Quando o cliente tem razão e o roadmap precisa de ser atualizado
Por vezes, o conflito com o cliente revela uma lacuna genuína no seu raciocínio. Vários clientes a pedirem algo que não tinha planeado é sinal de que o roadmap deixou escapar alguma coisa. A resposta certa não é construir de imediato o que pediram — é investigar se o problema de fundo pertence ao roadmap e, se pertencer, onde.
Esta distinção é importante. O cliente tem muitas vezes razão quanto ao problema; raramente tem razão quanto à solução. Use o feedback para atualizar a sua compreensão do problema, e não para copiar e colar o pedido de funcionalidade no backlog.
Como a FabricLoop ajuda a acompanhar o sinal dos clientes
Quando o mesmo pedido chega de vários clientes ao longo de vários meses, é fácil perder o padrão se o feedback estiver em e-mails dispersos e notas de CRM. A FabricLoop reúne os temas recorrentes num só lugar, para que possa ver se o "pedido de um cliente" é, na verdade, uma tendência, antes de já ter recusado cinco vezes.
10 ideias a reter deste artigo
- Os conflitos entre clientes e roadmap são rotina, não exceção. Ter um método consistente para os tratar é mais importante do que qualquer decisão individual.
- A pior resposta é dizer que sim para evitar a conversa e depois despriorizar tudo o resto em silêncio para compensar.
- O primeiro filtro: é um cliente ou são vários? Vários pedidos independentes, com linguagem semelhante, são um sinal que merece ser investigado.
- Desenvolver funcionalidades para um único cliente — mesmo que grande — é um imposto sobre a estratégia de produto que se acumula ao longo do tempo.
- Os pedidos específicos de clientes empresariais devem ser tratados como trabalho personalizado, e não como contributo para o roadmap.
- Recusar um pedido soa melhor quando reconhece o problema de fundo, e não apenas a funcionalidade.
- A maioria dos clientes precisa que o problema seja resolvido, não que a sua especificação exata seja construída. Mostre-lhes o caminho, e não apenas o não.
- Se um cliente só aceita a sua especificação exata, isso diz-lhe algo importante sobre a adequação entre ele e o seu produto.
- Quando vários clientes revelam uma lacuna genuína, investigue o problema de fundo — não se limite a copiar o pedido de funcionalidade para o backlog.
- Os clientes costumam ter razão quanto ao problema. Raramente têm razão quanto à solução.
