Operações de produto como um facilitador

Dec 06 2022

O papel das operações de produtos tem recebido atenção crescente nos últimos anos, mas, assim como muitos papéis que trabalham para alcançar a maturidade, muita confusão e incerteza surgem. Uma das maiores dúvidas é sobre onde as operações de produtos estão dentro da organização, o que elas impulsionam/possuem e onde podem agregar valor.

O papel das operações de produtos tem recebido atenção crescente nos últimos anos, mas, assim como muitos papéis que trabalham para alcançar a maturidade, muita confusão e incerteza surgem.

Uma das maiores dúvidas é sobre onde as operações de produtos estão dentro da organização, o que elas impulsionam/possuem e onde podem agregar valor. Especialmente desafiador ao introduzir Operações de Produto em uma organização que nunca trabalhou com Operações de Produto.

Considerando a adaptabilidade do papel e função dependente da organização, poderíamos argumentar que tudo e qualquer coisa é um jogo e potencialmente dentro do nosso escopo.

É minha opinião que, se mantivermos os princípios básicos corretos, a função é facilmente adaptável a qualquer organização e o escopo fácil de definir.

Mas o que isso realmente significa?

A palavra chave é facilitador

Mesmo os especialistas têm opiniões e pontos de vista variados sobre o assunto, mas uma palavra que sempre surge é ser um facilitador ou capacitar a equipe.

Como Antonia Landi colocou de forma tão eloquente em uma atualização recente do Linkedin :
“Aprendi algo importante recentemente: não explicar o Product Ops como 'facilitando a vida das pessoas'.

Como facilitador do trabalho, é fácil querer ser útil a qualquer custo, e é uma história fácil de "vender" a novos colegas e partes interessadas. Afinal, estou aqui para facilitar sua vida, por que você não me quer por perto?”

E então resume bem sua visão final com: “Meu trabalho é permitir que as pessoas em nosso departamento façam um ótimo trabalho”.

Acho que o importante é que, ao sermos claros sobre nosso papel como facilitadores, isso nos ajuda a definir um propósito e um escopo mais claros.

Como facilitadores, seremos os Multiplicadores de Força , conforme sugerido por Marty Cagan em seu artigo , em vez de um papel de preenchimento.

Mas em termos práticos, o que isso significa e como aplicamos essa lógica ao pensar no papel e no escopo?

Habilitando não possuindo

Por mais que gostaríamos de poder apresentar uma resposta padrão sobre o escopo e a responsabilidade das Operações de Produto, não podemos porque ela precisará se adaptar, dependendo de vários fatores:

As necessidades específicas da organização
Onde as operações do produto ficam dentro da organização
A maturidade da organização do produto

Quando habilitamos, desbloqueamos oportunidades. Ajudamos a conectar pessoas para construir os relacionamentos certos. Criamos as infraestruturas para apoiar a equipa em vez de forçar a equipa.

Vejamos o exemplo prático de feedback do cliente. Quer a empresa tenha pesquisa, sucesso do cliente, vendas, operações com o cliente ou nenhuma das opções acima, entendemos que o feedback do cliente é uma parte importante do processo de desenvolvimento do produto.

O desafio é que o feedback do cliente vem de várias fontes e cada um quer ter certeza de que o feedback do cliente está chegando às pessoas certas para tomar as decisões certas.

Neste ponto, as operações de produto podem facilmente ver como sua responsabilidade lubrificar a máquina e garantir que isso esteja acontecendo.

A verdade é que existem várias formas de abordar a situação, dependendo dos fatores mencionados acima.

Como podemos fazer isso funcionar sem pisar no calo de ninguém?

Como regra geral, eu pessoalmente sugiro a seguinte abordagem incremental.

Etapa 1: comece conectando os pontos

O primeiro passo é identificar as principais pessoas, departamentos e informações para se conectar.

Quem é dono do quê?
Quem nos ajudará a levar as coisas adiante?
Quem precisa consumir a informação e como?
Quem pode fornecer as informações e como?

Às vezes, somos capazes de descobrir soluções já existentes e trazê-las à tona. Se esses sistemas e práticas de apoio estiverem funcionando bem o suficiente, poderemos recuar sem muita intervenção.

Em outros casos, podemos perceber que há muitos elos perdidos entre as soluções existentes e precisaremos fornecer mais suporte para mitigar essas deficiências.

Potencialmente podemos chegar à conclusão de que não há infraestrutura real e precisaremos ser ainda mais ativos do que as duas versões anteriores. No entanto, e isso é importante, isso não significa que precisamos assumir a governança. Pode ser um indicador precoce, mas ainda não escrito em pedra.

Etapa 2: dar suporte à infraestrutura

Em todas as três instâncias apresentadas na etapa anterior, precisaremos agora fornecer algum suporte, mas isso varia muito para cada uma.

No primeiro caso, trata-se de suportar essa conectividade até que ela seja capaz de se sustentar. Não como proprietários, mas como facilitadores ou conectores.

O segundo caso apresenta um pouco mais de complexidade, onde precisamos dar suporte à conectividade, mas também precisamos ajudar na definição dos modelos de funcionamento das peças que faltam. Nesse caso, se somos os proprietários do trabalho ou apenas o suporte dependerá de termos proprietários existentes que façam mais sentido do que nós.

No caso final, precisamos ter uma parte mais ativa e às vezes precisamos ser os pilotos. Aqui somos os donos pelo menos durante o processo de ideação, definição e lançamento. Mas não necessariamente proprietários a longo prazo.

Passo 3: Possuir apenas o que faz sentido, quando faz sentido

É aqui que precisamos ser realmente rigorosos sobre se assumimos a propriedade de algo ou recuamos e deixamos que as próprias equipes assumam a propriedade.

No primeiro caso é mais fácil, porque eles já têm a infraestrutura existente para serem donos de tudo. Ajudamos a desbloquear a eficiência nesses modelos de relacionamento e trabalho. É isso.

No segundo caso, precisamos ter certeza de quem deve ser o dono da solução. O Product Ops pode possuí-lo temporariamente até que a equipe ou infraestrutura necessária exista. No exemplo do feedback do cliente, se houver uma equipe de sucesso do cliente ou operações do cliente, faz muito mais sentido que eles sejam os donos. Mantê-lo em Operações não faria sentido a longo prazo e “lutar” por ele seria um esforço perdido.

Em última instância, semelhante à opção anterior, precisamos deixar claro se a solução está dentro do escopo de operações do produto a longo prazo. Se fizer sentido, o Ops deve possuí-lo e evoluí-lo.

Se, no entanto, não estiver no escopo definido para as operações do produto, devemos estar preparados para deixá-lo ir assim que estiver pronto.

Devemos ficar felizes em passá-lo para os proprietários que fazem mais sentido. Devemos apoiá-los na tomada de posse. O sucesso deles faz parte do nosso sucesso e de não deixar nosso “bebê” de lado.

Essa é uma parte importante de ser o facilitador. Queremos apoiar as equipes nos desafios complexos e, em seguida, ajudá-las a se preparar para assumir essas soluções no futuro.

Pensamentos finais

Provavelmente, uma das coisas mais difíceis de assumir uma função de Operações de Produto é saber que você estará trabalhando em muitas coisas que potencialmente não possuirá no futuro.

Trata-se de investir nosso tempo e esforços para produzir nosso melhor trabalho e, às vezes, entregá-lo a outros.

A recompensa está em ver como os outros se beneficiam da sua intervenção e como eles próprios amadurecem e evoluem graças ao seu apoio e coaching.

Ao ter uma abordagem incremental, podemos entender melhor nosso nível de intervenção e evitar usar muitos chapéus ou assumir mais do que podemos mastigar.

Em última análise, queremos desbloquear os superpoderes da organização do produto. Ao querer possuir tudo, poderíamos potencialmente mostrar um grande impacto inicialmente, mas, a longo prazo, nos tornaríamos bloqueadores da inovação e evolução da organização.