Product management Vs Project Management

Em 2010 ministrei vários cursos em uma empresa de Telecom que estava se aprimorando na gestão de projetos e estabelecendo um PMO.

Durante minhas aulas discutíamos as funções do gerente do produto e do gerente de projetos. Porque os dois cargos existiam na organização: o gerente de produtos era da área de marketing, e o gerente de projetos da área operacional (engenharia). A discussão girava em de como ambos poderiam coexistir de forma alinhada.   

A minha contribuição para os debates girava em torno do ciclo de vida. O ciclo de programa é muito maior do que ciclo de vida dos projetos. O ciclo do projeto, vai da demanda até a entrega do produto, digamos um celular ou um serviço de telefonia. O ciclo do produto ia desde a análise de mercado e de viabilidade, a concepção do produto, a implementação, o acompanhamento das vendas, a análise de necessidade de melhorias (novas versões ou funcionalidades) e finalmente o descarte do produto ou retirada do mercado.

No caso, os dois departamentos apresentavam conflitos e discutíamos como poderiam ser alinhados e administrados para reduzir os conflitos e aumentar a produtividade.

Ainda hoje, passados mais de 10 anos, ainda se discute os dois termos, sua pertinência e coexistência. Isso porque a gestão de produtos está cada vez mais em alta no mercado, muito motivado pela necessidade de gestão ágil dos produtos, na entrega de produtos cada vez mais cedo ao mercado, para fins de entender e melhorar o produto o mais cedo possível, o que traz vantagem competitiva e aumento de retorno de investimento.

Então, a discussão atual não é só conceitual e de divisão de tarefas, mas também de pertinência. Neste primeiro artigo, busco trazer algumas ideias para colaborar com a discussão atual.

Gestão de Produtos versus Gestão de Projetos

Um produto é um bem ou serviço que atende determinado público alvo. O produto pode ser um avião, uma joia, uma coleção de moda, um software, um edifício, um novo empreendimento, uma escola de negócios, um curso online, um site de vendas. O projeto é um conjunto de atividades, feitas por pessoas, para entregar o produto.

Portanto, o gerente de projetos tem foco em gerenciar as pessoas para desenvolver e entregar o produto. Desenvolve habilidades de gestão de conflitos, gestão de riscos, comunicação, negociação etc.

Já o gerente de produtos tem foco na aceitação e uso do produto pelos clientes e atingimento dos objetivos de negócio. O gerente de produto pode, durante o seu ciclo de vida, sugerir melhorias e novas versões, o que demandara novos projetos. Isso porque ele acompanha a aceitação do produto e as necessidades dos clientes. O gerente de produtos é mais orientado ao negócio e ao valor que os produtos trarão para a organização.

O papel de um gerente de produto é estratégico por natureza e requer pesquisa de mercado e pensamento holístico para ser bem-sucedido. Também consiste em apresentar ideias de produtos, preços e métricas de sucesso. Isso o torna semelhante ao gerenciamento de programas, que se concentra no desenvolvimento de estratégias para atingir as metas de negócios.

Por ser o proprietário do produto, um gerente de produto deve ter visão estratégica do produto, priorização e habilidades de suporte ao cliente. Eles também devem ter experiência em possuir fluxos de trabalho de marketing de produtos e atender às necessidades dos clientes.

Juntamente com essas habilidades, também é importante que o proprietário do produto seja capaz de resolver desafios como falhas de produtos e prazos apertados.

O PO (Product Owner) é o gerente de produto?

Outro termo muito utilizado atualmente é o PO (product owner), conceito introduzido pelo Scrum.

Mas o PO, normalmente, não é a mesma coisa de gerente de produto. Enquanto um gerente de produto define a direção do produto por meio de pesquisa, estabelecimento de visões, alinhamento e prioridades, o proprietário do produto deve trabalhar mais próximo da equipe de desenvolvimento para agir de acordo com as metas que o gerente de produto ajuda a estabelecer.

Mas as responsabilidades podem mudar um pouco quando a composição e as práticas da equipe também mudam. Por exemplo, se a equipe não praticava Scrum (eles praticam Kanban ou outra coisa do tipo), o gerente de produto talvez tenha que cuidar da priorização pela equipe de desenvolvimento e fazer um esforço extra para que todos estejam na mesma página. Por outro lado, se a equipe está praticando Scrum, mas não tem um gerente de produto, o proprietário do produto muitas vezes acaba adquirindo algumas das responsabilidades do gerente de produto.

A implementação errada ou a confusão destes conceitos na implementação podem trazer o risco de se mudar os títulos, mas desempenhar as tarefas no formato antigo, onde quem demanda o produto ou escreve os requisitos está distante da equipe que efetivamente desenvolve o produto.

Pessoalmente, já vi muitas “implementações” de práticas ágeis que mudavam os títulos dos profissionais, mas não resolviam os reais problemas, fazendo com que as expectativas entre quem deseja e demanda o produto ficassem desalinhadas com quem desenvolve, por falta da implementação do que é necessário, que é a proximidade destas partes. 

Então o PO é uma espécie de Gerente de Projetos?

Normalmente, não. A principal responsabilidade, ou o propósito da função de Product Owner é “maximizar o valor do Produto”. A maneira como o Product Owner maximiza o valor é continuamente fazendo escolhas sobre o que construir e o que não construir no Produto. Para isso, o Product Owner é responsável pela gestão do Product Backlog e dos stakeholders.

Alguns exemplos do que um Product Owner deve fazer incluem: ser responsável pelo sucesso ou fracasso do produto; fornecer direção unificada ao produto; Fornecer os recursos e autorizar os fundos para o produto; fornecer suporte visível e sustentado para o produto. Ele é a pessoa responsável por garantir que o produto entregue o máximo de valor possível. Pode vir a ser também responsável pelo Retorno do Investimento, Orçamento, Custo Total de Propriedade e pela definição, manutenção e compartilhamento da visão do Produto, por exemplo, quando não existir um gerente do produto com estas funções. Isto acontece notadamente em empresas pequenas ou startups.

O Product Owner também é responsável pelo Product Backlog. Isso inclui atividades como expressar claramente os Itens do Backlog do Produto, ordenar (classificar) os itens no Backlog do Produto para melhor atingir as metas e missões e garantir que o Backlog do Produto seja visível, transparente e claro para todos, além de mostrar no que o time Scrum trabalhará em seguida (backlog de sprint).

O Product Owner é responsável pela Gestão das Partes Interessadas, a fim de alinhar todos em torno da visão do produto. Isso também inclui convidar as partes interessadas (chaves) certas para a Revisão da Sprint, discutir o status atual do Backlog do Produto, próximas metas e objetivos, datas prováveis ​​de entrega e progresso feito, durante a Revisão da Sprint, bem como rastrear o trabalho total restante (no menos a cada Sprint Review) para o Produto, criando previsões e tornando essas informações transparentes para os stakeholders.

O Product Owner tem algumas atividades similares aos gerentes de projetos, mas são coisas distintas. A equipe é autogerenciável, então o PO tem foco no produto e não na gestão da equipe. O Product Owner não cria e gerencia planos de projeto, não deve acompanhar e medir o progresso da equipe, não gerencia pessoas, recursos ou a capacidade do time de Desenvolvimento.

Que tipos de papeis a empresa deve ter?

A função certa para sua equipe depende das iniciativas e metas que sua organização deseja alcançar. Enquanto um gerente de projeto ajuda os projetos a avançar, acompanha o progresso e preenche as lacunas de comunicação, um gerente de produto é necessário para criar estratégias para novos lançamentos, coordenar com as equipes de produção e desenvolvimento e inovar em seu portfólio de produtos.

Também depende do tipo de projetos que você realiza ou se o seu foco é a manutenção de poucos produtos. Na construção civil, por exemplo, é mais difícil encontrarmos equipes autogerenciáveis. Um gerente de projetos (na figura de um engenheiro ou mestre de obras_) é fundamental para que as equipes desempenhem as tarefas necessárias.

Pense em outros cenários possíveis e na melhor escolha para o caso. Por exemplo:

• Cenário 1: Sua equipe está lutando para lançar continuamente novos produtos e manter a produção em movimento com eficiência? Solução: Um gerente de produto pode criar estratégias para novas ideias de produtos e coordenar com as equipes de produção e operações para garantir que os prazos sejam cumpridos.
• Cenário 2: Sua equipe está lutando para manter os projetos dentro do cronograma e se conectar sobre as mudanças do projeto e os principais objetivos? Solução: Um gerente de projeto pode supervisionar as entregas e alocar recursos enquanto mantém sua equipe informada sobre as mudanças no plano do projeto.
• No caso de sua equipe estar lutando com ambos os problemas, adicionar um gerente de programa e um gerente de projeto à sua equipe pode resolver problemas de produto e projeto.

Quando for construir o seu plano estratégico, tanto um gerente de produto quanto um gerente de projeto podem ajudar a organizar iniciativas, conectar membros da equipe e manter sua organização avançando. A verdadeira chave é determinar suas metas mais importantes e combinar o gerente certo para esses objetivos. Pense na implementação e que tipo de profissionais necessitará para garantir melhor implementação e alcance da estratégia.

Muitos dos métodos atuais de gestão ágil baniram a terminologia gestão de projetos e usa apenas a gestão de produto, e/ou PO, como no caso do Scrum e outros. Entretanto,  o mercado ainda necessita do profissional gestor de projetos quando lida com projetos que necessita gestão de pessoas, gestão do tempo, de riscos e de alguma previsibilidade na entrega dos resultados. Mesmo que não use o título ou cargo.

Existem também algumas implementações do Gerente de Projetos Ágil, que assume funções no nível técnico e no nível corporativo. No nível técnico, serve para alocar pessoas, criar processos e aumentar a produtividade dos indivíduos dos times. No nível corporativo, pode servir para gerenciar múltiplos times ágeis e integrar o trabalho dele, bem como servir de interface para o nível estratégico com esta visão mais holística entre vários times ágeis e seus resultados.

O que importa são as atividades e o perfil que se espera. Se é necessário a gestão de pessoas para alcance de resultados dentro de prazos pré-acordados, o perfil do gerente de projetos é o adequado. Se será necessário foco em produtos, será necessário utilização do perfil do gerente de programas. Como se diz o ditado, não existe o conceito de tamanho único (one size fits all). Os papeis que você vai implementar na organização devem atender às necessidades do negócio, adicionando agilidade e valor ao seu negócio e aos clientes que utilizam os seus produtos e serviços.

Mais importante do que cargos, títulos e funções é a forma que organizamos o trabalho de forma a sermos mais ágeis, mais articulados, agregar mais valor e aprender continuamente.

Por isso tenho me dedicado aos estudos, certificações e implementações de práticas do PMI Disciplined Agile, que é um kit de ferramentas e não prega apenas uma possibilidade de uso de práticas. Mas este é outro assunto, a ser tratado em outro artigo.