5 min

174 - Product Roadmap: Escapando do Build Trap (Cilada das Funcionalidades‪)‬ André Faria Show - Gestão, Negócios e Tecnologia

    • Business

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.

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.

5 min

Top Podcasts In Business

Finshots Daily
Finshots
WTF is with Nikhil Kamath
Nikhil Kamath
Think Fast, Talk Smart: Communication Techniques
Stanford GSB
The Neon Show
Siddhartha Ahluwalia
Moneycontrol Podcast
moneycontrol
The BarberShop with Shantanu
The BarberShop with Shantanu