Quem já é PO (product owner) há de concordar comigo: os primeiros dias nesta cadeira em uma empresa nova são muito desafiadores. Você precisa se ambientar em uma nova organização, conhecer sua cultura e seus processos, se familiarizar com as pessoas, entender o que cada uma faz e como seu trabalho contribui para a entrega do produto e, como se já não fosse o suficiente, você precisa entender (e bem!) do negócio.

Eu passei por este momento quando entrei no JOTA em outubro de 2020 –três meses antes destas linhas serem publicadas. Neste artigo, vou mostrar como foi e está sendo minha experiência na tentativa de tornar esse início mais fácil e de me apropriar das responsabilidades do cargo.

Mas, antes, um pouco de contexto. Se, por um lado, oficialmente, a empresa nunca tinha tido uma PO antes (o papel e suas atribuições eram divididas entre várias pessoas), por outro, eu nunca tinha sido PO em uma equipe totalmente nova (no meu trabalho anterior, havia me tornado PO quando já estava familiarizada com o time). E é neste caldo de novidades para todos os lados que compartilho alguns aprendizados.

1. Conhecer as pessoas

Segundo o Guia do Scrum, o product owner é “responsável por maximizar o valor do produto resultante do trabalho do Scrum Team”. Aqui temos duas variáveis que uma PO iniciando em uma nova equipe desconhece: o produto e o time. Então, nada melhor do que começar o trabalho por uma delas. E acredito que, não coincidentemente, o primeiro dos 4 valores do Manifesto Ágil é “Indivíduos e interações mais do que processos e ferramentas”. Sendo assim, minha primeira iniciativa como product owner no JOTA foi conhecer as pessoas que trabalham comigo.

No meu processo de onboarding, tive a oportunidade de alinhar expectativas com a diretora de Produtos e, posteriormente, com a scrum master, o que já me deu uma visão do todo, de como a equipe estava dividida e quais eram seus principais processos. A partir daí, convidei algumas pessoas para conversas informais a fim de conhecê-las, saber quais as expectativas que tinham em relação ao papel de PO e quais problemas eu poderia ajudá-las a resolver. Ao meu ver isso ajudou a criar uma proximidade com a equipe.

E quando sugiro este passo como o primeiro, não é algo que deve ser feito mecanicamente, como algo protocolar. O interesse em conhecer as pessoas, suas dores e opiniões deve ser verdadeiro, caso contrário não vale a pena fazer. Aqui temos a chance de exercitar a empatia e a escuta ativa, que são soft skills tão necessárias em qualquer cargo atualmente.

2. Entender os produtos / devorar as informações

Em segundo lugar, ainda orientada pela responsabilidade do papel de PO, fui em busca de conhecer o produto. Na verdade, os produtos. O JOTA possui uma gama de produtos que é um pouco diferente do que eu tinha trabalhado até então. Como somos uma empresa que alia jornalismo e tecnologia, além das ferramentas de software –construídas baseadas em ciência de dados–, outros produtos envolvem newsletters, relatórios especiais e calls contendo informações relevantes sobre o cenário de Saúde, Tributos e dos 3 Poderes na esfera nacional.

Mergulhei em toda a informação disponível no site, nos playbooks de cada área. Testei as ferramentas, li a visão geral dos produtos e a documentação dos feedbacks de usuários. Além disso, outras três coisas me fizeram aprender bastante sobre os produtos de forma rápida:

1. Participar, quase que de forma imediata, na sprint que já estava em andamento, ajudando nas validações das entregas do jeito que eu podia;
2. Participar de entrevistas com usuários, ouvindo sobre suas rotinas e como os produtos entregam valor em suas atividades;
3. Fazer perguntas! Pode parecer um pouco óbvio, mas nem todo mundo fica à vontade ao fazer questionamentos. Não é o meu caso. As perguntas, além de permitirem que você conheça os fatos, irão fazer você interagir com o time, demonstram interesse e, mais do que tudo, podem refletir na exploração de cenários e oportunidades que quem está imerso nos problemas não consegue observar.

3. Conhecer o backlog

Depois dos dois primeiros passos, foi hora de descobrir o que havia no Backlog. Voltemos ao Guia do Scrum: “O product owner também é responsável pelo gerenciamento eficaz do Product Backlog.”

Aqui se trata de realmente começar o trabalho como PO!

O Backlog irá te mostrar o que o time pretende para o futuro dos produtos e também o que existe além disso (bugs, débitos técnicos, spikes). Vai te dar uma ideia de como o time se organiza, como escreve as histórias, quais são as padronizações. Além disso, a “inspeção” do backlog te proporciona justamente o que eu sugeri no item acima: adquirir mais conhecimento sobre o produto.

Uma das minhas primeiras tarefas foi iniciar uma limpeza do backlog dos produtos, excluindo itens que não faziam mais sentido, muito antigos, duplicados ou até mesmo já concluídos. Como alguém que tinha acabado de entrar na equipe e ainda estava encontrando seu espaço, essa etapa exigiu bastante interação com várias pessoas para entender melhor o contexto de cada issue analisada.

É preciso frisar também que a manutenção do backlog é uma tarefa contínua, pois ele é uma estrutura viva, que ilustra o roadmap e as prioridades do produto. É preciso que não só a PO, mas todo o time, entenda a importância de tudo o que está registrado ali.

4. Sugerir mudanças

Ao iniciar a limpeza do backlog, minha cabeça já começou a pensar em sugestões que pudessem melhorar o seu gerenciamento, possibilitar maior clareza aos itens e às atividades.

Acredito que essa é uma vantagem de quem está começando em um novo emprego, em uma nova equipe ou novo projeto: fresh mind. A contribuição que você pode trazer para o time é enorme, tanto no que tange à experiência em outras empresas/produtos/projetos quanto a ter uma visão “fora da caixa”, a qual permite enxergar coisas que talvez outras pessoas imersas no dia a dia não vêem ou com as quais já estão habituadas.

Algumas das minhas recomendações nesse início foram, por exemplo, a padronização da estrutura das issues de acordo com o tipo (task, bug, story) e a criação de uma “definition of ready” (DoR).

Devido ao meu perfil de analista, naturalmente questiono bastante sobre os “porquês” das coisas e também como alguém que gosta de pensar em soluções, tenho quase sempre uma sugestão. Os times de Produtos, Tecnologia e Labs (ciência de dados) do JOTA são muito abertos às mudanças e receberam bem minhas propostas, mas é interessante que você saiba analisar o perfil da sua organização e ir calibrando como e quando sugerir mudanças. E não tenha medo de fazer sugestões.

5. Estabelecer acordos

Os acordos representam uma continuidade do ponto anterior. Não basta apenas sugerir algo que você acha que é o melhor, mas saber ouvir as pessoas e entender o que funciona melhor para o time como um todo. Acredito que os acordos são o que trazem engajamento e comprometimento na real execução de uma ideia, melhoria ou plano de ação.

Quando sugeri a “definition of ready”, a fim de que tivéssemos critérios para que um item seja considerado pronto para entrar em uma sprint, apresentei minha proposta de quais pontos deveriam ser considerados e ouvi as sugestões do time para que essa definição fosse de todos e não apenas minha.

É importante que as sugestões dadas não virem uma queda de braço entre a PO e o time para medir forças, quem pode mais ou coisa do tipo. Tente não levar para o lado pessoal se o time não aceitar uma ideia. Talvez ainda não haja maturidade para uma determinada mudança, quem sabe eles já tentaram isso e não deu certo ou o trade-off não vale a pena no momento.

E lembre-se: você também deve estar aberta(o) às proposições do time. Os acordos são definições conjuntas.

Foram essas minhas dicas, a partir da experiência como PO no JOTA em pouco mais de 3 meses. É só o início e temos ainda bastante assunto pela frente!