Qual a função de uma pessoa de produto ? Onde começam e terminam as responsabilidades desse papel? O que o mercado espera e o que a literatura sugere sobre a pessoa de produto/PO?

Depois de algumas buscas de job descriptions no Linkedin, consultar a definição de PO em materiais de referência e ver o que outros blogs falam sobre o assunto diria que existe um consenso geral:

“A pessoa de Produto deve entender o caso de negócio do produto, direcionar as decisões pensando nos usuários e maximizar o valor do produto definindo quais problemas devem ser resolvidos primeiro.”

Ou seja: Foco no upstream do processo e na validação da solução para o usuário final! Agora que temos um ponto de partida, vamos expandir um pouco mais essas atividades e escrever um “Job Description” da função. (Essa lista considera cerimônias do Scrum, mas pode ser utilizada por qualquer PO)

Bônus: No fim do texto coloquei umas dicas para aqueles que, assim como eu, migraram da área de desenvolvimento para os papéis de gestão)

Job Description

Definir o que fazer e a ordem de prioridade

• Entendimento das necessidades do negócio
• Desenvolver backlog de produto com foco na geração de valor para o cliente e alinhado com os objetivos estratégicos da empresa;
• Levantar e definir os requerimentos de negócios/sistemas;
• Usar fontes de dados disponíveis para criar hipóteses baseadas em dados e dores dos usuários;
• Priorizar as features e user stories com base na orientação estratégica da empresa.

Planejamento e Gestão do Backlog

• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar com o que o time vai trabalhar a seguir;
• Garantir que o Time tem um entendimento claro, compartilhado e detalhado dos itens do Backlog;
• Realizar a escrita de user stories e critérios de aceite baseados no definition of ready (DOR) e definition of Done (DOD);
• Acompanhar os indicadores de performance e qualidade do produto;
• Realizar a escrita de user stories baseados no definition of ready;
• Manter o backlog pronto para os próximos ciclos de desenvolvimento: colher informações do negócio para criar épicos e refinar os épicos em histórias de usuário;
• Preparar o Backlog para a cerimônia de planejamento (manter o backlog alimentado e refinado, evitando deixar o time em starvation);

Execução do Projeto:

• Realizar a gestão de interdependências entre projetos (alinhamento com outros POs/PMs).
• Resolver bloqueios que o time tenha por conta de dúvidas sobre regras de negócio;
• Participar como ouvinte da daily para tirar dúvidas e reportar o trabalho do upstream. (Cuidado para não transformar a daily em reunião de status);
• Participar ativamente das cerimônias de planning, refining, review e retrospectiva da Sprint.
• Conduzir/participar da execução dos testes de aceitação com usuários (UAT).
• Ponto de atenção: respeitar a autonomia do time quanto às atividades que precisam ser realizadas para a entrega.

Alinhamento de expectativas (comunicação) com partes interessadas:

• Manter contato frequente com clientes do projeto (e outros stakeholders), a fim de alinhar sobre o andamento do projeto;
• Definir em conjunto (e acompanhar) um plano de trabalho com as áreas de design, marketing e UX para concepção, manutenção e evolução do produto.

Monitoramento do resultado:

• Verificar métricas de negócio e *feedback de usuários;
• Coletar feedbacks de usuários, por meio de testes e entrevistas;
• Acompanhar KPIs e medir o resultado esperado das iniciativas de forma constante;
• Propor, implementar e validar testes rápidos a fim de validar hipóteses de negócio. Decidindo por prosseguir ou descontinuar iniciativas.
• Dar visibilidade dos resultados para stakeholders.

Então o PO deve realizar todas as tarefas dessa lista?!

Não obrigatoriamente. O guia do Scrum tem um quote interessante:

“O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos.”

Além disso considere que parte dessas tarefas pode não fazer sentido para a sua organização.

Lembre-se: Cada empresa tem uma situação única que exige o seu próprio processo. Nosso objetivo como gerente ágil é garantir que todas as atividades do processo tem um responsável e que o fluxo vai funcionar harmonicamente. Para isso não existe uma receita de bolo dizendo quais atividades a nossa pessoa de produto deve realizar exatamente.

Nesse ponto você deve ter entendido que o papel da pessoa de produto é dizer o que tem que ser feito. Não subestime a importância dessa responsabilidade. O time precisa de alguém que possa entender o negócio, a estratégia, as dores do cliente e trazer isso para eles.

O que acontece quando o PO não consegue se concentrar nas suas tarefas? + Dicas para novos PO

É normal que as pessoas de produto se percam um pouco no escopo das suas atribuições. Eu particularmente encontrei essa dificuldade em startups aceleradas e empresas pequenas onde essa pessoa, por ter um vasto contexto do negócio, acaba ajudando vários outros setores.

Seu time vai ficar sem saber o que fazer:

Sem uma noção clara do que deve ser atendido, o time de desenvolvimento pode começar a trabalhar em coisas que não são prioridade, começar a resolver problemas que não são importantes para a empresa/cliente ou simplesmente parar o trabalho por que o processo entrou em starvation (Quando não existem demandas prontas (DoR) para o desenvolvimento).

Deixe o backlog com histórias de usuário suficientes para o time de desenvolvimento trabalhar e com a priorização adequada. Se você está no início do projeto pode querer fazer um story mapping( [Vamos falar sobre Story Mapping] ) , se o story mapping já foi feito ou o seu objetivo já está bem definido você pode querer melhorar o refinamento das histórias, para isso veja: User Stories. Quebrar ou não quebrar? Eis a questão ou Melhorando o refinamento e a autonomia de times com a implementação do 7D

Não diga “Como fazer”, mas “O que fazer” e confie no seu time:

Essa é especialmente para aqueles que acabaram de migrar de desenvolvimento para cargos de gestão de produto ou processos. Codar é legal! De verdade eu ainda gosto de fazer um script de vez em quando. Mas com o tempo, vamos perdendo nosso conhecimento da arquitetura do projeto, esquecemos a maneira otimizada de resolver certos casos e até a sintaxe nos foge um pouco. É importante entender isso e abraçar esse novo papel de gestão, mantendo foco na nova especialização como Pessoa de Produo/PO. Assim você também evita que o time de desenvolvimento se sinta microgerenciado. Se sua realocação for nova e o time ainda precisa da sua opinião técnica, tente ao menos evitar fazer isso nas reuniões de refinamento e deixe que te procurem quando for necessário. Por fim, defina um nivel claro de autonomia para o time produzir sem depender de você (ou você nunca mais irá tirar férias!).

Outros setores podem começar a interagir com as demandas do time:

Não existe nada de negativo em ter o time razoavelmente acessível para debates com outros setores da sua organização. Na verdade, essa conversa tende a ser extremamente benéfica. Porém se você juntar Devs motivados, que querem codar e que estão sem um objetivo claro, com pessoas de algum outro setor que visualizam uma dor no cliente, essa combinação pode resultar em trabalho e esforço para resolver um problema que não é prioritario para a organização naquele momento. E em defesa deles, provavelmente estão fazendo isso de boa-fé acreditando que é um bom uso do seu tempo. Escute o que os outros setores e pessoas estão identificando como uma dor do cliente e inclua (ou não) isso no backlog

Lembre-se: Existe um objetivo para ser atingido, alinhe o conjunto de features necessarias para esse objetivo e o time terá um direcionamento de para onde seguir.

Priorização, Riscos e discovery podem ficar abandonadas:

Uma situação que pode ocorrer é medir de maneira errônea os impactos de riscos do projeto e priorizar erroneamente as atividades. Isso pode se traduzir em Bug Reports com prioridade errada que acabam furando a fila de desenvolvimento, ou como uma feature realmente importante que deixamos de desenvolver. Sugiro a leitura desse artigo: Tipos de Demanda e Classes de Serviço: Afinal, é tudo a mesma coisa? , principalmente a parte de cost of delay, irá ajudar a entender como a priorização afeta o projeto do ponto de vista financeiro e como pensar de maneira calculada nos riscos.

Já no quesito discovery, ajude o time a eliminar as incertezas de negócio e permita que eles resolvam incertezas técnicas. Afinal você não quer que o time trabalhe por semanas para só ao final descobrir que uma parte crítica do projeto não está disponível ou não existe tecnologia para construí-la. Sugiro a leitura desse artigo :Requisitos em equipes ágeis: Falando sobre complexidade e incerteza.

Análise de métricas do produto não ocorre:

Como a organização pode saber se o que foi entregue está de fato resolvendo as dores do cliente? Sem saber qual a aceitação dos seus usuários,podemos acabar criando os produtos errados. Não quebre o ciclo de feedback, faça bom uso das reviews, verifique como estão os OKRs e colete dados quantitativos e qualitativos do produto. Se ainda não tiver, pense neles: Dilemas de PO: como definir OKRs em equipes ágeis.

Resumindo

Se você como Pessoa de produto está conseguindo desenhar o “mapa da tesouro” para a time e ajudando eles a se manterem focados no objetivo parabéns!

Caso ainda esteja iniciando no papel ou queira saber mais sobre o Pessoas de Produto e Agilidade veja os posts sobre PO no blog da Plataformatec.

Quer conversar mais sobre o assunto, dar feedbacks ou tirar dúvidas? Fique a vontade para deixar seu comentário.

Referencias :

Guia do Scrum: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf