Se tem algo que todos nós fazemos, sem exceção, é cometer erros.
Quando estava pensando nesse assunto, lembrei de muitos exemplos diferentes de erros que não percebemos que cometemos no dia a dia.
Pensando nisso, resolvi separar alguns que acredito que acontecem com mais frequência.
Pensar que você é o usuário
É fácil nos convencermos que já conhecemos bem o problema ou o comportamento de uso do nosso usuário.
Até podemos conhecer o usuário bem, m
as nem sempre temos os mesmos problemas que eles, e mesmo que tenhamos, podemos viver em contextos e ambientes muito diferentes.
Evite adicionar funcionalidades que "são legais" de ter no produto, ou que você acredita que o usuário vai gostar. Ele vai usar o produto para resolver um problema real e esse deve ser o nosso foco, resolver o problema.
Para garantir que estamos no caminho certo precisamos sempre validar o produto com quem realmente importa, o usuário. Devemos considerar sempre seu ponto de vista e construir o produto mantendo sua perspectiva em mente.
O produto é para o usuário, e não para o PM.
Começar muitas coisas e não terminar
O Kanban tem uma ideia chave que diz "Pare de começar e comece a terminar".
Não adianta entregar diversas coisas em paralelo se o que foi entregue são apenas MVPs que ninguém vai voltar depois para terminar. Quando entregamos uma versão mínima de algo, deixamos alguns pontos importantes de lado para testarmos rápido.
Você escolhe se quer resolver esses pontos importantes agora, ou possivelmente será obrigado a resolver eles no futuro.
MVPs são importantes para validar hipóteses rapidamente, e normalmente não são suficientes para ficar no ar e serem usados em escala. Se for, talvez você não tenha feito um MVP.
Confundir a melhoria do produto com a inclusão de novas funcionalidades
Incluir novas funcionalidades não quer dizer que o produto está melhorando, na verdade conforme mais funcionalidades o produto recebe, mais complexo, difícil de usar e de comunicar ele pode ficar.
A evolução do produto - em alguns casos - é deixá-lo cada vez mais simples, resolvendo muito bem determinados problemas do usuário.
Um produto com muitas funcionalidades não é necessariamente melhor, já um produto que resolve muitos problemas, sim.
Dizer "sim" para tudo
É normal fazermos reuniões em que são apresentadas listas de funcionalidades importantes para o produto que vão "resolver todos os problemas".
Na verdade, muitas idéias que chegam para o PM são muito boas e faz sentido serem testadas. Outras talvez ainda não seja a hora certa, e algumas são ruins e não devem ser consideradas.
Primeiro entenda os problemas que estão por trás dessas listas, veja se eles são realmente importantes e precisam de uma solução agora, e só depois comece a pensar em como você pode resolvê-los.
Pensar na solução antes do problema
Conhecer muito bem o problema a ser resolvido nos permite pensar em diversas formas de resolvê-lo.
Investir tempo na definição correta do problema, nos faz economizar tempo na hora de pensar na solução, e diminui bem o risco de priorizarmos a solução errada.
Finalizando
Essa aula de Gestão de Produto feita pelo Marty Cagan no Mind the Product, com diversos exemplos de erros que devemos evitar.
Referências:
- 5 Things to Avoid as a Product Manager
- The Top 12 Product Management Mistakes - By Marty Cagan
- The Modern Day Good Product Manager/Bad Product
- The Five Mistakes All Product Managers Will Make (And What They Will Learn)
- What Product Managers Can Learn From 4 Products That Flopped
- The Root Causes of Product Failure by Marty Cagan
- How To Communicate Product Vision And Strategy To Just About Anyone
