Relembrando o que falei no Capítulo 04 – Principais características de um gestor de produtos, a característica mais importante que todo gestor de p...

Relembrando o que falei no Capítulo 04 – Principais características de um gestor de produtos, a característica mais importante que todo gestor de produto precisa ter é a empatia, ou seja, a capacidade de se colocar no lugar de outra pessoa para compreender seus anseios, motivações, necessidades e problemas. Essa característica deve ser usada não somente com o cliente do produto como também com as pessoas das diferentes áreas da empresa. Como dito, o gestor de produtos deve entender o impacto que seu produto tem no trabalho do jurídico: será que aumentaram os problemas jurídicos devido a alguma funcionalidade nova no produto? E quanto à equipe de vendas, suporte, operações, financeiro, marketing, será que o novo produto complicou muito a vida deles? E em relação ao time do produto, os engenheiros e os analistas de UX que fazem parte do core team do produto, como as suas decisões em relação ao produto, qual o impacto em suas funções? É o que veremos nos próximos capítulos! Vou começar falando sobre a relação entre engenharia de produto e gestão de produtos. Definição Engenharia de produto é responsável por desenvolver o produto e mantê-lo operando. Com a visão de negócios trazida pelo gestor de produto, mais o desenho de solução feito pelo pessoal de UX – baseado no entendimento da necessidade ou do problema do cliente –, a engenharia de produto “constrói” o produto. Para construí-lo, ela deve não só fazer a programação como também definir sua arquitetura técnica. Ou seja, qual é a infraestrutura onde ele rodará, qual a linguagem de programação mais adequada, qual o banco de dados mais apropriado, como garantir os requisitos não funcionais desse produto (velocidade de resposta, disponibilidade, escalabilidade etc.). Deve também validar com o gestor de produtos se o custo dessa infraestrutura cabe no seu modelo de negócio. O fato de o gestor de produto ser responsável por definir o produto a ser feito pode dar a impressão de que a engenharia de produtos está subordinada à gestão de produtos. Entretanto, essa visão é incorreta e, se as áreas se comportarem dessa forma, a chance de fracasso do produto aumenta, pois quem se sente subordinado tem menos comprometimento com o resultado. Engenharia de produtos, gestão de produtos e UX são um time, não há relação de subordinação entre nenhum desses grupos. Eles devem funcionar como parceiros e sócios, cada um com sua especialidade e responsabilidade, colaborando para produzir o melhor produto possível. Inovação No diagrama anterior, a engenharia de produtos é quem traz a tecnologia disponível. Como expliquei no Capítulo 08 – Inovação: o que é inovação?, inovar não é simplesmente conhecer a última tecnologia. É preciso conhecer não só esta como também todas as tecnologias disponíveis, e saber como usá-las. Esse é o papel da engenharia de produtos. A oportunidade e o potencial de produzir uma inovação estão em conhecer as tecnologias disponíveis e saber como utilizá-las para resolver um problema, ou atender a uma necessidade de um grupo de pessoas. Dicas práticas para gestores de produto Não se meta na solução técnica, a não ser que você tenha conquistado o direito de se meter. Um gestor de produto deve ter algum conhecimento técnico sobre seu produto, mas essa não é sua área de especialidade. Os especialistas estão na equipe de engenharia de produto. Por isso, evite apresentar soluções técnicas para o time de engenharia a não ser que esse time dê abertura para isso. Para facilitar o dia a dia com o time de engenharia de produto, aqui vão algumas dicas práticas: Leve engenheiros nas conversas com clientes e usuários. Como parte do seu cotidiano como gestor de produto, você deve conversar sempre com seus clientes e usuários para entender como seu produto resolve os seus problemas ou atende às suas necessidades, e como você pode fazê-lo ficar ainda melhor. Os engenheiros gostam muito de ir a essas conversas. Para eles, é uma experiência muito bacana ver pessoas reais usando um software que eles desenvolveram. Eles ficarão ainda mais engajados na missão de fazer um produto melhor. Sempre tome decisões baseadas em dados. Quer seja dados de acesso e de uso do produto, ou dados de conversas com clientes e usuários, use dados para tomar suas decisões e apresente-os para o time. Isso dará maior consistência aos itens que você vai colocar no roadmap do seu produto. Aprenda a tirar o excesso. Busque sempre o produto mínimo ou a funcionalidade mínima, ou seja, procure implementar o mínimo possível para atingir o seu objetivo de negócio. Esteja presente. É fundamental estar junto com o time de engenharia de produto ou, pelo menos, acessível ao time o máximo de tempo possível. Durante o desenvolvimento do produto, inevitavelmente surgirão dúvidas e, se você não estiver presente, ou o time para, ou vai implementar como eles acham que deve ser, o que pode ser diferente do que você havia planejado. Dê feedback para o time sobre o produto. Você, como gestor de produto, sabe como o seu produto está indo, quantos usuários tem, o que esses usuários estão achando dele, como esse produto está ajudando a empresa a atingir seus objetivos etc. Conte periodicamente sobre isso para o time de engenharia do produto. Com isso, você estará dando um contexto e um propósito para o time. Negocie as histórias de reescrita e de manutenção. O time de engenharia, se for um time bom – antenado na evolução das boas práticas de engenharia de software e acompanhando sempre o que há de novo no desenvolvimento de sistemas –, sempre vai descobrir formas melhores de implementar cada pedaço do produto. Se depender do time de engenharia, o backlog do produto só terá histórias de melhoria técnica. Isso é bom, mostra que você está trabalhando com um ótimo time. Contudo, você deve usar o item anterior para dar o contexto do produto para o time, ou seja, mostrar que há determinados objetivos definidos para o produto, que vocês têm de atingir e que, por isso, vocês devem sempre colocar novas funcionalidades nele. Deve existir um balanço entre histórias de manutenção e reescrita e de novas funcionalidades. Já li em vários lugares algo como: defina X% do tempo para histórias de manutenção e reescrita. Eu não gosto de dar essa sugestão, pois acredito que cada momento do produto requer um equilíbrio diferente, e cabe ao gestor de produto e ao seu time de engenharia conversar e definir de comum acordo esse equilíbrio apropriado a cada fase. Vale lembrar da importância de encontrar um bom equilíbrio, pois isso evitará o famoso débito técnico que, à medida que cresce, fará com que o time de engenharia de produto fique cada vez mais lento. Alguns engenheiros de produto acabam se tornando ótimos gestores. É importante ser capaz de perceber quando um engenheiro está procurando “outra coisa pra fazer”, e dar a ele essa opção de carreira. Na Locaweb, temos (e tivemos) ótimos gestores de produto que eram engenheiros de produto. Em alguns casos, acabaram se tornando gestores do próprio produto em que era engenheiro. Por outro lado, existem alguns engenheiros de produto que experimentaram a gestão de produtos e não gostaram. Para quem está acostumado a medir sua produtividade por funcionalidades entregues, pode ser estranho no começo perder essa referência de produtividade. Como já vimos, o dia a dia de um gestor de produto é composto de muita conversa com as várias pessoas envolvidas nele, e esse monte de conversa pode “assustar” o engenheiro que está acostumado a trabalhar focado no desenvolvimento de funcionalidade. Por isso, é preciso deixar a porta aberta para ele poder voltar a ser engenheiro de produto, sem nenhum prejuízo para a sua carreira.