A Kodak perguntou o que os clientes queriam, e a resposta foi: “filmes melhores”. Assim, ignorou completamente a câmera digital criada dentro da própria empresa. A Blockbuster, de tanto escutar que os clientes queriam alugar filmes com maior comodidade, abriu mais de 9 mil lojas no mundo, desperdiçando a chance de comprar a Netflix ao focar apenas no que os clientes verbalizavam e não nas dores reais que estavam por trás das respostas.

Ouvir o cliente pode, literalmente, ser a receita perfeita para a irrelevância de um produto ou negócio. E se o seu cliente for o maior obstáculo para sua inovação?

É muito comum founders ou Product Managers se apoiarem em entrevistas com clientes como se elas revelassem verdades absolutas. Quem nunca trabalhou em uma empresa em que o cliente pede e você faz; o cliente sugere e você implementa; o cliente menciona e isso vira item de roadmap? O resultado é previsível: depois de alguns meses o time está exausto, não há clareza sobre o que o produto realmente resolve e começa uma multiplicação de funcionalidades que não sustentam valor.

Clientes respondem com base no presente, em desejos superficiais, no que acreditam que o entrevistador quer ouvir, e muitas vezes sem qualquer visão sistêmica do negócio em que estão inseridos afinal, normalmente são apenas funcionários dentro de uma organização. Clientes são ótimos para validar dores. Péssimos para imaginar o futuro.

O conceito de “Jobs to be Done” ilustra isso: um cliente não compra uma chave de fenda por suas características técnicas, mas porque precisa montar móveis. Da mesma forma, o seu produto deve resolver um problema relevante e não replicar todas as características da operação atual do cliente. A operação talvez nem devesse funcionar daquela forma.

Por isso, você não deve perguntar o que o cliente quer; deve entender o que ele está tentando resolver. É a partir dessa dor, não dos pedidos explícitos, que um produto consistente é criado.

O iPhone, a Netflix e o Uber não surgiram de sugestões de usuários, mas de dores profundas e mal resolvidas. O risco invisível de agradar demais mata startups ao gerar a falsa sensação de que tudo está bem até o contrato acabar sem qualquer explicação. Muitas empresas quebraram acreditando que, por terem feito tudo o que o cliente pediu, estavam no caminho certo.

Cada nova sugestão do cliente é uma bifurcação. Em vez de aprofundar um problema real, você passa a atender diversos desejos passageiros. Startups não podem ser um restaurante por quilo. Não existe buffet para todo mundo.

Founders e PMs devem observar comportamentos, entender a dor e, só então, criar o produto que será testado e ajustado conforme evidências reais, não promessas de como o cliente supostamente usaria a solução. Steve Jobs não perguntou o que queriam. Ele entendeu o que o mundo precisava antes que o mundo soubesse.

Se você continuar perguntando ao cliente o que ele quer, acabará construindo uma versão melhorada de algo que ninguém mais deseja. O futuro não é feito de pedidos, e sim de visão, escuta ativa, observação e coragem para dizer não.

Código importa muito menos do que você imagina. Seu trabalho como desenvolvedor é irrelevante se não gerar receita ou reduzir custos. A melhor arquitetura do mundo não salva um projeto atrasado. O código pode ser bonito, limpo e robusto — e, ainda assim, o cliente pode ir embora.

Um amigo contou que trabalhou em uma empresa cujo CTO, vindo de big tech, dominava profundamente tecnologia, conversava com clientes, falava com investidores e tinha todos os atributos que se espera de um líder técnico. Faltava apenas uma coisa: bom senso para reconhecer que arquitetura complexa e código impecável não resolvem o problema se o produto não chega a tempo ou não entrega valor. Código bonito não paga salário. Produto rodando, sim.

É comum ver profissionais defendendo princípios como SOLID, DRY, Clean Code e testes automatizados. Esses princípios são excelentes e devem ser norteadores. Porém, você não foi contratado para escrever códigos perfeitos; foi contratado para resolver problemas que geram caixa ou reduzem despesas. Se o seu código, por mais elegante que seja, não atende a isso, ele é dispensável.

A área de tecnologia existe para servir ao negócio. Desenvolvedores estão, inevitavelmente, ligados ao impacto financeiro da empresa. Quem nunca viu uma “gambiarra estratégica” salvar um trimestre? Ou um projeto que, de tanto se discutir a melhor forma de implementá-lo, atrasou até se tornar irrelevante? É possível seguir todos os princípios do Uncle Bob e, mesmo assim, construir a coisa errada da forma certa, no momento errado.

Isso não significa ignorar qualidade. Sem qualidade mínima, você até entrega uma vez ou outra, mas o futuro será instável. O ponto é entender quando exigir rigor técnico e quando priorizar velocidade. Nem todo code review precisa ser exaustivo. Nem toda funcionalidade precisa nascer com 100% de cobertura de testes, principalmente se ainda será validada e possivelmente ajustada na semana seguinte.

Melhores práticas não salvam negócios. Entregas certas, sim.

O equilíbrio entre qualidade e impacto no negócio é o que sustenta empresas de forma consistente. Tecnologia é meio, não fim. Cada vez mais é commodity. O que importa é gerar valor real para o cliente e capturar receita por isso.

Se você quer ser um bom engenheiro, pare de medir seu valor pela beleza do pull request ou pela performance do seu código isoladamente. Comece a medir pelo impacto que gera no negócio.

Quer ser relevante? Escreva código que move o ponteiro não código que apenas enfeita o repositório.