Product Operations, ou POps como algumas pessoas tem chamado, é uma função que tem aparecido com certa frequência em times de desenvolvimento de produto, principalmente nos times razoavelmente grandes com 150 ou mais pessoas, dentre engenheiras, designers e gestoras de produto.

Definições

Quem me conhece sabe como acho importante alguns termos estarem claramente definidos, para garantir que temos o mesmo entendimento quando estamos falando desse termo. É a linguagem ubíqua, conceito criado por Eric Evans em seu livro Domain-Driven Design, que é o conjunto de termos que devem ser plenamente entendidos tanto por especialistas no domínio (usuários do sistema) como por desenvolvedores (implementadores do sistema).

Operações é um daqueles termos bem amplos e genéricos, que pode ter diferentes significados e representar diferentes responsabilidades, a depender da empresa, sua cultura e seu contexto. Contudo, nas diferentes definições que podemos encontrar no Google, encontramos como denominador comum que:

Operações é a gestão do dia-a-dia (da empresa ou de uma área) e a busca da eficiência dos processos de geração de valor dessa empresa ou área.

Muitas empresas têm diretoria de operações e até mesmo uma pessoa na alta gestão com o título de COO, Chief Operating Officer. E muitas empresas têm também áreas de operações específicas para algumas funções da empresa. Sales Ops, Marketing Ops, DevOps, Design Ops. Todas elas têm por objetivo ajudar na gestão do dia-a-dia de sua respectiva área e, consequentemente, ajudá-la a ser mais eficiente.

Antes de ser uma área, deve ser uma necessidade

Antes de pensarmos em criar uma área de operações, precisamos primeiro entender a necessidade que pode culminar na criação dessa área. Normalmente essa necessidade aparece quando a empresa começa a crescer em quantidade de pessoas. Quanto mais pessoas tem uma empresa, maiores são as chances de haver ineficiências no dia-a-dia dessa empresa.

Quando uma área de desenvolvimento de produtos (engenharia, design e gestão de produtos) é pequena, tipo 5 a 7 pessoas, tudo acontece dentro do time. O próprio time cuida de todos os aspectos do produto. Esse time tem bastante autonomia e capacidade para gerar resultados rápida e continuamente. À medida que o time cresce, costumamos dividir esse time em times menores, para manter a autonomia e a capacidade de gerar resultados rápida e constantemente. Por outro lado, essa divisão do time grande em times menores também traz dois pontos que requerem atenção:

• retrabalho: com times autônomos pode acontecer de times diferentes estarem trabalhando em temas similares, mas por estarem focados em seus objetivos, não percebem as sinergias e eventuais as oportunidades de ganho de eficiência.

• desalinhamento: por mais autônomos que sejam os times, eles trabalham dentro da mesma empresa e, muitas vezes, focados no mesmo cliente ou em clientes complementares. Por isso, por mais autônomos que sejam, o trabalho de um time vai eventualmente ser influenciado pelo trabalho dos outros times. Quando os times são muito autônomos, essa influência pode demorar para ser percebida, o que certamente vai impactar negativamente na geração de valor, normalmente devido a atrasos ou impedimentos.

Uma vez detectado o problema, pode-se pensar em soluções. Muitas vezes a solução pode ser alguém de algum time se juntar com alguém de outro time para criar uma solução para aquele problema. Uma vez criada e implementada a solução, as pessoas continuam trabalhando em seus times de origem e, se houver necessidade de alguma melhoria ou ajuste na solução, elas podem se juntar novamente para fazer esse ajuste. Caso essa necessidade de melhoria ou ajuste na solução passa a ser frequente, aí sim podemos pensar em dedicar alguém para focar continuamente nessas necessidades de melhorias e ajustes.

Para ajudar a tangibilizar esses conceitos, aqui vão alguns exemplos, de problemas de escala de time e como resolvemos esses problemas:

• Design system: os times de produto da Locaweb eram bastante independentes, uma vez que cada time cuidava de um produto específico. Tínhamos um time cuidando do produto de hospedagem de sites, outro do produto de email, outro do produto de loja virtual, outro do produto de revenda de hospedagem e assim por diante. Essa independência possibilitava inclusive que os times utilizassem linguagens de programação diferentes. Por outro lado, essa independência criava certos retrabalhos. Um desses retrabalhos que resolvemos primeiro foi o design das interfaces desses produtos. Cada produto parecia que era feito por uma empresa diferente. Foi aí que decidimos criar o Locastyle, framework front-end de comportamento e estilo, ou seja, o Design System da Locaweb. Ele foi desenvolvido como um side hustle de algumas pessoas de design e de engenharia e quando havia manutenção, ou necessidade de criar algum novo componente, essas pessoas se juntavam e fazia os ajustes necessários. Não houve necessidade de criar um time permanente para cuidar desse tema. Na Conta Azul aconteceu da mesma forma a criação do Mágica, mas depois de criado, optamos por ter uma pessoa designer sendo um time de 1 pessoa de DesignOps. Essa pessoa, além de olhar para o design system, olhava também para os processos de design, junto com o head da área. Depois de algum tempo, esse time de Design Ops cresceu para 2 pessoas, com uma UX Writer cuidando da consistência de comunicação. No Gympass, montamos um time de Design Ops com um designer e um front-end que criaram e mantinham o Yoga. Esse time depois cresceu com UX Writer cuidando o tom de voz e traduções e Research Ops para coordenar esforços de pesquisa feitos por mais de um time com o mesmo usuário. Na Lopes tb houve um esforço, exercido part-time pelas pessoas do time de design, em criar o guia de estilo de design da Lopes.

• Ferramentas: também na Locaweb enxergávamos várias oportunidades de centralizar o desenvolvimento e manutenção de algumas ferramentas. Por exemplo, todos os times precisam de autenticação e autorização em seus produtos, e vários times queriam oferecer APIs de seus produtos. Ao invés de cada time fazer sua própria autenticação e autorização e sua própria infra de APIs, fazia mais sentido criar uma centralizada. Pensando nisso criamos um time de ferramentas que tinha exatamente esse objetivo, de criar ferramentas para os times de produto serem mais produtivos. Colocamos nesse time dois de nossos desenvolvedores mais sêniores. Também criamos esse time na conta Azul, com o nome de Foundation, mas o caminho foi um pouco diferente. Uma das tribos, a que cuidava das funcionalidades de registro de venda e de emissão de NF, decidiu oferecer essas funcionalidades também como API. Então essa tribo criou a infra de API para colocar os endpoints que precisava. Essa tribo conversava com líderes técnicos das outras tribos, mostrando o que estava fazendo e colhendo feedback. Quando uma outra tribo, que cuidava das funcionalidade financeiras, decidiu também colocar sua funcionalidades acessíveis via API, começamos a pensar em montar um time para cuidar dessa infra de API, e de outras necessidades dos times de produto, de maneira centralizada, e chamamos esse time de Foundation.

• Portal de ideias: em um certo ponto os GPMs da Conta Azul começaram a trazer em nossa reunião semanal a necessidade de colher sugestões de clientes de forma mais estruturada. Ao invés de cada GPM colher essas sugestões de forma independente, decidimos fazer isso de forma mais centralizada, uma vez que o cliente era o mesmo, independente de qual parte do produto ele estivesse utilizando. Surgiu então a ideia de construir um Portal de Ideias exclusivo para clientes da Conta Azul. Nosso propósito era criar algo simples que somente clientes do Conta Azul pudessem acessar, fazer sugestões, ver, comentar e votar nas sugestões de outros clientes. A pessoa head product design decidiu tocar essa iniciativa, buscou uma solução de mercado. Com ajuda de uma pessoa designer, ajustou o layout e, com a ajuda de uma pessoa desenvolvedora, fez a integração com o sistema de autenticação de clientes da Conta Azul. Uma vez a solução implementada, a manutenção era mínima, e não precisava de ninguém dedicado. Quando havia necessidade de alguma manutenção, alguém dedicava algumas horas para essa manutenção. Imagino que em um time maior, a construção e manutenção de um portal de ideias como esse poderia ser cuidado por um time de Product Ops, ou mesmo de Design Ops. Assim como um sistema para pesquisa de NPS.

• Dados: na época da Locaweb o acesso a alguns dados era exclusividade do time de BI, que era demandado para gerar relatórios e insights e, obviamente, tinha uma fila de priorização. Para evitar essa gargalo, desde a época da Conta Azul tenho trabalhado com os times em uma cultura de democratização dos dados, ou seja, dar acesso aos dados para mais pessoas da empresa para que todos possam gerar seus relatórios e insights a partir dos dados. Na Conta Azul implementamos o Metabase como ferramenta que permite essa democratização dos dados. Lembro que quando tive acesso ao Metabase da Conta Azul pela primeira vez, passei uns 10 dias indo dormir às 3:00 da manhã, me divertindo construindo dashboards! Fizemos o mesmo no Gympass e na Lopes. A implementação dessa ferramenta, conectando-a as bases de dados da empresa e a manutenção dela, dando acesso às pessoas do time de desenvolvimento de produto e da empresa toda, ajudando as pessoas a conhecerem e a tirar melhor proveito sempre foi uma responsabilidade de um dos times estruturais que tínhamos nessas empresa, o time de dados.

• OKRs trimestrais: na Lopes nós nos organizávamos em times focados em cada um dos atores de nosso marketplace. Tínhamos time focado no cliente final, outro focado em quem está vendendo o imóvel e um terceiro focado em quem faz a intermediação, os corretores. Também tínhamos o time de marketing, com foco na geração de demanda, e o de sistemas centrais, focado nos sistemas utilizados internamente. A cada final de trimestre esses times definiam seus OKRs para o próximo trimestre. Apesar de todos os times trabalharem com o mesmo foco de ajudar as pessoas a conquistarem o seu lugar, conectando-as ao imóvel mais apropriado através do melhor corretor, cada time acabava olhando para o seu foco principal. Por isso, assim que os times terminavam de definir seus OKRs, eu fazia uma revisão e encontrava sobreposições e complementaridades, alinhava com os times sobre esses achados, e mudava os OKRs dos times para que tirássemos proveito dessas sobreposições e complementaridades. é um trabalho de alinhamento, parte do job description de uma pessoa head de produto. Estamos falando aqui de 5 times com uma média de 3 a 5 objetivos por trimestre, cada um com uns 3 a 5 key results, ou seja, uns 20 objetivos e uns 80 key results. Com certeza, com o número de times maior e, consequentemente, a quantidade de OKRs também maior, a necessidade de coordenação será maior e pode requerer alguém dedicado por mais tempo a esse alinhamento, o que pode ser uma atribuição de Product Operations.

Vale ressaltar alguns pontos importantes em relação aos exemplos acima:

• as iniciativas foram criadas e tocadas por pessoas com experiência em liderança e capacidade de enxergar o todo, ou seja, pessoas sêniores.
• outro ponto importante a destacar é que, antes de pensar em criar uma nova área, pensamos em como resolver o problema em questão com os times atuais, deslocando um pouco de esforço do dia-a-dia para resolver o problema.
• somente quando ficou claro a necessidade recorrente de manutenção e melhoria da iniciativa, pensamos em criar uma área com esse foco.
• toda nova área deve começar com uma ou, no máximo, duas pessoas.
• à medida que essa(s) pessoa(s) vai(ão) mostrando resultados, diminuindo o retrabalho dos times e ajudando no seu alinhamento, pode fazer sentido crescer a área colocando mais pessoas.
• com a evolução dessa área, pode fazer sentido uma estrutura e um mindset mais próximos dos de um time de desenvolvimento de produto, com pessoas gestora de produto, pessoas engenheiras e designers. Nesse caso, a pessoa gestora de produtos estará criando produtos produtos para resolver problemas e atender necessidades dos times de desenvolvimento de produto.

Resumindo

• Product Operations, ou POps como algumas pessoas tem chamado, é uma função que tem aparecido com certa frequência em times de desenvolvimento de produto, principalmente nos times razoavelmente grandes com 150 ou mais pessoas, dentre engenheiras, designers e gestoras de produto.
• Operações é a gestão do dia-a-dia (da empresa ou de uma área) e a busca da eficiência dos processos de geração de valor dessa empresa ou área.
• A medida que a empresa cresce, ela acaba se subdividindo em áreas e times menores para que essas áreas possam ter autonomia e a capacidade de gerar resultados rápida e constantemente.
• Essa divisão em times menores também traz dois pontos que requerem atenção, retrabalho e desalinhamento.
• A solução para esses pontos de atenção pode ser o esforço temporário de uma ou mais pessoas para criar e implementar soluções para esses problemas.
• Essas soluções podem eventualmente requerer atenção e manutenção mais constante, o que pode originar a necessidade de criação de um time (Design Ops, Tools/Foundation, Product Ops, etc.)

Nova turma do Workshop para Criação da Visão e Estratégia do seu Produto

Sem a clareza da visão e da estratégia de seu produto é muito difícil, ou mesmo impossível, gerenciar seu produto. Como decidir onde colocar seu foco e energia? O que deixar para depois? Como mostrar para os stakeholders o que você pretende fazer com o produto? Como ter argumentos para dizer não para pedidos de novas funcionalidades em seu produto?

É por isso que estou abrindo a segunda turma do meu  Wotrkshop para Criação da Visão e Estratégia de seu Produto. As vagas são muito limitadas, então garanta já a sua!

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho ajudado empresas a conectar negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter:Email

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.