Para Saber Quando Parar

Saber quando parar é um dos momentos mais complicados no desenvolvimento de produtos de software que ocorre depois que uma startup supera seus estágios iniciais.

Muitas vezes presencio uma realidade sombria em que um produto de sucesso, que garantiu mais recursos para seu desenvolvimento contínuo, começa a expandir rapidamente sua equipe. Isso é compreensível, pois a pequena equipe original não tinha capacidade para implementar todos os aspectos importantes do projeto, e o aumento do financiamento destina-se a resolver esse problema.

Após a expansão e contratação de novas pessoas, as coisas tendem a correr bem por um tempo. Uma equipe de desenvolvimento nova, impressionante e maior finalmente consegue lidar com todas as tarefas há muito atrasadas. Porém, com a ampliação da equipe de desenvolvimento, surge a necessidade de ampliar também a equipe de gerenciamento de produto.

Isso cria uma armadilha significativa. Uma vez que a equipe tenha capacidade para lidar com todas as tarefas necessárias, a equipe de gerenciamento começa a abordar todos os pontos problemáticos com novos recursos. No entanto, uma vez que todas as tarefas críticas tenham sido concluídas, novos planos e roteiros podem ainda não estar em vigor. Apesar disso, muitas vezes há uma forte necessidade de fornecer novas tarefas com urgência para a equipe de desenvolvimento.

Além disso, você tem um grupo de gerentes de produto recém-contratados que pagaram com sucesso todas as dívidas pendentes de produtos. Enquanto aguardam ansiosamente o próximo desafio significativo, eles começam a debater ideias para melhorias adicionais no produto que já funciona bem.

Nesta fase, a equipa enfrenta frequentemente uma escassez de métricas adequadas e metodologias de experimentação, que ainda não implementou. Também é bem conhecido que avaliar a influência de um único recurso em uma métrica de produto de nível superior pode ser um desafio. Como resultado, novos recursos podem ser adicionados simplesmente “porque gostamos deles” e não têm impacto negativo no produto.

Então, desta vez, o produto começa a mudar sem motivo. Os cenários do usuário, que valorizam nosso produto para os usuários, são alterados, resultando em confusão entre os usuários. A interface fica cheia de “sinos e assobios”, tornando-a difícil de compreender.

O produto outrora amigável e familiar, que efetivamente atendeu às necessidades do usuário, se transforma em uma confusão confusa de recursos desnecessários que obscurecem o cenário valioso primário.

Portanto, os usuários podem não conseguir mais utilizar o cenário principal, que antes era o recurso principal do produto. Só porque os gerentes de produto não têm nada para fazer.

E então todos percebem a queda na retenção e tentam “consertar” enviando toneladas de notificações push…