Ok, antes de mergulharmos nas dicas sobre Agile Product Management, vamos primeiro dar uma olhada no que é Agile Product Management! Um Product Owner no Scrum Framework é a única pessoa responsável pelo sucesso de um Produto e por maximizar o valor desse Produto. No Scrum Framework, algumas das responsabilidades dos Product Owners são descritas como:
- Gerenciamento do Product Backlog;
- Maximizando o valor;
- Gerenciamento das partes interessadas.
Além dessas responsabilidades, a função de Product Owner também tem muito a ver com o gerenciamento de produtos! Portanto, um Product Owner é uma espécie de Agile Product Manager.
Agile Product Management
A função de Product Owner é totalmente diferente das funções tradicionais conhecidas na maioria das organizações. Algumas pessoas pensam que o Product Owner é uma espécie de ‘gerente de projeto Agile’ ou que o Product Owner é uma espécie de ‘analista de negócios’. Isso não é verdade!
O Product Owner é realmente o proprietário do Produto.
Ele ou ela é a única pessoa responsável pelo sucesso do Produto. O foco de um Product Owner, portanto, não está em ‘fazer projetos’, mas em entregar, manter e comercializar o Produto!
Nesta postagem, cobriremos 10 dicas sobre Gerenciamento Ágil de Produtos. Verifique também meus outros blogs com dicas para o Product Owner (veja os links no final desta postagem do blog).
Espero que você goste deles!
10 dicas para o Product Owner
1. Aja como um líder de produto, não como um gerente de projeto ágil
Um gerente de projeto é responsável por gerenciar o escopo, exceções, ‘recursos’ e relatórios (entre muitas outras coisas, é claro). Como Product Owner, seu trabalho não é gerenciar ‘recursos’ ou ‘tarefas’. Seu trabalho é maximizar o valor do seu produto! Para criar os recursos que entregam o máximo valor para os usuários dos produtos!
Para maximizar o valor do seu produto, você não precisa gerenciar coisas como tarefas, o que as pessoas fazem no dia a dia, qual é o andamento da equipe em um Sprint. Tudo isso pode ser gerenciado pela própria equipe.
Portanto, pare de micro gerenciar a equipe e comece a maximizar o valor do seu produto, em colaboração com usuários, clientes e stakeholders!
2. Explique aos seus stakeholders por que você está trabalhando com Agile
Agile não é um exagero, nem é algo que você ‘faz’. É uma mentalidade. É um conjunto de valores e princípios que o orientam.
O Framework Scrum é uma estrutura usada em ambientes complexos para desenvolver e manter produtos complexos. A forma de trabalhar, os valores e princípios que você deseja adotar são bastante diferentes das formas tradicionais de trabalho.
Isso também vale para a cultura e governança da organização. Stakeholders precisam ter sua maneira de pensar e comportamento também, então você precisará investir tempo (junto com seu Scrum Master ou Agile Coach) treinando seus stakeholders e explicando Agile para eles.
3. Seja um Product Owner orientado ao produto em vez de orientado ao projeto
Um projeto (em sua definição) é algo que termina. Um projeto é uma organização temporária que é criada com o objetivo de entregar um escopo específico, dentro de um determinado prazo e orçamento. Um Product Owner, entretanto, deve se concentrar em entregar um Produto. E adivinha?
O desenvolvimento do produto não termina enquanto o produto vive! Além disso, medimos o sucesso do projeto de maneiras diferentes do sucesso do produto. Um projeto normalmente é bem-sucedido quando o escopo acordado antecipadamente foi entregue no prazo e dentro do orçamento.
Um produto, entretanto, tem sucesso quando está sendo adotado, usado e valorizado pelos usuários do produto.
4. Melhore o seu tempo de aprendizagem (em vez de tempo para o mercado)
Muitas pessoas e organizações estão focadas em reduzir o ‘tempo de colocação no mercado’. Claro, isso é valioso, porque você pode entregar produtos aos seus clientes mais rapidamente.
Como Product Owner, você deseja maximizar o valor para seus clientes, portanto, entregar mais rápido e com mais frequência parece bom, certo? Claro que sim! No entanto, há um problema …
Você não pode determinar o valor antecipadamente.
O quê? Está certo!
Você não pode determinar o valor antecipadamente! Se algo é valioso ou não, é determinado por seus clientes e usuários. Com base no uso do produto e no feedback fornecido por eles, você aprenderá o que é valioso e o que não é.
Você deve apenas melhorar seu tempo de colocação no mercado, você deve se concentrar em melhorar seu tempo de aprendizagem!
O tempo de aprendizagem não significa apenas ir ao mercado, mas também inclui a coleta de feedback dos clientes e usuários.
5. Assuma a responsabilidade pelo sucesso do produto
Como Product Owner, você é responsável pelo sucesso final do produto. Eu vejo muitos POs que são responsáveis por partes de um sistema, ou que são Proprietários de Produto proxy’ que estão gerenciando o Backlog do Produto em nome de outra pessoa (que não está disponível).
6. Pare de cascatear em Sprints, comece a entregar valor para clientes e usuários
Vemos muitos Product Owners praticando Scrum dentro de um projeto. Também vejo muitos POs que estão dividindo sistemas em camadas de sistema (como Frontend, Backend, middleware, hardware etc.). Isso não o ajudará a maximizar o valor.
Por exemplo, uma arquitetura completa não contém nenhum valor para o usuário.
Uma fatia ponta a ponta de um recurso, entretanto, tem valor para o usuário! Portanto, não entregue uma camada de sistema em um Sprint, entregue um recurso de ponta a ponta!
Outro exemplo que vejo com frequência, são as equipes que criam o design em um Sprint, desenvolvem no próximo Sprint, testam no Sprint depois e finalmente entregam a um usuário no quarto Sprint.
Isso significa que você não está entregando nenhum valor para os usuários até a quarta Sprint! Tente tornar os Itens do Backlog do Produto menores, para que você possa entregar um recurso de ponta a ponta em um Sprint!
7. Entenda que mais análise não necessariamente torna o produto melhor
Muitas equipes estão acostumadas a trabalhar em projetos. Projetos são maneiras excelentes de trabalhar em ambientes complicados. Entretanto, não tanto em ambientes complexos (consulte o modelo Cynefin). Em ambientes complexos, você precisa de uma abordagem empírica, como o Scrum Framework.
Em ambientes complicados, os problemas têm uma causa e um efeito típicos. Assim, fazer mais análises iniciais resultará em uma solução melhor no final. Em ambientes complexos, os problemas podem ter múltiplas causas e múltiplos efeitos. Isso significa que a melhor abordagem é não analisar mais.
A melhor abordagem em ambientes complexos é dar um passo (agir), do que observar o que acontece (sentir) e reagir aos novos dados coletados (responder). Portanto, queridos Product Owner, aceitem que o mundo não é previsível, mas comecem a fazer mais experimentos, testes,
8. Pesquisa de mercado, vendas e marketing são parte de suas responsabilidades
Muitos Product Owners são responsáveis apenas por um sistema, ou parte de um sistema. Entretanto, isso não envolve a ideia de um Product Owner ser o proprietário real de um produto.
Um Dono do Produto empreendedor, alguém que é o responsável final pelo sucesso do Produto, também é responsável pela:
- Pesquisa de mercado;
- Vendas;
- Marketing;
- Outros.
9. Concentre-se em aumentar o valor (resultado) em vez de aumentar a velocidade (produção)
Muitos, muitos, muitos Product Owners estão focados em aumentar a velocidade de sua (s) equipe (s). Por favor, pare de fazer isso!
Medir a velocidade de uma equipe é baseado em uma técnica de estimativa relativa. Isso significa que os pontos da história são um valor relativo. É extremamente fácil para as equipes dobrarem sua velocidade e, se você pedir que façam isso, elas dobrarão sua velocidade em segundos!
Eles vão apenas dobrar ou triplicar todas as suas estimativas !!! Desta forma, não compare equipes com base na velocidade, nem foque tanto em melhorar a velocidade!
Comece a focar no valor! Meça o valor entregue pela equipe, meça o impacto de novas entregas através de indicadores de seus produtos, meça a satisfação do cliente / usuário, etc, etc.!
10. Seja um Product Owner golfinho, não um submarino!
Nossa dica final sobre o Agile Product Management é permanecer na superfície da água (como um golfinho). Um golfinho só fica submerso por um curto período de tempo e depois volta à superfície, dito de outra forma, um golfinho permanece visível.
Em ambientes complexos e no desenvolvimento de produtos complexos, você precisa obter feedback de clientes e usuários com antecedência e com frequência.
Muitos Proprietários de Produtos, no entanto, são tentados a permanecer debaixo d’água por muito tempo (como um submarino). Eles têm a ideia de que, se gastarmos ‘um pouco mais de tempo’ no Produto, podemos torná-lo ‘perfeito’ para nossos clientes e usuários.
Não faça isso!
Com certeza, isso não ajudará você a gastar mais tempo no Produto, mas o ajudará a lançar o produto com antecedência e com frequência, para entregar aos seus clientes e usuários e obter seus comentários.
Essa abordagem o ajudará muito mais a maximizar o valor do seu produto.
Referência
- https://medium.com/the-value-maximizers/10-tips-for-product-owners-on-agile-product-management-d3eb34ebf35d
