A área de Product Operations (Product Ops, POps) vem ficando cada vez mais POp(s) (sim, eu adoro essa piadinha) no ecossistema de Produto. Cases de grandes empresas de tecnologia aqui do Brasil vem surgindo a cada dia e os resultados chamam a atenção para aquelas que ainda não possuem a área, indicando que existe uma oportunidade no ar.
Se você não faz ideia do que se trata, sugiro conferir esse artigo aqui, que vai te deixar contextualizado da importância e escopo de POps.
Temos OLX, VTEX, iFood e Unico, para citar alguns exemplos, com cases divulgados. Essas empresas são referência quando falamos de Produto e investem na área, trazendo o respaldo necessário para afirmamos que POps faz sim a diferença no desenvolvimento de seus produtos e, por consequência, nos resultados da companhia.
Como fazer Product Ops sair do 0?
“Toda empresa já faz Product Ops, mesmo que você só tenha apenas 1 PM”, essa frase escrita por Thiago Belluf, que foi líder de POps na OLX, já ajuda a acalmar os ânimos de quem não faz nem ideia de como começar a construção da área. É muito mais uma questão de colocar foco e disseminar bons cases.
Quando voltamos a essência da área, que é principalmente a criação da base e estrutura necessária para gerenciar produtos, já é um indício que o primeiro passo é priorizar a alocação de alguém com background em Produto para ter seu foco apenas em Product Ops.
1. Definir os objetivos da área dentro do contexto
Quando uma empresa decide criar uma área de Product Ops, geralmente algumas dores gerais da companhia em relação a Produto estão sendo escancaradas e sentidas principalmente pela liderança. O passo 1 é conversar com esses stakeholders e entender quais são essas dores que vão fomentar e guiar essa etapa inicial da área.
Vamos dar um exemplo no qual o CPO da empresa foi o responsável por convencer os demais líderes a importância da área. Os argumentos utilizados por ele provavelmente serão o maior guia para a definição desses objetivos, sendo alguns deles:
- Melhorar a comunicação e alinhamento do time de Produto;
- Melhorar a relação entre a área de Produto e de Negócio;
- Facilitar o acesso e consumo de dados pelas áreas de Produto.
2. Mapear as oportunidades junto das pessoas de Produto
Imaginando o cenário no qual a área de Product Ops foi criada e pelo menos uma pessoa com background de Produto está responsável por alinhar os trabalhos e os objetivos da área, o caminho mais comum é extrair das pessoas de Produto quais são suas maiores dores, mapeando tudo isso em alguma ferramenta (Miro, Google Sheets, Google Docs, etc.). Para esse passo a passo aqui eu indico uma planilha, mais pra frente vamos entender melhor o porquê.
3. Priorizar as dores
Nesse momento, você deve ter uma lista com algumas dores extraídas das pessoas de Produto, esse é o seu backlog. E, como toda Pessoa de produto que tem um backlog em mãos, o que fazemos? Priorizamos!
Agora (principalmente para quem fez o Curso de Product Management aqui da PM3) como podemos priorizar melhor? Com frameworks!
Inclusive, nesse momento estamos tratando Product Ops como um produto, percebe? Entrevistamos os usuários, entendemos suas dores e agora vamos resolver de acordo com um racional de priorização “Product Ops as a Product“.
No passo anterior, a sugestão de mapeamento foi utilizar uma planilha. Isso porque o exemplo de priorização para Product Ops proposto pela Anabela Cesário (VP de Product Operations da Outsystems de Portugal), foi utilizar um framework de pesos, baseado no objetivo alinhado no passo 1.
E como funciona esse framework que a Anabela propõe? Parecido com o RICE, para cada iniciativa é atributo uma nota e peso de impacto no objetivo, frequência que ocorre, alcance (quantos PMs impacta por exemplo) e impacto no Lifecycle do Desenvolvimento de Produto (quanto que resolver determinada dor vai melhorar a eficiência dos PMs).
Exemplo (preenchido arbitrariamente com valores de 1 a 5):
Ao final do exercício, o seu backlog estará priorizado e pronto para ser apresentado para a liderança com muito respaldo técnico de mercado e de Produto, inclusive em formato de roadmap. Isso vai facilitar as explicações de por que uma dor vai ser resolvida antes de outra, assim como deixar mais suave e resguardado aquele “não” que nós produteiros precisamos dizer em certos momentos.
Executando as primeiras tarefas
Hora da mão na massa: resolver o primeiro problema que foi priorizado, que recebeu o maior score na nota. Existem 2 estratégias sobre as quais vamos falar aqui: disseminar bons exemplos já em prática e produtizar Product Ops.
Disseminando bons exemplos
Utilizar cases dentro da própria empresa pode ser seu grande quick win nesse início. É extremamente comum que a dor de um PM seja algo já resolvido por outra squad de maneira localizada.
Digamos que a dor é sobre comunicação de releases para os times internos. Enquanto para um time isso é uma dor e traz más lembranças, pode ser que outra squad já tenha um processo definido, com cadência e bem azeitado, feito apenas por eles. Basicamente o trabalho de Ops nesses casos é documentar esse processo e disseminar pela companhia, começando pelos times que levantaram esse ponto.
Produtizando Product Ops
A segunda maneira é quando se faz necessário criar a solução do zero. Nesse caso, o trabalho de Ops é mais extenso, sendo necessário fazer o levantamento dos times envolvidos, entrevistar pessoas, desenhar a solução, implementar e testar, ou seja, é o verdadeiro processo de desenvolvimento de produto!
Por exemplo, caso a situação anterior de comunicação de releases ainda não tenha um case para ser disseminado, após um processo de Discovery, entendimento de contexto e dia a dia de ambas as áreas, a solução seria:
- Assim que a iniciativa for priorizada para desenvolvimento, o PM entrega a documentação para o time de treinamento;
- Esse time, em um SLA (acordo interno) alinhado e pré-definido, realiza o seu trabalho e retorna para o PM, liberando a release para subir (isso pode ser inclusive automatizado através de ferramentas de agilidade);
- Enquanto isso não ocorre, o deploy fica on hold.
Agora é só levantar as hipóteses de teste e acompanhar as etapas. Caso tudo dê certo, o framework é validado e pronto para ser expandido para todas as squads. Lembrando que a estratégia de tração desses processos também é importante, é o processo de GTM de Product Ops.
Product Ops é solução, e não problema!
Importante salientar que, como Product Ops, não podemos simplesmente sair mudando o dia a dia de trabalho das pessoas, burocratizando etapas e impondo responsabilidades. Se for dessa forma, além da solução provavelmente não funcionar, ocorre o risco político de “manchar” a área, taxando-a como problema e não solução.
Por exemplo, ao entrevistar as pessoas, dores citadas podem já estar sendo resolvidas de alguma maneira por outra área, uma vez que Product Ops ainda não existia. Então é importante envolver todos que possam ser adjacentes a determinada situação e mapear o contexto como um todo.
O que ajuda também é, além da área de Produto da empresa, fazer uma apresentação sobre o que é Product Ops para toda a companhia. Uma vez que a probabilidade de outras áreas fazerem parte do seu dia a dia é muito alta, essas pessoas tem que saber o porquê de vocês estarem ali.
Referências sobre o tema
Alguns conteúdos que utilizei como referência para a elaboração deste artigo, além da experiência própria:
- Anabela Cesario: “Building Product Ops From Scratch” | La Product Conf 2022 Madrid
- [Product Camp 2020] – Níveis de Maturidade em Prod Ops – Thiago Belluf – Favo
- [Product Camp 2020] – Product operations: o que é e como começar? – Marcela Schlaepfer – Vtex
Nos próximos conteúdos sobre Product Ops vamos falar sobre métricas de sucesso para área, ferramentas, montagem e estrutura dos times, diferentes escopos em diferentes empresas e muito mais!
Leia também:
