O que a autora Melissa Perri chama em seu livro de Build Trap é um problema que acontece quando as empresas começam a medir seu sucesso pelas entregas e não pelos resultados.

O tema é tão relevante, e essa é uma cilada que pega tantas empresas de software que a Melissa escreveu um livro dedicado para ajudar empresas a evitarem esse problema.

Quando você começa a medir mais “o quanto” está entregando do que “o valor” que essas entregas estão de fato trazendo para seus clientes fique atento.

Tudo aquilo que você adiciona de funcionalidades em seu produto deveria estar diretamente ligado à algum tipo de valor de negócio, o valor não pode ser a quantidade de funcionalidade entregues, mas os problemas que foram resolvidos e o valor que foi criado.

Normalmente, as startups quando estão na fase de encontrar o Product-Market-Fit, entendem que tudo são hipóteses a serem validadas e, naturalmente, já questionam todas as premissas até encontrar o caminho de maior valor. Já depois de ter um produto mais maduro e com usuários ativos isso, muitas vezes, acaba se perdendo.

Para evitar a armadilha uma das boas práticas é sempre começar perguntando o porquê. Mas atenção a resposta deve ser um problema e não a falta de uma funcionalidade.

O um dos erros mais comuns apontados por Melissa é definir o problema como sendo a falta de uma funcionalidade em vez de o que aquela falta causa.

Problema: Clientes não tem dashboard personalizados

Solução: Permitir criar dashboards personalizados.

Note que o problema real, não é o fato de não ter dashboards personalizados no produto, mas sim algo que o cliente não está conseguindo fazer para atingir seus objetivos.

Esse é um sinal para mergulhar mais profundamente e realmente entender o problema do cliente. Aquela máxima que entender o problema de verdade já é grande parte da solução realmente se aplica nesse caso.

Muitas vezes o próprio usuário/cliente pode te influenciar pulando direto para o a funcionalidade que ele acreditar resolver melhor seu problema. Dê um passo atrás e mergulhe no problema. Essa será a melhor forma de certificar que o foco esteja em buscar a melhor solução.

Recomendo bastante a leitura do livro da Melissa (infelizmente parece ainda não estar disponível em português).

E para mim o que ficou é lições aprendidas:

• O problema não é a falta de funcionalidade.
• O foco deve estar em problemas resolvidos e não funcionalidades entregues.
• Após entregar é preciso acompanhar e medir para certificar que o objetivo foi atingido.

E você já caiu na “Build Trap“? Conte nos comentários.

‍