Time to say no

Quando dizer não ao seu cliente?

Pra quem não me conhece, sou Eduardo, sócio fundador da Mainô, empresa responsável pelos sistemas Comex NF-e e Traxo. Para a finalidade deste artigo basta saber que ambos os softwares foram criados pela Mainô e são comercializados no modelo SAAS (software as a service). Ambos são softwares de gestão empresarial, que auxiliam nos processos de emissão de nota fiscal, gestão de estoque e gestão financeira de qualquer empresa de comércio.

O Comex NF-e, com foco em comércio exterior, é um software que já tem sua maturidade: 6 anos de estrada. Já o Traxo possui menos de 6 meses de sua primeira versão, e ainda não teve nenhum lançamento “oficial”.

Seis anos tocando um mesmo sistema em uma área que não é minha especialidade (comércio exterior), posso dizer que na verdade o sistema foi elaborado pelos meus clientes, não por mim. Entretanto, não vou tirar o mérito do que conseguimos fazer na Mainô. Desde o dia 1 de lançamento do Comex NF-e até hoje, creio que posso contar nos dedos os dias que não recebemos nenhuma solicitação ou pedido de clientes para realizar alterações no sistema. Já seria impossível atender todas as demandas, quem dirá atendê-las e ainda manter um sistema simples e intuitivo.

Se você já viu algum software de gestão empresarial, já deve ter percebido que muitos deles são difíceis de usar, pouco intuitivos, e com muitas funcionalidades que foram desenvolvidas para atender um ou dois clientes. Quando me deparo com um sistema desses, sempre me pergunto: como isso foi ficar desse jeito? E depois de 6 anos de Comex NF-e, posso dizer: é muito fácil o sistema se tornar um Frankestein se você não tomar cuidado. Basta fazer tudo que os clientes pedem.

Solicitações de Clientes x Visão da Empresa

Segundo a metodologia Lean Startup devemos lançar o produto o quanto antes para coletar feedback do mercado e assim aprimorar o produto buscando alcançar o market fit. Veja, não há nada de errado com isso. Entretanto, durante muito tempo confundi isso com “vamos fazer tudo o que os clientes pedem”. E quase caímos no abismo do vale dos sistemas mortos-vivos, que são onde os sistemas bizarros ficam vagando sugando as almas de empresas que um dia foram promissoras. Empresas essas que já possuem um número considerável de clientes para se desistir e mudar tudo, mas não conseguem crescer mais porque se desviaram da visão inicial.

Então se o segredo é dizer não para os clientes e seguir minha visão inicial? Não precisamos mais lançar o produto o quanto antes? O Lean Startup é uma farsa? O MVP é uma enganação?

É claro que não. O que eu vou dizer agora é uma das coisas mais fáceis de se decorar e mais difíceis de se executar. O feedback dos clientes é incrivelmente importante para seu negócio, entretanto você precisa ser capaz de diagnosticar o real problema do cliente. E o real problema do cliente meu amigo, não é tão obvio quanto parece, pois na maioria das vezes nem o cliente sabe. Conhece aquela frase: “o cliente não sabe o que quer até ele ver o que quer, pois nesse momento ele saberá que é exatamente aquilo que ele queria.”? Confuso não? Mas o que quero dizer é que os clientes sabem a dor que sentem, mas não têm a menor ideia do conjunto de funcionalidades que vai resolver essa dor. Eles vão dar sugestões baseadas em sistemas Frankesteins que já viram por aí, e nesse momento que sua empresa pode ser arrastada para o vale da morte.

Certo, então como aproveitar o feeedback dos clientes sem ser uma marionete?

O próprio livro do Lean Startup aborda a solução quando menciona a estratégia dos 5 porquês. É necessário conhecer a raiz dos problemas. Toda solicitação de cliente na verdade resolve um problema-raiz escondido, que provavelmente nem mesmo o cliente conhece direito. ele conhece bem as consequências do problema, mas as causas geralmente não estão claras. E ao entender o problema-raiz que originou a solicitação, você conseguirá tomar a melhor decisão. Ela pode ser:

  1. Não fazer nada, pois você chegou a conclusão que o problema não é tão relevante assim ou a quantidade de clientes que passam por esse problema não é tão relevante.
  2. Resolver o problema, onde a solução pode ser ou não aquela proposta pelo cliente (por experiência, geralmente a solução é outra completamente diferente).
  3. Guardar como backlog, pois você ainda não está certo da relevância daquele problema.

Vamos ilustrar através da seguinte situação:

Cliente: Eduardo, preciso de um campo de código de cliente.

Eu: Certo, mas qual o motivo?

Cliente: Quero depois buscar informações por esse código.

Eu: Certo, mas não pode ser o CNPJ da Empresa?

Cliente: O CNPJ é difícil de lembrar.

Eu: E o código não?

Cliente: O código nós já sabíamos porque o sistema anterior era assim (Primeiro alerta! Comparar com uma solução já existente. Provavelmente o sistema anterior era um Frankenstein!!!)

Eu: E você não pode buscar o cliente pelo nome

Cliente: Mas pelo código é mais rápido. (Segundo alerta! Qual o parâmetro de comparação? É mais rápido que o quê?)

Eu: Certo, compartilhe a tela comigo. Gostaria de ver onde e como você utiliza a busca por clientes.

E nesse momento descobri que a solução não era criar um código para o cliente, mas implementar a busca de clientes com uma consulta do tipo “like”, que busca uma parte da palavra no todo, que atualiza a busca enquanto o usuário digita, além de buscar simultaneamente pela razão social e pelo nome fantasia do cliente.

Nesse caso o usuário tinha como parâmetro um sistema anterior, cuja busca por razão social era uma experiência ruim, visto que ele precisava lembrar se o nome do cliente que ele tinha era na verdade a razão social ou o nome fantasia. No fim das contas conseguimos evitar a criação de mais um campo inútil no cadastro de clientes, além de obter um aprendizado com relação a forma com que os usuários consultam seus clientes.

Algumas vezes, entendendo a fundo o problema do cliente, você consegue mostrar para ele que o seu sistema resolve o problema de outra forma. Por exemplo, depois que implementamos tags nos objetos do sistema, muitas das necessidades de campos para posterior consulta foram supridas.

Hoje, 6 anos depois do lançamento do sistema, continuamos recebendo solicitações todos os dias. Entretanto, nosso backlog de desenvolvimento possui aproximadamente apenas uns 20 itens. Para que a estratégia funcione é preciso que todos na empresa estejam alinhados com ela, desde o comercial até o suporte. No fim, o próprio cliente é beneficiado, pois possui um sistema mais simples e eficaz no que ele se propõe. E a empresa tem espaço para continuar buscando seu propósito.