Compartilhe esta publicação
Resumão do Papo na Arena de Agosto
Como funciona uma área de Product Ops?
E ai! Esse é mais um post da Brilliant Basics, a sua newsletter sobre tópicos de produto sem filtros. Já somos mais de 2.000 cadastrados aqui e no LinkedIn. Se você ainda não assinou, tá na hora né?
Já assinou? Que tal recomendar pra galera? 😍
Mais um Papo na Arena lotado! Estivemos no auditório do Cubo, para trocamos experiências e aprendizados sobre:
Como funciona uma área de Product Ops?
Quem participou do papo?
Eu, Arthur Castro, Founder da Product Arena e esse que vos escreve
Eduardo Magalhães, Head of Product Ops na RD Station
Mayara Barros, Sr. Product Manager no QuintoAndar
Priscila Chagas, Expert Consultant na Bain & Company
Bora pros highlights?
Product Ops em um tweet: 👩💻
Dudu (2 tweets):
“Product Ops é a área que ajuda os times de produto, eventualmente engenharia e design a serem mais produtivas, eficiente e eficaz”
“A área que empurra a companhia para bater seus gols”
Mayara:
“Product Ops alavanca e ajuda a direcionar e implementar estratégia de produto” ou “Faz tudo de produto”
Priscila:
“Uma disciplina que endereça problemas de produto para ajudar fazer acontecer”
Como vcs explicam para outras áreas o que é Product Ops?
Mayara:
“Por incrível que pareça, quando começamos existiam 2 áreas de Product Operations, que faziam coisas diferentes. Uma tava mais ajudando operações a testar mais rápido sem produto. E a minha área de ProdOps tinha chegado para ajudar e permitir o time a escalar. Mas no final das contas, parte você explica, parte você faz. Depois de um tempo, que a galera viu que tava funcionando, inclusive chegavam pra mim “posso ter um Ops no meu time também?”
Priscila:
“Quando a gente montou o capítulo lá no PicPay de produtos, a gente tinha dificuldade de explicar o que era, né, porque a gente estava lá. Todo mundo tinha suas dores e a gente estava ali pra tirar essas dores, pra tirar os impedimentos dessa turma. Inclusive na época já tinha um time `Product Operations`.
Dudu:
“Na RD tem outras áreas de Ops que são bem fortes, como Revenue Ops, Marketing Ops, CX Ops. Então foi mais fácil explicar porque era basicamente ‘Somos o Ops com recorte em Produto’. E ai o papel geral dessas áreas é: como essas áreas estão trazendo efeitos para os indicadores da companhia. E temos 3 pilares principais:
Data Analytics: tenta entender causa vs. efeito)
Governança: retorno vs. investimento)
“Enablement”: que é olhar as “habilidades” do time e ver quais coisas que as pessoas do time precisam evoluir. Baseado num score que a gente criou, a gente identifica e cria trilhas para desenvolvimento. É um investimento bem pequeno, mas que traz uma evolução gigantesca.
Cursos de Product Ops - Presencial e Online
Quer saber mais na prática sobre Product Ops? Por onde começar, princípios, desafios e muito mais? Então bora se inscrever nos cursos da Product Arena que vão rolar sobre o tema:
Presencial, em São Paulo - 02/09 (últimas 02 vagas)
Online e ao vivo - 30/09 (sábado)
Por onde começar? 🧐
Mayara:
Quando você chega num nível de complexidade do time e/ou produto, onde a pessoa de produto tá gastando mais tempo em como escalar o time, processos e afins do que em evoluir o produto, provavelmente ProductOps vai conseguir ajudar. Mas não pense que “ter uma área de prodops vai salvar seu time”, até pouco tempo atrás ninguém falava nisso.
Priscila:
Olhar um pouco os comportamentos que podem mostrar que tem espaço para uma área de Product Ops:
PM se justificando muito: “ah, preciso mandar relatório pra fulano, ciclano…”
Falta de trilha de carreira: “Não sei qual próximo passo aqui na empresa" (tem a ver com o “enablement” que o Dudu comentou, como “rampar” a equipe para ganhar senioridade?
Visão da liderança de: “Não sei se a galera tá fazendo o que eu preciso e não to com uma visão muito clara de quando e como isso vai ser entregue”.
Dudu:
Na RD Station teve uma troca de CPO, e quem assumiu a posição foi um dos fundadores da empresa. Ele tinha um pouco de dificuldade de trackear os resultados da equipe de produto. Esse foi o principal motivo. Só que a primeira tentativa, ele trouxe alguém muito bom em dados, mas que não tinha muito suporte para construir. Depois ele me contou um pouco essa dor, não sabia nada do que era Product Operations na época e me deu um desafio de ajudar a planejar a estratégia para o próximo ano. Porque os executivos falavam uma língua e a gente outra. Ai começamos por isso, foi um processo meio extenso, mas tá dando bom.
Como é/pode ser a estrutura de Product Ops?
Dudu:
Na RD Station, como Head de Product Ops, eu sou par do Head de Produtos de cada vertical.
Mayara:
No princípio, ficamos debaixo da estrutura de Produto (ProdOps respondia para Diretor de Produto que respondia para o CTO). Fui uma “euquipe” por muito tempo. Mas depois percebemos que estavamos ajudando o quarteto como um todo (produto, tech, design e dados). Continuamos parte do time de produto, mas ai passamos a ter uma diretoria de ProdOps, respondendo direto para o CTO.
Curtindo o resumão? Compartilha ai! 🤓
Qual estrutura máxima que vcs já viram?
Dudu:
Estamos perto da máxima. Temos 10 pessoas hoje na equipe, e não pretendo crescer a área muito mais que isso. Temos um benchmark que é para cada 10 pessoas x 1 pessoa de Ops.
Hoje estamos abaixo disso. O princípio é ter um time enxuto, mas bem senior. É o time mais caro, o time mais senior, mas eu não vejo a gente com mais de 15 pessoas.
Mayara:
Chegamos ter 17 pessoas, porque absorvemos design e research ops também. Mais um dos aprendizados que tive foi que definitivamente uma área de ProdOps deve começar com gente mais senior.
Cachorro que tem muito dono acaba passando fome. Como fica essa separação de responsabilidades?
Dudu:
Tamo descobrindo isso ainda hoje. Muitas vezes acabamos fazendo o trabalho do outro e não tem muito uma fronteira da onde começa e termina o trabalho de Ops. Mas, a liderança tem momentos para discutir e deixar claro quem tá apoiando e quem tá tomando a decisão. E isso é pautado também no Disagree and Commit. Ter bons acordos e comunicação constante ajuda a isso não ser um problema.
Priscila:
No começo sempre é meio complicado, ninguém sabe quem é responsa de quem. No final das contas a gente fez uma separação onde até cada área ia, e nos overlaps a gente sentava para discutir junto. Porque o que rola quando isso acontece, principalmente se não é um time senior, é que as pessoas por não saberem pra quem levantar a mão, não levantam pra ninguém, o que é muito pior.
Como saber que tá funcionando?
Dudu:
Ajudamos os PMs a melhorar “em qual alvo” eles vão tirar. Temos uma corresponsabilidade com os indicadores que os times trabalham. Quando começamos a área, era muito “entregar X análises". Ai depois partimos para uma métrica que chamamos de intervenções do produto ou liberação: quanto mais a gente tá iterando o produto, mais estamos aprendendo.
Esse conceito que tem muito a ver com o “ciclo de produto”, que já falamos algumas vezes:
Agora estamos evoluindo ainda mais: divido a responsabilidade de indicadores econômicos, tipo, reduzir o "Revenue churn de X para Y".
Hoje já tendo alguns anos da área, vemos que “entregar X análises” e deixar o time se virar, acaba sendo só uma das partes.
Mayara:
Genuinamente não acredito que existe um jeito único de fazer Product Ops. Vem muito da empresa entender a sua estrutura e cultura de produto, para ver onde tá o obstáculo, para ver onde Product ops pode ajudar. E ai ProdOps entra e consequentemente, os indicadores atrelados a isso. No início a “fundação" vai ter métricas relacionadas a entrega mesmo, não dá para querer pular lá pro final
Priscila:
Nem sempre a gente consegue avaliar diretamente o resultado. Mas uma coisa que fizemos no PicPay foi quanto conseguimos mudar os processos e ter engajamento dos profissionais e liderança.
Toda empresa precisa de uma área de Product Ops?
Arthur:
A gente sabe que todo termo da moda, a galera quer usar né? Foi assim com as squads do Spotify, Design Sprint… recentemente querem acabar com os PMs porque acharam que foi isso que o CEO do Airbnb falou… Mas pra mim, a resposta é não. Cabe a liderança identificar uma série de coisas. Se ela tá apta a conseguir criar e acompanhar os momentos/processos para ficar por dentro disso sem comprometer outras coisas, então não necessariamente vai precisar de uma área.
Mayara:
Não. Simples assim. Várias empresas que não tem e isso não significa que não estão evoluindo.
Dudu:
Não! Por exemplo, eu fui um dos 20 primeiros funcionários da DogHero, lá definitivamente a gente não precisava, até porque a informação rodava bem, por ser uma empresa enxuta. O ponto não é: "estou com um problema e preciso de uma área de product operations"
A partir do momento que começa a perder o “tracking” e você tem budget para investir nisso, pode ser que faça sentido.
Priscila:
Depende da natureza do negócio. Empresa que é nativa digital, subindo a complexidade, provavelmente uma área de ProdOps vai fazer sentido. Agora, tem um outro universo que é as que tão passando por uma transformação digital. Porque provavelmente será “mais uma área”. Então voltamos naquela pergunta básica:
Que problema queremos resolver?
Como foi “acabar” com a área de ProdOps?
Mayara:
Parte ruim:
ser uma área especialista em tempos de eficiência, é algo complicado. De forma inteligente ou não, é difícil manter.
Parte boa:
E essa parte legal é, a partir do momento que você estabeleceu processos e fundações que vivem sem você, que também é muito bom, você gerou sua contribuição, o time está melhor sem você, claro que poderia, se a área continuasse distinta, tinha outras coisas ali para fazer. Mas a sua contribuição positiva já está ali. De alguma forma a gente criou um artefato que o time consegue tocar melhor sozinho. Então que não tenha um time diretamente relacionado a isso. Assim, está aqui. A gente já elevou o patamar, a gente já criou elementos escaláveis que não precisam necessariamente de alguém o tempo todo com a mão ali. Dá pra fazer mais? Dá. Mas no momento em que a gente está escolhendo batalhas, essa batalha foi escolhida.
Top 3 aprendizados:
Arthur
Contexto, para entender como e onde atacar os problemas.
Conhecer do negócio. Pois vai ser fundamental para os trade-offs (e quanto mais contextualizado, mais conversas difíceis vão acontecer).
Disagree and commit.
Priscila:
Comunicação
Tratar as coisas como um produto (definir bem qual o problema e pra onde estamos indo?)
Querer genuinamente resolver os problemas
Mayara:
Senioridade é super importante. Isso é necessário para as discussões estratégicas que vão acontecer.
Não ser babá dos times. Se entender com a área “Enabler”, para não se envolver a ponto de você ter a responsa que deveria ser dessa outra área e por má comunicação ou excesso de “ajuda”, você acabar fazendo e sendo cobrado por isso.
Estruturar para escalar.
Dudu:
Construir boas relações. É extremamente importante porque vão rolar conversas difíceis e é um pouco do seu papel ficar “confortável” nessas conversas.
Estimular a diversidade de pensamentos. Entender os contextos
Conhecer do negócio. "Se você conhece do business, você toma melhores decisões."
Por hoje é isso. Já já a gente anuncia a data do Papo na Arena de Setembro aqui em SP!
Se você é de Porto Alegre, dia 11/09, teremos Papo na Arena ai!
Muito obrigado, e até a próxima edição da Brilliant Basics!