Papel da pessoa PM no processo de Product Delivery

Porque nem só de Discovery vivemos

Uma vez que o Product Discovery é o principal valor que a pessoa gestora de produto entrega, e no Delivery quem mais brilha é o time de engenharia, é natural que exista muito mas material falando sobre a atuação da pessoa PM no primeiro do que no segundo.

No entanto, existe, sim, participação da pessoa Product Manager no processo de Product Delivery.

É o que eu sempre digo: PM está no passado, no presente e no futuro ao mesmo tempo. Muito mais no futuro, claro, pensando no que pode ser feito a seguir no produto que mais aproximará a empresa do resultado que ela busca naquele momento. Mas também no passado, acompanhando o desempenho de entregas que foram feitas, e no presente, dando suporte ao que está em desenvolvimento no momento e deixando tudo pronto para o lançamento.

É sobre esse último ponto que escrevo hoje.

Como a pessoa de produto pode contribuir com o time no processo de Delivery, colaborando para o sucesso do lançamento?

Trago abaixo alguns pontos que, como tudo na vida, vão depender da empresa/contexto/produto, mas que geralmente são tarefas da pessoa de produto no momento em que os cards estão passando pelo board de engenharia.

1. Handoff

Ok, o handoff não acontece exatamente durante o Delivery, mas sim, logo antes. É o pontapé inicial para que ele comece. É o momento em que PM e Product Designer fazem a passagem do que precisa ser construído para as pessoas desenvolvedoras. Na minha realidade, é um processo liderado pela minha dupla PD, mas eu sempre estou lá para dar o contexto para o time de como chegamos até aquela solução, para que a pessoa PD apresente a solução em si.

Importante citar que, se tudo deu certo no Discovery, essa não é a primeira vez que o pessoal de engenharia da squad está tendo contato com a iniciativa que foi priorizada. Idealmente, o time de desenvolvimento foi envolvido em alguma medida no Discovery, medida essa que dependerá dos riscos envolvidos na solução.

2. Apoio às regras de negócio

A depender da empresa e do time, o processo de escrever os requisitos e regras de negócio por parte da pessoa PM é mais ou menos detalhado. Pessoalmente, eu prefiro trabalhar sem precisar especificar cada detalhe da solução, simplesmente porque não é necessário. Claro que isso depende da maturidade do time e do tempo dele trabalhando com o produto, mas no geral, o time sabe como as coisas precisam funcionar. No handoff, passamos à engenharia apenas as regras de negócio mais particulares do que está sendo feito naquele momento (que diferem do padrão do produto).

No entanto, trabalhar dessa forma faz com que possam surgir mais dúvidas de negócio ao longo do desenvolvimento. E não tem problema nisso! Eu acho melhor parar 15 minutinhos para discutir uma regra de negócio sob demanda, do que ficar horas escrevendo cada regrinha mínima que possa existir na solução antes de poder passá-la para desenvolvimento.

3. Organização das fases e grupos do rollout

Caso a nova feature venha a ser liberada sob rollout (ou seja, não será liberada de uma vez para 100% da base), é papel da pessoa de produto fazer o planejamento do rollout.

Isso inclui separar em uma planilha os usuários que receberão o rollout, determinar os critérios que serão usado para separar os grupos (ex: contas internas ou externas, país da conta, plano da conta, engajamento, etc.) e organizar os usuários nos grupos de rollout. Dessa forma, assim que a solução estiver pronta, ela já pode ser liberada para o primeiro grupo de contas, sem perda de tempo organizando o cronograma de rollout com a feature já pronta.

Observação sobre o rollout: quase sempre eu começo dando o rollout para 10 contas no primeiro dia. Se, em 24 horas, não tivermos nenhum problema, eu faço vezes 10, ou seja, libero para mais 100 contas no segundo dia. E assim por diante, até ter atingido a base toda.

4. Apoio ao go-to-market e materiais de suporte

A depender do que está sendo feito, as ações de divulgação de uma melhoria ou nova feature começam a ser planejadas com maior ou menor antecedência. O roadmap é uma excelente ferramenta para que todos os times envolvidos se organizem a tempo para o momento de lançamento.

De toda forma, eu costumo comunicar o time responsável pelo marketing de produto assim que o primeiro card da feature é puxado no board de engenharia. Assim, enquanto a feature é construída, suas ações e materiais de divulgação vão sendo planejadas e finalizadas, para entrarem em ação assim que o rollout acontecer. Caso a empresa conte com materiais de suporte, também é hora de atualizá-los para contemplarem a novidade.

Dependendo da estrutura da empresa, a pessoa PM se envolverá mais ou menos nessa etapa, mas como somos as pessoas com mais informações sobre o valor que o que está sendo feito entrega para a pessoa usuária, é imprescindível que, no mínimo, ajudemos em um briefing para a divulgação.

5. Comunicação com canais internos e organização de treinamentos

Os times internos da empresa precisam ser os primeiros a saber quando alguma coisa mudou no produto, ou quando surgiu uma novidade. Não dá para a pessoa customer success ou do suporte, por exemplo, descobrir uma mudança no produto pelo cliente.

De novo, o como isso vai ser feito depende da estrutura da empresa (se tem ou não times de enablement, por exemplo). De toda forma, a pessoa PM precisa dar suporte à construção do material de treinamento, ou ela mesma dar treinamentos sobre a nova feature. Somos as pessoas que mais conhecemos o que está sendo construído, tanto do ponto de vista de dor que resolve, quanto de como funcionará a feature (as famosas regras de negócio).

6. Apoio aos testes da feature quando pronta

Adivinha? Sim, depende de como funciona cada empresa. Tem empresas que possuem pessoas de QA que lideram o processo de testes de uma nova implementação. Tem outras onde as próprias pessoas engenheiras do time fazem essa tarefa.

Ao mesmo tempo em que eu defendo que essa tarefa nunca deve ficar sob responsabilidade da pessoa PM (ou seja, não somos nós os responsáveis por averiguar a solução e garantir que ela esteja funcionando antes de ir para a mão do cliente), também defendo que sempre precisamos ser as primeiras pessoas a testarem uma nova feature ou melhoria.

Eu tenho a prática de promover testes coletivos do time, ou seja, assim que a feature está pronta, libero o rollout apenas para a conta da tribo, e crio uma planilha com cenários (caminho feliz e alternativas) para testarmos. Então todo mundo entra na planilha e pega algumas tarefas para testar, pessoas PMs, designer e engenharia.

E logo após os primeiros rollouts…

7. Atualização das métricas da tribo

Assim que a melhoria está em produção, é hora de atualizar o dashboard ou controle de métricas da tribo, para que já possamos desde o dia 1 acompanhar a adoção e performance do que foi posto no ar, e se a entrega está colaborando para os resultados da empresa conforme a tese inicial.

A partir desse controle será possível tomar decisões sobre, por exemplo, a necessidade de iteração de uma entrega —de preferência combinando com feedbacks qualitativos.

8. Entrevista de feedback com beta testers

Conforme acabei de citar, os feedbacks qualitativos ajudam muito a entender se estamos no caminho certo com determinada entrega. Quanto antes entendermos isso, mais rápido podemos agir. Por vezes, em entregas com mais waves, já é possível corrigir a rota de uma wave para a outra.

Essa coleta de feedbacks pode ser feita por meio de entrevistas síncronas, ou em formatos mais lean. Frequentemente eu puxo do banco as informações dos usuários que usaram a melhoria que foi lançada, e envio um email bem simples, perguntando como foi a experiência e pedindo feedbacks. Outro formato que gosto de usar é de pesquisa in-app, exibida após o uso da novidade, porém requer parcimônia, para que o usuário não fique vendo pesquisas pulando na tela a toda ação que realiza no produto.

Sentiu falta de alguma tarefa da pessoa PM durante o Delivery? Deixa um comentário!