Como o gestor de produtos deve se relacionar com as diferentes áreas da empresa? Engenharia, UX, marketing de produtos, gestão de projetos, operações, vendas, jurídico, financeiro, atendimento, recursos humanos e administrativo.

Relembrando o que falei no capítulo Principais características de um gestor de produtos, a caraterí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 neste e nos próximos artigos!

Engenharia e gestão de produtos

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 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 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

Para facilitar o dia a dia com o time de engenharia de produto, aqui vão algumas dicas práticas:

• 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.
• 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. Como 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.

Não dá mais, precisa reescrever tudo…

Já ouvi essa frase várias vezes ao longo da minha carreira. Quem trabalha com desenvolvimento de software sabe que invariavelmente chega um momento em que aparece essa discussão que normalmente tem frases como: está cada vez mais difícil mexer no código; se fosse fazer do zero, seria muito mais rápido; se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

Na Locaweb, tínhamos o produto de Email Marketing, para envio e gerenciamento de campanhas de e-mail marketing, que usava como base de dados o MongoDB, uma base de dados não relacional conhecida por sua capacidade de armazenar grandes bases de dados. Contudo, provavelmente devido à nossa pouco experiência em desenvolvimento de software usando esse tipo de base de dados e em administrar bases de dados não relacionais, à medida que essa base crescia, o sistema ficava cada vez mais lento.

Por isso foi necessário reescrever o produto para usarmos PostgreSQL. Desenhamos essa reescrita de forma a ser transparente para os clientes. Isto é, o cliente não ia ser migrado de uma base de dados para outra, evitando assim passar por um período de indisponibilidade ou eventual perda de dados. A reescrita foi um sucesso. O processo todo de reescrita, incluindo colocar todos os clientes existentes (mais de 15.000) na nova base de dados, permitindo desligar a base de dados MongoDB, levou seis meses, um prazo razoável para uma iniciativa desse tamanho.

Entretanto, durante esses seis meses, o time não entregou nada novo para o cliente. Nenhuma nova funcionalidade. Para diminuir a frustração de nossos clientes, decidimos por contratar uma empresa terceirizada para construir aplicativos para iOS e Android em cima das APIs existentes do produto. Com isso, conseguimos entregar novas funcionalidades para nossos clientes enquanto o time de produto ficava focado na reescrita. Se essa opção não existisse, teríamos de encontrar outras formas de entregar valor para o usuário que não dependessem do time de engenharia.

Se você trabalha com desenvolvimento de software, tenha certeza de que, se ainda não passou por essa situação em sua carreira, certamente passará. O problema de reescrever software é que, ao reescrevê-lo, o time deixa de fazer coisas novas para o seu usuário, como mostrei no exemplo do produto de Email Marketing da Locaweb. Ou seja, do ponto de vista de negócio, o software não evolui, o cliente não vê evolução, e pode perder o interesse pelo seu produto passando a procurar opções melhores no mercado. Por isso gostaria de tecer algumas considerações sobre o tema:

• Tecnologias novas e melhores vão aparecer sempre. Antigamente desenvolvia-se sistemas com tudo em um código só. Depois foi o conceito de MVC (model, view, controller) separando o código do software em camadas de acordo com sua função. Mais recentemente, foi criado o conceito de microsserviços, quebrando a aplicação em aplicações pequenas, conectadas com baixo acoplamento, feito preferencialmente via APIs e facilitando a manutenção. Se a cada nova tecnologia que aparecer formos reescrever o software, certamente não faremos outra coisa senão reescrever software.
• Reescrever software tem de ter uma motivação clara de negócio, ou seja, de alguma forma deve atender aos objetivos estratégicos da empresa que é dona do software como deve atender às necessidades ou resolver um problema dos clientes. Se não houver uma motivação clara de negócio, a recomendação é não reescrever.
• Se reescrever for inevitável (tem certeza?), é importante pensar nessa iniciativa de reescrita do ponto de vista de negócios, isto é, qual é o impacto dessa reescrita para os clientes e para o dono do software. Entender isso é responsabilidade do gestor de produtos. Algumas perguntas para te ajudar a refletir junto com o time sobre esse impacto:
  • Como será essa reescrita?
  • Enquanto a reescrita estiver acontecendo, vão ser entregues novas funcionalidades?
  • Como será a coexistência do sistema novo com o sistema velho?
  • Quando forem implementadas novas funcionalidades, serão implementadas no sistema novo e no sistema velho, ou só no sistema novo?
  • Quando novos clientes poderão ser instalados no sistema novo?
  • Quando os clientes existentes serão migrados para o sistema novo?
  • Se existir a proposta de fazer um sincronizador para que os dados dos clientes existam simultaneamente no sistema velho e no sistema novo, qual é o custo dessa proposta se comparado com a opção de não fazer esse sincronizador?
  • Se a diferença entre o sistema velho e o sistema novo puder ser percebida pelos clientes, como essa diferença será comunicada?

Pronto, aí estão algumas considerações sobre reescrita de software, um tema muito importante para qualquer gestor de produto.

Ah, e tem mais um ponto!

Alguns engenheiros de produto acabam se tornando ótimos gestores. É importante ser capaz de perceber quando um engenheiro está procurando “outra coisa para 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.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis