Este artigo é uma tradução adaptada do post Product Ops Overview, de Marty Cagan. Por ser um conteúdo riquíssimo, achamos que seria uma boa ideia traduzi-lo para ajudar a comunidade brasileira de Product Marketing a evoluir. Boa leitura!
Como a Product School diz em seu artigo de pesquisa, tentando definir o que é Product Ops: “O Product Ops opera de maneira diferente em cada empresa”. Isso pode até ser verdade, mas não é muito útil.
Da minha experiência com empresas implementando ou explorando Product Ops, encontrei nada menos do que 6 definições diferentes.
Portanto, a primeira e mais óbvia questão para pensarmos é: por que tantas definições assim?
Minha teoria é que, embora o termo tenha surgido como um conceito quase paralelo ao de DevOps, o conceito original de DevOps se refere principalmente a ferramentas e tecnologia para capacitar os engenheiros e acelerar o código para a produção. Mas não encontrei ninguém tentando fazer soluções parecidas para gerentes de produto (exceto fornecedores de ferramentas, é claro).
Acho que isso acontece, em parte, porque já existem muitas soluções prontas para as principais ferramentas, como roadmap e plataformas de OKR. Mas principalmente porque, ao contrário da engenharia, para a maioria das coisas que os PMs fazem, simplesmente não se trata de uma função das ferramentas, portanto, o significado original de DevOps não se aplica muito bem ao gerenciamento de produtos.
Assim, o conceito de capacitar gerentes de produto para fazer um bom trabalho, assim como capacitamos engenheiros, soa bem. Isso cria uma predisposição para a ideia de “Product Ops”, que é geral e elegante o suficiente para que seja tentadora para uma empresa adotá-la, com o objetivo de atender às necessidades organizacionais relacionadas ao produto.
Independentemente de saber se minha teoria está correta, a primeira coisa para entendermos é que, se uma empresa diz “temos Product Ops”, isso é uma afirmação muito vaga hoje em dia.
Mas, por favor, não me entenda mal. Como você pode imaginar, adoro o conceito de capacitar gerentes de produto e equipes de produto para ajudá-los a fazer um bom trabalho. E acho que existem maneiras muito boas de aproveitar o potencial do Product Ops para melhor capacitar gerentes e equipes.
Portanto, neste artigo, quero tentar encorajar as empresas a serem cautelosas com as definições inúteis, mas também a considerar a adoção do que eu acredito ser uma definição valiosa e útil de Product Ops.
Mas antes de compartilhar minhas observações, preciso fazer algumas ressalvas:
Primeiro, quero que você lembre que o foco do meu trabalho está nas empresas de produtos, líderes de produtos e equipes de produtos que estão tentando trabalhar como as melhores empresas. E tudo bem, porque há muitas pessoas por aí cuidando de outras coisas. Mas, como você vai ver, muitas das definições problemáticas de Product Ops são uma reação aos problemas mais profundos, especialmente os de times de features, e colocar o rótulo “Product Ops” em um modelo fundamentalmente limitado não vai resolver esses problemas.
Em segundo lugar, tem quem defenda cada uma das definições de Product Ops que descrevo. E encorajo você a ouvir todos os argumentos e tirar suas próprias conclusões.
Terceiro, apesar de tantas definições diferentes, preciso dizer que não encontrei nada que seja realmente novo. E não quero dizer “novo” como sinônimo dos últimos dois anos. Quero dizer, novo como nas últimas décadas. Pelo menos, como o praticado em empresas de ponta de produtos. Mas não pense que não há valor no Product Ops como um conceito, acredito que haja, e vou mostrar isso a seguir.
Aqui estão as várias definições que encontrei, da mais prejudicial até a mais valiosa:
O modelo de PMO reencarnado
“Em nossa empresa, o Product Ops facilita as atividades de planejamento – planejamento de longo prazo, planejamento de roadmap e planejamento de portfólio. Também ajuda na execução coordenando e rastreando as atividades em toda a organização, desde o lançamento até o fim do processo. Somos responsáveis por implementar procedimentos operacionais padronizados e governança em torno de nosso lifecycle. Somos o primeiro ponto de contado para as solicitações dos stakeholders e gerenciamos cronogramas e resultados ”.
– VP de Product Ops para uma grande empresa de dispositivos de hardware
Em muitas empresas, quando o Agile surgiu, o estilo PMO (Program Management Office) de comando e controle foi substituído. Mas elas procuram um caminho de volta há anos. Um exemplo muito claro disso é a ascensão do SAFe.
Mas a manifestação mais recente e sobre a qual escrevi no recente artigo Process People, é usar o Product Ops como um Cavalo de Tróia para trazer de volta as pessoas, as práticas e especialmente a mentalidade de comando e controle do PMO das antigas.
Estou sendo um pouco paranóico aqui? Pode ser. Mas a razão para isso não é nenhum mistério. Muitos CEOs e empresas da velha guarda querem a previsibilidade e o controle do antigo modelo de PMO – esse é um grande motivo para eles serem atraídos pela SAFe. Mas, de maneira geral, estou constantemente com receio de me tornar uma organização de mentalidade do Dia 2.
Felizmente, nem todas as pessoas PMO têm essa mentalidade problemática. Conheço vários gerentes preparados e eficientes, essenciais para produtos muito complexos – especialmente no caso de dispositivos. O comportamento problemático a que me refiro é a mentalidade de comando e controle de cima para baixo.
Espero não ter que repetir todos os motivos pelos quais não sou fã desse modelo. Tudo o que estou apontando aqui é que algumas empresas estão definindo Product Ops como as organizações da era pré-Agile costumavam definir um PMO.
O modelo de PM Two-in-a-Box
“Enquanto um gerente de produto é o dono do desenvolvimento do produto (também conhecido como a pessoa que constrói a coisa), um gerente de Product Ops lida com as tarefas diárias envolvidas com o desenvolvimento (também conhecido como a pessoa que torna mais fácil construir a coisa).”
– Product School
Eu tenho insistido nesse problema há vinte anos.
Essa questão aparece por aí de muitas formas. Por exemplo, ter um Product Manager e um Product Owner em uma mesma equipe de produto. Ou ter um gerente de produto e um analista de negócios. Ou ter um gerente de produto de Outbound e de Inbound. Ou ter um gerente de produto e um gerente de produto associado. Ou ter um Product Manager e um Product Ops Manager em cada equipe de produto.
Sei que a causa raiz desse problema é que muitos gerentes de produto sentem que têm muito trabalho a fazer e muitas responsabilidades.
Treinamento é normalmente a chave para superar essa barreira, mas combinado com o próximo problema – do gerente não estar disposto ou não ser capaz de fornecer a qualificação necessária – e as pessoas procuram dividir o trabalho para torná-lo mais gerenciável.
Mas o que essas pessoas não percebem são as consequências a longo prazo, que afetam a capacidade dos gerentes de produto de fornecerem a contribuição da que a equipe precisa. Já escrevi muitas vezes sobre as consequências negativas de dividir essa função.
Mas reconheço que preciso escrever mais sobre isso, já que muitas pessoas realmente não entendem a necessidade de assimilação contínua e prática de informações e insights fundamentais para a eficiência do gerenciamento de produto.
Agora é importante deixar claro aqui o que faz parte das responsabilidades de PMs e o que eles não fazem.
Por exemplo, na maioria das empresas de médio porte e em quase todas as grandes empresas de produtos, existem equipes de pessoas para ajudar os gerentes de produto e designers a responderem a perguntas quantitativas (por exemplo, time de analistas de dados). E pessoas para ajudar os gerentes de produto a responderem perguntas qualitativas (por exemplo, time de User Researchers). Falaremos mais sobre essas funções importantes mais para frente.
É fundamental que os PMs ainda sejam os donos dessas decisões e não as deleguem, mas essas outras equipes também têm um papel essencial no processo..
O modelo de delegação do líder de produto
“Nossa empresa conta com Product Ops para garantir que nossos gerentes de produto aprendam as habilidades necessárias, selecionem e entendam as ferramentas apropriadas, saibam quando e como executar experimentos, aprendam como interpretar e aproveitar dados e conectar os pontos entre as atividades das várias equipes de produto.”
– Diretor de Product Ops em uma grande empresa de comércio eletrônico
Líderes de gerentes de produto estão lá para permitir que estes últimos façam um bom trabalho.
No entanto, não é esse também o objetivo geral das operações de produto?
Na prática, embora as operações de produto possam ajudar quando são bem feitas (como será discutido abaixo), uma consequência ruim é o fato de os líderes de produto pensarem que podem delegar a responsabilidade de treinar gerentes de produto e de desenvolver a estratégia de produto às operações de produto.
Algo que acontece com o modelo de PM Two-in-a-Box (e, na minha opinião, a principal causa da pouca eficiência de gerentes de produto) é a situação em que os líderes de produto não estão dispostos ou não são capazes de fazer seu trabalho, especialmente quando se trata de coaching e estratégia de produto.
Empresas em que os líderes de produto gerenciam pessoas (no sentido de RH) e não podem ou não querem fornecer o treinamento necessário ou o contexto estratégico sofrem com um vácuo significativo em termos de liderança de produto.
E, em algumas organizações, espera-se que o Product Ops possa preencher esse vácuo.
O problema da liderança fraca na área de Produto não é novo.
Quando os líderes de produto não estão dispostos ou não são capazes de treinar e desenvolver seu pessoal, as pessoas procuram ajuda em outro lugar. Às vezes, em programas de treinamento interno ou externo ou em certificações. Às vezes, em programas de mentoria. Isso pode ser útil, mas nada perto de ter um gerente que assume a responsabilidade pelo desenvolvimento das habilidades e da carreira dos membros do time.
Da mesma forma, você também pode ter conhecido empresas que criaram uma equipe de estratégia de produto separada, muitas vezes composta por ex-consultores. O problema então, como agora, é que essas pessoas não estão próximas o suficiente do trabalho de descoberta em andamento (nas equipes de produto) para obter os insights necessários e impulsionar boas estratégias de produto. Em qualquer caso, o time de estratégia não é respeitado o suficiente pelas equipes de produto.
Mais uma vez, contamos com equipes de dados e insights do cliente para ajudar esses líderes de produto a fazer o trabalho, então não há expectativa de que eles mesmos façam tudo o que precisa ser feito.
No entanto, e isso é muito importante: é a assimilação contínua desses insights, combinada com as interações diárias entre as equipes de produto, que fortalece os líderes de produto e as estratégias de produto.
Mas, de forma mais geral, quando o líder não assume a responsabilidade pelas habilidades de seus gerentes de produto, então isso é descartado ou delegado. O resultado, muitas vezes, é o enfraquecimento dos gerentes de produto e, inevitavelmente, equipes fracas de produto.
No fim, não há o que substitua líderes de produto capazes e engajados, trabalhando em conjunto com seus gerentes, não apenas para entender a teoria, mas para aprender a prática e as particularidades do produto. Se esse é o problema real, é isso que precisa ser consertado.
Modelo de rebranding de Product Ops
“O trabalho de um PM não termina no lançamento… Mas, em muitos negócios, é aí que o trabalho [Product Ops] realmente começa… eles oferecem valor… garantindo que as coisas continuem funcionando sem problemas.”
– Product School
Eu sei que a frase soa muito semelhante, mas “Product Ops” tem um significado muito específico e importante em muitas empresas.
Alguns leitores vão saber imediatamente a que estou me referindo e outros não, por conta da natureza de seus produtos.
Vou dar um exemplo claro de um dos meus produtos favoritos: Guadian`s Eyewitness. Ainda mais impressionante do que o produto em si é o fato de ele ter sido feito por uma empresa com 200 anos, em apenas 7 semanas. Você pode ler a história completa aqui, mas o produto era um aplicativo de fotojornalismo para o então novo iPad e contava as notícias por meio de fotos, o que exigia coordenação diária entre um editor de fotografia, um jornalista e o editorial.
Embora a equipe de produto tenha criado ferramentas para apoiar esse processo diário, sempre há um certo nível de Product Ops em andamento (“garantindo que o produto esteja funcionando corretamente na produção”).
Não é difícil imaginar que se os problemas de operações de negócios / produtos crescerem bastante, isso pode criar uma grande demanda de tempo ao gerente de produto. Em parte, isso é bom porque o PM está motivado a investir em mais automação. Mas, em muitos casos, pode fazer sentido ter uma pessoa dedicada às operações de produção.
O problema é que essa função nunca teve um título específico, então, para mim, não foi uma surpresa encontrar algumas empresas que se apropriaram do título de “Product Ops” para isso.
E para ser claro, essa é uma função importante para muitos produtos, e se mudar o nome da função Production Operations para Product Ops ajuda essas empresas a atrair e reter pessoas fortes para a função, então, isso é compreensível.
A única desvantagem que vejo é que, com o tempo, isso provavelmente criará alguma confusão para os futuros empregadores que vão analisar a experiência de candidatos com esse título em seu currículo.
O modelo de rebranding do gerente de marketing de produto
“Em nossa empresa, o Product Ops cobre duas atividades principais: agrupar o feedback contínuo dos clientes que vêm de vendas, serviços e suporte, e coordenar atividades relacionadas ao lançamento, incluindo programas de lançamento antecipado. O Marketing de Produto inicialmente tentou fazer esse trabalho, mas não tinha largura de banda e, em muitos casos, as habilidades necessárias. ”
– Vice-presidente de Product Ops de uma empresa de software empresarial
Marketing de produto sempre foi uma tarefa difícil, mas, para muitos produtos hoje, especialmente no caso do B2B, a dificuldade cresceu tanto quanto o trabalho dos PMs.
As atividades relacionadas ao lançamento podem estar relacionadas a programas de descoberta de clientes, programas beta, vendas, serviços e treinamento de marketing; testes contínuos de lançamento de produtos no mercado. E então o feedback do cliente precisa ser incluído nesse processo e analisado pelos vários canais de vendas.
O Product Marketing convencional pode ter dificuldade em acompanhar essa demanda e atrair talentos capazes de suportar a complexidade exigida. Então, pelo menos em algumas empresas, a função foi reformulada para atrair um profissional mais técnico, para criar uma parceria com o gerente de produto.
Ainda não tenho um juízo fechado sobre esse ponto. Compreendo a necessidade disso, porque também já vi esse problema muitas vezes. Talvez seja um caso em que o rebranding seja necessário para tornar o trabalho mais atraente para o tipo certo de profissionais.
Em qualquer caso, este é um trabalho extremamente importante e, seja qual for o título, é essencial que seja bem feito.
Assim como acontece com o rebranding do Product Ops, existe um risco mínimo de que os futuros empregadores tenham dificuldade em compreender a experiência relevante dos candidatos nesse modelo. E, é claro, essa abordagem pode gerar tensão na equipe de Product Marketing.
O Modelo Multiplicador de Força
Até agora, descrevi 5 definições muito diferentes de Product Ops: 3 que considero antigos problemas ressurgindo com uma nova roupagem e 2 que são funções existentes que foram reformuladas para ajudar a torná-las mais atraentes para o talento certo.
Agora, gostaria de descrever o modelo de Product Ops que espero que as empresas considerem adotar.
Devo dizer aqui que essa definição de Product Ops é semelhante àquela de Melissa Perri, em seu livro Escaping The Build Trap, pelo menos até onde eu entendo.
Ela define 3 pilares, que podem ser apresentados dessa forma:
- Insights Quantitativos
- Insights Qualitativos
- Ferramentas e boas práticas
Equipe de Insights Quantitativos
Por mais de 20 anos, as empresas com bons produtos tiveram equipes de insights de dados (com diferentes nomes) disponíveis para ajudar os times de produtos a tomarem decisões baseadas em dados.
É essencial ter uma fonte confiável e centralizada de dados (você não quer que cada gerente de produto defina e interprete KPIs de sua própria maneira). Isso também é importante porque, muitas vezes, existem várias ferramentas necessárias para acessar as diferentes fontes de dados.
Vale dizer que essa equipe precisa ser uma equipe de capacitação. Em outras palavras, o time de insights de dados não faz a análise como um serviço. Em vez disso, as pessoas da equipe capacitam os times de produto, incluindo a criação de ferramentas de autoatendimento e o aumento do QI de dados da organização de produto.
O problema é que essa equipe muitas vezes luta para encontrar o seu lugar na organização. Eu já vi esse time localizado na área de finanças, de engenharia, de vendas ou operações de negócios, de produto e, às vezes, isolada do resto da empresa.
O motivo pelo qual gosto de aproximar essa equipe de Product Ops é garantir que todos os times de produto sempre tenham acesso direto a essas pessoas tão importantes.
Equipe de Insights Qualitativos
Empresas de bons produtos também têm equipes de insights qualitativos há várias décadas. Às vezes, o time é apenas um pequeno número de user researchers, mas mesmo sendo pequena, essa equipe pode ter um grande impacto.
Assim como acontece com o time de insights de dados, no caso da user research, não se trata de fazer a pesquisa para as equipes de produto, mas de treinar e capacitar o pessoal produto para fazer uma boa pesquisa e ter autonomia com o aprendizado, além de oferecer a infraestrutura necessária para testes contínuos com cliente.
Normalmente, o time faz parte da área de UX / Design do produto, mas também pode ser da área de Marketing ou até de outros setores da empresa. Já vi equipes com o nome de “user research/pesquisa de usuário”, “insights do cliente” ou “insights de mercado”.
Assim como acontece com o time de insights quantitativos, gosto de entender essa função como um dos pilares do Product Ops.
De uma forma ou de outra, cada equipe de produto precisa ser capaz de responder a perguntas quantitativas e qualitativas. Mas tenha em mente que os times de insights estão lá para ajudar os de produto e os líderes a tomarem decisões baseadas em dados, não para tomar essas decisões por eles.
Ferramentas e boas práticas
Essa é a parte em que, pela minha experiência, as coisas têm maior probabilidade de dar errado se você não tiver uma visão certeira quanto às pessoas que coloca nessa função. Claro que isso se aplica até certo ponto à maioria das funções, mas poucas têm a capacidade de impactar a cultura de produto da organização como essa – para melhor ou para pior.
Como mostrei no meu último artigo, muitas das minhas empresas favoritas selecionariam um dos gerentes de produto sênior mais respeitados (normalmente, os Principal Product Managers) e pediriam a essa pessoa para ajudar a otimizar as habilidades dos gerentes de produto da empresa.
Isso pode incluir o desenvolvimento de um programa de integração ou outras formas de treinamento, qualificação em técnicas avançadas de discovery, seleção de ferramentas, criação e compartilhamento de exemplos relevantes. Tudo isso para otimizar o aprendizado em áreas complexas e ajudar outros gerentes de produto ou equipes de produto.
Sempre gostei de contar com Principal Product Managers e Principal Designers para essas funções porque, em primeiro lugar, essas pessoas têm uma experiência de produto muito profunda e relevante; e segundo, isso ajuda o grupo a se tornar um multiplicador de forças.
Impulsionar essa iniciativa em Product Ops torna essa responsabilidade mais evidente, exigindo mais tempo dedicado a isso.
Quando falamos em escala, é bom ter uma ou mais pessoas experientes para liderar o onboarding e o treinamento de gerentes e designers de produto, trabalhando constantemente para otimizar as habilidades dos profissionais e garantir equipes fortes. Essas pessoas são importantes para orientar as equipes de produto em relação às melhores práticas e aos problemas mais complexos de discovery.
Um processo específico que vale a pena destacar é o planejamento trimestral. Em uma grande organização, muito precisa ser feito quanto a rastreamento, alinhamento e coordenação. Ter uma pessoa experiente ou um pequeno grupo para ajudar pode ser útil para todos os envolvidos.
Muito disso é função dos líderes de produto (eles precisam ser responsáveis pela estratégia do produto e pela definição dos objetivos da equipe).
Mais uma vez, com as pessoas erradas nessa função, as coisas podem sair do controle e o processo ganha uma dimensão exagerada. Queremos que o planejamento seja conduzido pelos líderes de produto, e não o contrário.
Outra razão pela qual gosto dos Principal Product Managers e Designers nessa função é que eles entendem que padronizar as melhores práticas parece bom na teoria. Mas, se isso não estiver aliado ao discernimento e à experiência, pode levar à imposição de uma forma única de fazer as coisas em partes da empresa em que essas práticas não fazem sentido.
Organização
Gosto de pensar nesse Modelo Multiplicador de Força como tendo uma função de Product Ops do mesmo nível da de Gerenciamento de Produto e Design de Produto.
O Product Ops existe para servir como um multiplicador de força para gerentes, designers e gerentes de marketing de produto. Você pode achar que isso é apenas mudar algumas pessoas de lugar, mas uma coisa que aprendemos em produto é que o empacotamento inteligente costuma ter um grande impacto.
Para mim, essa combinação de serviços de visão quantitativa e qualitativa, junto com a difusão das melhores práticas, traz um impacto organizacional significativo e otimiza as chances de atrair as pessoas certas para esse papel.
Vale a pena enfatizar que cada um desses 3 componentes de Product Ops representa conjuntos de habilidades muito diferentes e essenciais. O Modelo Multiplicador de Força precisa de pessoas altamente qualificadas nessas áreas, caso contrário, isso pode ter o efeito oposto: reduzir a eficácia das equipes de produto que dependem dessas pessoas.
Vejo que muitas empresas estão contratando pessoas bem jovens (às vezes, pessoas sem experiências muito amplas) e oferecendo uma posição de alto impacto na organização. Por favor, não faça isso. É o mesmo problema de quando as empresas mandam seus gerentes de produto para treinamentos feitos por pessoas que nunca colocaram a mão na massa.
Resumo
Embora eu conheça muitas empresas que há muito tempo têm os 3 pilares do Modelo Multiplicador de Força de Product Ops, ainda não conheço muitas que organizaram esses pontos em torno de algo chamado Product Ops. Mas tenho esperança de ainda ver isso.
De forma geral, esses 6 modelos que descrevi são apenas os principais que eu vi por aí (encontrei alguns outros, mas eles parecem exceções). Espero sinceramente que haja outros que ainda não encontrei. Se sua empresa implementou um conceito diferente de Product Ops, compartilhe comigo, junto de suas experiências.
Em qualquer caso, por conta da variedade de abordagens para Product Ops, espero que a gente continue vendo algumas definições até que isso se acalme e um modelo específico se torne mais relevante. Só espero que seja um modelo que represente realmente um avanço.
Agradeço especialmente a Chris Jones pela ajuda com este artigo.
Product Ops no podcast da PM3
O Mesa de Produto é o programa de podcast da PM3 repleto de discussões sobre produtos digitais e tecnologia. Nós convidamos Eduardo Magalhães, Head de Product Operations na RD Station, e Guilherme Campbell, Lead Product Manager no Nubank, para um episódio totalmente dedicado ao tema Product Ops.
Basta você apertar o play no vídeo abaixo para conferir ou acessar o podcast que também está disponível no Spotify:
Seja especialista em Produto
Aqui na PM3 nós temos como visão: tornar o mercado brasileiro de tecnologia a referência mundial em Product Management. E para fazer isso acontecer, nós levamos a nossa missão a sério: formar os melhores profissionais da área de Produto, utilizando as mais atuais práticas de Product Management por meio de casos de sucesso reais e brasileiros.
Por isso, reunimos os melhores especialistas em produto do país no nosso Curso de Product Management, para compartilhar um conhecimento linear e com cases reais do nosso mercado. Assim, você receberá uma formação no contexto em que atuamos, conhecendo mais sobre quem realmente faz acontecer hoje em produto no Brasil.
Aproveite e confira já a ementa completa do curso e veja como ele se encaixa no seu momento atual de carreira.
Confira também:
