E chegamos no último pilar de Product Operations que é o de ferramentas e processos, para

depois entrarmos no bloco do curso de quando e como começar uma área como essa.

Então, o último pilar de ferramentas e processos é aquele pilar da máquina de produto, ou

seja, como eu torno a máquina de gerenciamento de produto mais eficiente com ferramentas e
processos. Quando eu falo máquina, estou falando da máquina de um ciclo clássico de
produto, desde a criação da visão, de descoberta, de execução, de coleta de resultados. Essa
máquina é muito informada pelos dois pilares que a gente já comentou até aqui. De fato, ela
também por si só, exige muitos rituais e muitos processos para que funcione da melhor forma
possível.

E aí, os pontos principais que esse pilar toca, são: uma escala de onboarding e
desenvolvimento de PMs, falamos de todos os rituais de produtos e templates, rituais como
de roadmap por exemplo e templates para você escalar o time de produto, de fato todo
mundo falar a mesma língua.

Ferramentas como um todo, gerenciar e implantar algumas ferramentas de produto, como um

Jira da vida, como um Figma, enfim. Você pode ajudar a influenciar nisso também, a gerenciar
esse uso da ferramenta.

E criação de processos de forma geral mais padronizada. Vou trazer um exemplo aqui para
vocês entenderem, porque processo é uma palavra bastante genérica e vocês entenderão do
que eu estou falando.
Primeiro apenas falando um pouco mais sobre a parte de rituais dentro desse pilar. Ritual ele
existe, gente, obviamente num time que vai fazer uma retrospectiva e é um ritual num nível
de squad, até rituais como o de comunicação de um roadmap, porque é um ritual que
acontece de tempos em tempos que envolve não só o time de produto todo, mas a empresa
inteira e muitas vezes o cliente também.

Então, você pensando nessas camadas desses rituais, Product Operations pretende
normalmente, influenciar muito na padronização em escala desses rituais que envolve muita
gente e, tem menos influência ou nenhuma nos squads individuais. Quando eu falo pouca ou
nenhuma influência, não é no sentido de deixar largado, é que eu nunca vou pretender tirar a
autonomia dos times, isso não faz sentido nenhum, porque as pessoas têm formas diferentes
de trabalho e tudo bem, não tem problema. É muito importante que não tiremos a autonomia,
mas que consigamos conectar talvez os squads que queiram aprender uns com os outros,
enfim, informações. Isso pode fazer parte desse pilar também, mas o que padronizamos e
escalamos é olhando mais para a direita nesse framework aqui.
E aqui estão alguns exemplos desses rituais que a gente influencia um pouco mais talvez, desde
o anual, trimestral ou mensal. Ali eu tenho nos bi-semanais, um que a gente toca, por exemplo,
que a gente criou, são os PMs Talks, casos de produto interessantes para compartilhar com
outros squads, que não necessariamente tem a ver com resultados só de produto, de OKRs,
mas pedidos de ajuda, PM Critices. Isso é interessante que podemos influenciar, porque é algo
às vezes difícil de acontecer naturalmente, mas se acontecer é ótimo.

O que é muito legal e eu vejo na VTEX é alguém teve uma ideia de fazer de repente um
PM Talk e, isso veio sim de uma PM: ‘Acho que a gente deveria ter um ritual com todos os PMs
uma vez a cada semana ou uma vez a cada duas semanas para fazer isso. Vocês ajudam a
colocar para rodar?’ É lógico! Esse é o papel de Product Operations, porque aí a PM teve a
ideia, está feliz que será executado, mas ela não teve que gerar e pensar em alinhamento de
objetivo da reunião, gerar milhões de invites, gerenciar como os tópicos da reunião serão
organizados, comunicar isso tudo, enfim. Então, fazemos esse papel, conectamos com outras
pontas e ajuda bastante naquele equilíbrio da balança, do 80/20 que eu comentei no início.
E aí em ferramentas esse pilar a gente de fato nunca impede ou controla novas ferramentas
criadas. Estamos sempre num nível das ferramentas já existentes ou que queremos usar de
forma cruzada entre global dentro do time de produto. Ajudamos a controlar acessos, os
usuários, para economizar dinheiro, respondemos por isso, usamos até ferramentas que
ajudam nesse gerenciamento como um todo, enfim, tutoriais, melhores práticas de uso das
ferramentas.

Aqui por exemplo, para o Jira, contratamos sim uma pessoa que deu treinamentos de A à Z do
Jira, na ótica da VTEX, na realidade da VTEX, temos isso gravado, para qualquer PM, Engenheiro
ou Designer aprenderem, assim que entram na VTEX, como é o uso oficial da ferramenta e qual
é o nível de automatização em liberdade que é altíssimo, enfim. Muitas pessoas nem usam o
Jira em outras empresas, então, foi importante esse tipo de setup e você pode fazer para N
ferramentas.
E alguns exemplos de iniciativa desse pilar, para cada uma daquelas bolinhas que eu trouxe, eu
vou dar destaque aqui para três delas. Então, dentro da coordenação de rituais, para o
processo de roadmap, como fazemos isso com tantos times. Dentro de ferramentas de produto
como que criamos um dashboard de estrutura de produtos e vagas, isso foi bastante
importante na escala que a gente já se encontra na empresa. E dentro daquele mundo de
processos, o processo de escala de tickets é o time de Produto.
E eu vou começar por esse último que é o processo de escala de ticket de produto que é algo
bem interessante e que fez bastante diferença depois que implementamos. Algumas dores
principais para vocês entenderem de onde vem esse processo.

Imaginando isso, deve ser quase em qualquer empresa, você deve tem atendimento ou por
Zendesk, não importa a sua forma de atendimento, e-mail, mas você tem clientes perguntando
e tirando dúvidas e anunciando certos bugs.

E o que acontecia é que você tem um primeiro nível de atendimento que é feito pelo time
de Growth, mas o time de Growth não sabe responder tudo. Então, o time de Growth precisa
escalar certas coisas ao time de Produto com uma importância e relevância muito grande,
prioridade alta, mas o que ele fazia, ele fazia em dez canais de Slack diferentes, pelo telefone,
pelo WhatsApp dos Engenheiros, das pessoas que fazem o Atendimento de Produto na ótica ao
segundo nível de atendimento.

E isso era o caos, porque o que acontecia era que essas pessoas de Atendimento de Produto
trabalhavam muito mais horas, porque elas tinham muitos canais para gerenciar além do
próprio Zendesk que seria em teoria ferramenta única e principal de trabalho. E, o pior, sem
um processo claro de escala, do tipo: ‘Pelo amor de Deus! Isso aqui é mais importante do que
todo o resto’.

Se Growth tem essa opinião e isso vinha de uma forma muito descentralizada, a gente perdia
uma informação importante e demorava mais a resolver de repente um problema de um
cliente, que impactava as vendas dele. Nos colocamos como parceiros dos clientes, na VTEX
não perdemos R$ 1,00 de vendas por causa do nosso produto, isso é muito importante. Então,
isso poderia acontecer no processo anterior com mais facilidade.

E o que criamos para vocês entenderem o tipo de coisas de automatização que eu falo, da
importância, às vezes, de um desenvolvedor no time também? Criamos um canal do Slack
usando um workflow. O Slack tem workflows para quem não conhece, que você consegue
programar em cima. Programamos e usamos até o framework da VTEX nisso, criamos um canal
único chamado Escalations, escala, onde qualquer pessoa na VTEX pode entrar e escalar
um ticket do Zendesk, para o time de Produto e isso está linkado com: temos regras de
priorização clara, ou seja, o formulário ele te conduz a postar ou não aquela informação, isso
gera alertas e todo um processo do time de Produto de atendimento, isso está linkado ao
celular de Engenheiros, se isso é necessário ter on calls, eu vou saber. Por causa desses
campos, eu vou ligar diretamente para o Engenheiro, a partir do Slack, com três chamadas, se
ninguém atende tem o plano b, plano c e o plano d. E com isso, eu consigo finalmente,
acompanhar algumas métricas.

Porque vamos combinar, ninguém quer ter esse canal, o objetivo dele é um dia não existir.
Então, criamos coisas também para eu matar no futuro, mas para matar eu preciso saber qual a
realidade que existe. E da forma descentralizada que existia antes, era impossível. Agora,
estamos com muita informação para tratar a causa-raiz de certas escalas para o time de
produto.

E falando um pouquinho mais da solução, só para mostrar, depois que você posta um pedido
de escala, marcamos exatamente as pessoas certas, tem uma thread onde elas discutem
algumas coisas. Isso tudo vai para um data base, não fica só no Slack e a gente não se perde e,
principalmente, o produto fecha com algumas razões.
Então, são essas razões que num dashboard que temos para mostrar os resultados desses
processos, aprendemos nesse graficozinho aí de barras que está muito grande, aprendemos
que 50% dos pontos que escalam o time de Produto, o time de Atendimento poderia resolver
sozinho se ele tivesse as informações certas. Não precisou de um workaround de produto, não
era um bug, não era algo que precisava de uma configuração, você rodar um script ou algo que
CX não teria capacidade de fazer.

Então, isso diz muita coisa. poderíamos treinar melhor. Agora, estamos fazendo toda uma ação
junto com o time de Educação de Atendimento na VTEX, para que reduzamos essa barrinha à
zero. Esse é o objetivo, que eu falei do canal morrer, talvez nunca morra 100%, mas da forma
como está eu gostaria que ele mudasse bastante de figura.