No dilema do Product Owner que vamos discutir hoje, é bem comum sentirmos um frio na barriga quando temos um novo produto ou projeto para dar vida.
Assim como é comum a insegurança, o medo e o estresse por encontrarmos pressões para este produto ou projeto tenha resultados.
E no meio disso tudo, ainda pode surgir aquela cobrança da produtividade da execução, não é mesmo?
Esse é um cenário bem comum na profissão de um Product Owner (ou Dono do Produto) na gestão ágil de produtos e serviços.
Afinal, o Dono do Produto é um papel fundamental no sucesso do desenvolvimento de um produto ou serviço.
E por isso é comum encontrarmos profissionais, líderes e gestores com dúvidas sobre:
Na gestão de produtos e projetos, é comum encontrarmos Donos de Produtos inseguros, com medos, e estressados com o peso que esta responsabilidade pode trazer.
Dentre diversas outras questões, que vamos tratar neste artigo.
Também vamos mostrar as 3 etapas para a construção de carreira de sucesso como um(a) Product Owner.
E no final ainda vamos falar sobre o verdadeiro dilema de um Product Owner: O escalomamento.
Mas primeiro:
Para começar esta discussão, devemos ter claro que a eficácia é o objetivo a ser conquistado. Já a eficiência é parte do caminho para chegar ao objetivo.
A eficiência tem muito a ver com a produtividade, afinal, ela nos diz se estamos fazendo bem o que deveríamos fazer para chegar ao objetivo esperado.
Isso é o que define bem o conceito geral das metas ágeis com OKR também. ?
Mas a grande questão aqui é:
Como Product Owner, ou Dono do Produto, podemos garantir projetos ou processos de sucesso?
Em minhas experiências como Product Owner e Agile Coach de várias equipes lidei com o dilema de me concentrar em aumentar a produção (eficiência), e aumentar o resultado (eficácia).
Então…
Uma das definições que encontramos em um dos Scrum Guides é:
“O Dono do Produto é responsável por tirar o máximo proveito do valor do produto e do trabalho do time de desenvolvimento…. O Dono do Produto pode ser o único indivíduo encarregado de lidar com o Backlog do Produto em particular.”
Desde sua idealização como um dos papeis do framework ágil Scrum, a definição do Product Owner já recebeu diferentes e conflitantes visões.
Se você buscar na web referente ao papel do Dono do Produto, é provável que encontre definições como:
Não quer dizer que havendo um(a) PO, que a decisão seja tomada individualmente. Normalmente, esta responsabilidade é compartilhada.
A verdade é que não há uma só resposta correta aqui. Pois vai depender da dinâmica no seu local de trabalho.
Algumas empresas lidam com esta função como tática ou operacional, focada em tarefas apenas. Como se fosse apenas um líder de grupo preocupado em atender pequenas tarefas ou demandas.
Já em outras empresas, podemos encontrar Product Owners mais voltados para a estratégia.
Assim, o PO faz a ligação entre a visão da gerência do produto e o time encarregado de executar e entregar essa visão.
Entre a concepção da ideia e a execução da visão planejada para o produto, pode haver uma grande lacuna em que o PO atua para manter o produto viável e sustentável.
Nesse ambiente, o gerente de comunica a visão estratégica para o Product Owner.
Que depois disso atua junto com o desenvolvimento para garantir que eles executem essa visão corretamente.
Nesse ambiente, o gerente de comunica a visão estratégica para o Dono(a) do Produto.
Que depois disso atua junto com o desenvolvimento para garantir que eles executem essa visão corretamente.
O proprietário do produto seria responsável pela efetivação do valor de projeto ou produto.
Ou em outros termos, ele deve atuar para garantir a entrega de sucesso ao longo do desenvolvimento daquele produto/projeto.
O que isso quer dizer afinal?
Bom, pode ser muitas coisas:
De fato, o conceito de Product Owner ganhou destaque ultimamente.
Pois em várias organizações, muitas pessoas são responsáveis pelo sucesso de um determinado produto.
Vendas, Executivos, Publicidade, Design, BackOffice, etc. Áreas que normalmente estão no top da hierarquia da empresa, e, na prática, com pouco tempo para entender dos detalhes de um produto ou serviço.
Quando temos muitos grupos ou áreas responsáveis, há grandes chances do produto ficar distante das necessidades reais dos seus usuários. O Product Owner vem suprir este dilema.
Sim eu sei, na teoria não deveria ser assim. Mas a realidade pode ser cruel ?
Ao responsabilizar alguém pelo sucesso do produto/serviço ao longo prazo costuma promover maior velocidade nas decisões que podem ser tomadas.
Assim, o Dono do Produto pode ficar mais atento às modificações do mercado e das tecnologias que pode surgir!
Quando temos muitos grupos ou áreas responsáveis, há grandes chances do produto ficar distante das necessidades reais dos seus usuários. O Product Owner vem suprir este dilema.
Um dos artefatos mais importantes que o Dono do Produto deve ter certeza de que está presente é o Product Backlog.
Não que esta seja uma tarefa individual do Product Owner.
Já que vários requisitos podem vir de diferentes áreas.
Mas é uma das atribuições do PO garantir que tudo está claro para o que se espera do projeto/serviço.
De modo que todos os envolvidos no projeto saibam o que esperam deles durante o desenvolvimento do produto.
O Product Backlog é uma lista ordenada por prioridades de funções e comportamentos esperados de um produto/serviço.
É claro que esta lista precisa ser compreensível por todos os envolvidos, incluindo aqueles que não estão habituados a linguagens técnicas específicas.
Alguém aqui pode imaginar que se trata de outra lista de tarefas. Mais uma para ficarmos atolados na pressão do dia-a-dia☹
O Product Backlog na verdade trata-se de uma ferramenta de gestão visual. Uma das mais simples possível. ?
Seu principal propósito é auxiliar na identificação e clarificação dos requisitos. Necessários e esperados para o produto/serviço. Tudo para adiantar o maior valor possível esperado com o investimento realizado.
O Product Backlog constitui uma excelente ferramenta visual para a identificação e priorização de requisitos do seu projeto.
Muitos dos conhecimentos adquiridos em produtos inovadores vem do aprendizado durante a execução do produto/serviço.
Isso porque muito do que falamos até aqui tem a ver com gestão de produtos!
Porém, todos os papéis, artefatos e eventos do Product Owner não tratam do como nós devemos fazer a gestão do produto.
Na verdade, eles descrevem como as interações entre o PO e o time de desenvolvimento podem funcionar na gestão ágil de produtos e serviços.
Ou seja, o PO trata a maneira de pensar (mindset) e os valores que permitirão que você se conecte ao seu time.
De maneiras que o empirismo seja possível durante todo o avanço do projeto.
Resumidamente, podemos dizer que ele dos comportamentos e habilidades dos envolvidos, necessárias para o atingimento dos objetivos esperados daquele produto.
Na verdade, o Dono do Produto em particular não deixa de ser algo como um Gerente de Produto Ágil. Guardada as devidas proporções, claro!
Porém, mesmo que ele tenha funções e atividades associadas à Administração do Produto, o dilema que comentamos reside na estreita colaboração com todo o Grupo de Desenvolvimento.
Por isso, a grande maioria dos Donos de Produtos acabam como um tipo de supervisores de produtos.
Mas para complicar o dilema do Product Owner, nem todos os gerentes de produtos atuam como Donos do Produto. ?
O que nos leva a seguinte pergunta:
Infelizmente, o mercado mais tradicional faz do Gestor do Produto mais próximo dos processos do que dos times, prejudicando a comunicação.
Bom, se alguém considerar o Product Owner apenas como um encarregado de tarefas, ou como uma função que apenas endossa as solicitações do cliente, talvez não haja muita dúvida de que esta função poderia fazer parte das atribuições de um gerente de produto.
No entanto, um bom Product Owner promove uma atmosfera de avanço ágil capaz de estabelecer metas táticas e estratégicas para o produto/serviço.
E para isso o Dono do Produto deve ser capaz de usar de suas habilidades legítimas de gerenciamento de produto.
Isso em conjunto com outras habilidades de comunicação e de gestão de pessoas para avaliar hipóteses por exemplo.
De forma a garantir o retorno antecipado do projeto em questão.
Os métodos e frameworks ágeis permitem ao Product Owner antecipar as entregas utilizáveis, permitindo o retorno antecipado de investimentos.
A título de exemplo, o PO deve ser capaz de se conectar a diferentes departamentos.
Por consequência, ele deve possuir, ou desenvolver, habilidades auditivas excepcionais. Além de várias outras várias soft skills que facilitam o Team Building.
Claro que um gestor de produto pode ter, ou ainda desenvolver estas habilidades.
E assim atuar também como um PO.
Mas vamos ser práticos. Na realidade esse pode ser um perfil bem difícil de se encontrar disponível no mercado.
Neste caso, a organização pode precisar de um indivíduo dedicado por causa dessa função.
Dentre as principais funções e habilidades, destacamos:
Um bom Product Owner sabe que ele sempre será um profissional em formação, sempre aprendendo. Afinal, ninguém nasce sabendo de tudo, correto?
Observe que muitas das características apresentadas, tem relacionamento com a eficiência do time. Ou da sua produtividade.
Mas muitas outras tem a ver com a eficácia. Ou seja, com a conquista dos objetivos esperados pelo produto ou serviço.
Então, na realidade, não há um dilema moral entre ser eficaz ou eficiente na atuação de um PO.
Eficiência e Eficácia andam tão juntos quanto resultados e produtividade. De fato, não há um caminho certo e outro errado. Ambos são necessários!
Assim como não adianta muito sermos eficazes, ou seja, entregarmos os esperados, mas com grande desperdício na geração do resultado.
Ou ainda com atrasos, levando o produto a ficar fora do Time to Market.
O que nos leva a primeira pergunta desta situação:
Esta é a primeira etapa para a construção de uma carreira como Product Owner.
É natural que muitos Product Owners iniciem a carreira primeiro como Scrum Masters.
Entre os diversos aprendizados de um Scrum Master, está a criação de sinergia dos times de desenvolvimento do produto ou projetos.
A alta performance de um time é alcançada quando há colaboração multidisciplinar de seus integrantes.
Assim, o Scrum Master consegue dominar as ferramentas e habilidades necessárias para impulsionar o desempenho das equipes envolvidas.
Isso antes mesmo de começar a desvendar os mistérios dos produtos/serviços.
Conhecendo as técnicas de refinamento de requisitos, gestão de backlog e de riscos eu pude aumentar a performance 4 times simultâneos quando comecei a atuar como Product Owner.
Claro que isso não é em único tiro! É uma evolução, Sprint após Sprint.
A seguir vou deixar algumas recomendações para quem pretende iniciar como PO mais eficiente.
Com estas 4 etapas, já podemos observar em pouco tempo uma melhora considerável na eficácia e efetividade dos projetos e produtos.
Achou muita coisa???? Por isso é importante encontrar uma formação para Product Owners adequada.
Um bom treinamento em PO pode fazer muito por você neste sentido. ?
E ainda tem a segunda pergunta do dilema:
Esta é a segunda etapa para a efetivação da carreira de um Product Owner mais eficaz.
Depois de alguns anos em uma função tática e estratégica, eu pude aprender com gestores de produtos.
E contar com muita experiência focada em itens líderes de mercado.
E dentre as maiores conclusões que tirei é:
Do que adianta construir um sistema hidráulico em tempo recorde, e conectá-lo ao esgoto no lugar da água potável?
Ser eficiente seria como fazer uma analogia de entregar um encanamento de água.
Podemos ajudar aos times a serem eficientes e entregarem o encanamento de água para o cliente.
Da maneira mais rápida possível, com a maior vazão possível, certo?
Mas e se a água não for potável?
Pior, e se ligarem o sistema hidráulico ao esgoto ao invés da caixa da água?
Mesmo que os canos sejam limpos, não sei se o cliente ficará satisfeito em usar o mesmo sistema hidráulico? Você ficaria? ?
A analogia é simples. Mas quando falamos de objetivos, eles nem sempre são claros.
Afinal, muitos projetos são estratégicos. Sensíveis ao posicionamento do mercado.
Podem até ser críticos para a manutenção da identidade e da operação de uma organização.
Por isso elas nem sempre são verdadeiramente declaradas.
Então, para um PO evoluir verdadeiramente para a liderança estratégica de um produto, ele deve começar a ganhar a confiança.
Para assim compreender de fato o posicionamento de cada produto atendido.
E para isso, o Dono do Produto deve seguir 3 passos:
Pode ser, ou não, rs.
Vai depender da estrutura organizacional de cada empresa.
De fato, originalmente, o PO tem o papel fundamental de conectar a comunicação entre os clientes, partes interessadas, e time de desenvolvimento.
Por isso ele atua como uma ponte entre eles. Facilitando a comunicação.
E garantindo o sucesso do projeto/produto.
Então, digamos que sua empresa possui um único produto, e você tem feito todas as facilitações e definições de requisitos.
É bem provável que na prática, você seja o PO que toma decisões finais.
Mas este não é o objetivo final do Product Owner.
Todo investimento em projetos e produtos tem objetivos que geram impactos para a empresa. Em geral espera-se que sejam impactos positivos, não é?
De fato, ele facilita a comunicação e a compreensão do produto.
De modo que os requisitos atendam às necessidades de todos os objetivos daquele produto ou projeto.
Ou seja, não é bem uma decisão direta do PO. Mas a decisão surge quando ocorre a articulação do Dono do Produto, para o melhor daquele produto.
De todo modo, é necessário que o dono do produto trabalhe cuidadosamente com os membros das equipes sobre o quê e o porquê desenvolver aquele projeto.
Faça planos e crie metas definidas para cada iteração significativa do produto.
Procurando revelar o impacto do produto e do processo de desenvolvimento.
Não há uma receita que atenda a todos aqui.
Há o que melhor atende cada situação e a cada empresa.
Este é o verdadeiro dilema do Product Owner!
Eu já atuei como PM (Pro
duct Manager) e como PO. Em tempos separados em alguns projetos, e ao mesmo tempo em outros.
Alguns dos problemas que me recordo agora:
Não há nada de errado em ser um mensageiro. Só não é a função esperada de um Product Owner!
Como PO, pouco contexto era obtido em muitos dos casos.
Já como PM, nem sempre seria possível incentivar os times a resolverem seus problemas.
Agora, atuando em uma função combinada de Product Owner / Product Manager, temos algumas vantagens:
Por isso acredito que a responsabilidade do Product Owner é na verdade compartilhada com os times envolvidos.
E isso acontece quando o PO:
Assim, desenvolver uma carteira de produtos torna-se uma obrigação do grupo com o PO.
Que os direciona a fim de potencializar um time de sucesso.
Se você for o gerente de produto de uma empresa que é bastante pequena, ou ainda lida com um produto apenas, (ou possivelmente uma pequena categoria de produtos comparáveis), você pode ser capaz de cumprir os dois papéis.
Mas, uma vez que o gerenciamento de produtos tem um número muito maior de funções e responsabilidades, talvez você não tenha realmente muito tempo para ser o Product Owner ao mesmo tempo que é Product Manager.
Ou ao menos não será fácil conseguir isso de forma tão eficaz.
Se você gerencia um punhado de produtos grandes, cada um com um grupo dedicado de desenvolvedores, provavelmente não terá a capacidade de se tornar disponível a todos, não é mesmo?
Caso contrário, seria extremamente estafante! ☹
Imagine, a fim de realizar a sua parte como gerente de produto, você teria ainda que – comunicar-se com todos seus stakeholders profissionais; realizar de avaliação de mercado; participar de todas as reuniões com suas equipes de marketing, de todas as reuniões com consumidores, participar das vendas; etc.
Dependendo do tamanho da organização e da carteira de portfólios, pode ser inviável junção do papel do PO com a do PM.
O que nos traz ao que todo bom Product Owner precisa: tempo.
Para realmente trabalhar nesta função, o dono de um produto deve estar comprometido com o time de desenvolvimento.
A ponto de estar disponível em todas as Sprints.
Ou em qualquer outro momento que se fizer necessário esclarecimentos.
Isso significa participar de todas as reuniões em que o produto for o foco.
Significa estar aberto para examinar e falar sobre todas as histórias do usuário.
Também significa estar disponível em qualquer fase do desenvolvimento do projeto.
Para responder às questões que surgirem.
Como podemos observar, há alguma sobreposição entre um gerente de produto e um dono do produto.
No entanto, eles atuam como dois recursos completamente diferentes.
Podemos até encontrar algumas funções semelhantes entre o PM e o PO. Porém, na prática, ambos cumprem propósitos bem diferentes.
Conforme uma organização cresce, e seu próprio portfólio de produtos se ampliam. Assim, o Product Owner pode ter que ser uma posição dedicada.
Então, se você quer aprender mais sobre isso, ou ainda é um Product Owner, Product Manager, Scrum Master ou mesmo Agile Coach, com um ano de experiência (ou mais), te faço um convite:
O convite para explorar todas as posições, ferramentas, habilidades e competências que pertencem ao um Scrum Product Owner Certified.
Se quiser conhecer mais, clique aqui para trabalharmos no próximo nível de um Product Owner que promove Eficácia, Produtividade e Eficiência em seus produtos e serviços.
Te vejo do outro lado!
Até breve! 😉