Vamos ao segundo pilar!

Agora recapitulando, eu falei de voz do cliente, falei de três exemplos

e os objetivos deste pilar. Agora vamos falar daquele pilar que são de dados mais quantitativos,
dados do produto.
Alguns exemplos trazendo aqui do que estamos falando, quando eu falo dados de produto é:
são dados da jornada do cliente, normalmente mais quantitativo já num dashboard, algo
bastante fácil de consumir.

Dados de performance do produto variam de empresa para empresa, você tem que descobrir o
que é performance para o seu produto e para você. Dados de uso também, essa mesma linha,
mas: Ah! Usuários ativos. O que é usuário ativo? Profundidade de uso, enfim, esse tipo de
coisa.

E dados financeiros, normalmente dados financeiros em algumas empresas é até uma das
últimas coisas a você conseguir unificar, mas é muito interessante quando o time de produto
acompanha, de fato, lucros, P&L do seu produto e consegue ser informado por o quanto o
produto está gerando de vendas, de lucro. Se for o objetivo do seu produto, sabemos que tem
de tudo.

E aí, normalmente esse é o pilar mais maduro, independente da área de Product Operations.
As empresas que já nascem nessa era de dados, já nascem com pessoas que vão criar bancos
de dados muito bem feitos, que você vai conseguir saber quem é aquele cliente, quem é
aquele usuário que está consumindo a,b,c. Por mais que não esteja tudo integrado, você já tem
isso registrado. Em muitos outros casos você talvez não tenha isso e o que acontece na maioria
das empresas é que você terá várias áreas em linhas de dados, evoluindo localmente.

A área de Product Operations é a área que em algum momento ou, uma área de dados e, aí
chame do que quiser, normalmente existe um momento em que você precisa de alguém
olhando todo o framework de dados. Então, vai usar qual camada para banco de dados, qual
camada para data analytics, para qual camada? Então, isso tem muitas aulas por aí, com
certeza. As outras aulas citam sobre dados, mas o que estou dizendo aqui é
que Product Operations numa empresa que não tem uma área de dados tão formalizada assim,
ela serve para fazer essa unificação e para gerar insights em cima disso. Não paramos só na
parte de dashboards disponibilizados ao time, trabalhamos ali de fato também em
alguns insights.

E como eu falei, é uma baixa prioridade esse pilar na maioria das empresas, quando você já
tem essas informações, mas a VTEX esse não era o caso, não tínhamos nem as áreas
segmentadas, com dados muito organizados. Então, foi muito importante ter um impulso de
uma área buscando essas informações, principalmente em um dos casos que trarei aqui que
são dados de uso do produto. Então, não tínhamos essas informações e não é algo tão simples
de ter da noite para o dia, quando você já tem uma estrada muito longa, muitos clientes
usando, então isso é um desafiozinho e isso é importante.

Trazendo alguns exemplos desse pilar, a implementação do Amplitude é o que eu vou trazer de
exemplo junto com dashboard de eficiência do time de produto, mas enfim, tem outros
exemplos também para vocês pensarem sobre essa área, dentro daquelas bolinhas que eu
trouxe com o exemplo de dados.
Bom, exemplo do Amplitude que é a implantação na verdade, Amplitude é você conseguir
implementar uma ferramenta que te dê análise de uso do seu produto pelos seus usuários.
Quais áreas os usuários estão acessando, quando, quantas vezes? Quais features são mais ou
menos utilizadas? Qual é o caminho? E por aí vai.
E como fizemos a solução? A solução vem primeiro de uma escolha obviamente de ferramenta,
avaliamos várias. Abrindo aqui, ficamos até entre o Amplitude e o Mixpanel, descartamos o
Pendo na época e ficamos na dúvida se implantava também o Segment ou não. O Segment é
uma ferramenta muito poderosa para ajudar a escalar dados de uso do produto, mas é uma
implantação um pouco mais longa e queríamos essas informações muito rápidas. Então,
começamos somente com o Amplitude e depois a ideia era expandir incluindo o Segment
também.

E uma vez que você decide a sua ferramenta é muito difícil você sair do zero para o cem,
depois de uma empresa rodando, como eu falei. Inclusive, em qualquer quase projeto
de Product Operations, você vai escolher um grupo seleto de squads e de PMs, ou Engenheiros,
ou Designers interessados em trabalhar naquilo para gerar o case, para depois expandir.

A primeira fizemos primeiro com dois squads escolhidos, definimos quais seriam os dados,
as tags e fizemos junto com eles esse setup. E aí não é só: ‘Ah! Eu fiz aqui, como colocar no
seu squad’, a área de dados tem um papel muito importante nesse tipo de implantação que é
você ter todo o dicionário do que é um conhecimento único, do que é um usuário ativo. Esse
tipo de informação: ‘o que é uma ação do tipo a, b, c?’, então, esse dicionário é muito
importante para que seja algo escalável para que todo mundo fale o mesmo idioma na
empresa e tenha acesso aos mesmos dados e as mesmas interpretações em cima desses
dados.

E aí, usamos o Notion que é a nossa ferramenta de gestão de conhecimento mesmo, para falar
sobre educar, porque uma empresa que não tem dados desde sempre, não necessariamente
todo mundo saberia usar, eles podem ter o melhor dashboard do mundo e não saberem usar.
Além de treinarmos em como fazer o setup de um novo dashboard do Amplitude, colaboramos
e ensinamos também a aprender como você usa dados, porque são importantes, como que o
PM pode absorver isso?
Talvez ali tenha até um papel não de Agile Coaches, mas enfim, esse tipo de cultura de
produto, que isso a gente pode também ajudar a escalar ou, linkar um PM que já trabalhou
com isso em outras empresas e um PM que nunca trabalhou com dados ou tendo uma
ferramenta de Product Analytics tão poderosa como é o Amplitude, um Mixpanel e por aí vai,
colocar essas pessoas juntas para que uma aprenda com a outra. Não é
que Product Operations fica na posição de: Eu sei e vocês não. Linkamos pessoas, então, eu sei
quem precisa do gap e as pessoas vão evoluindo. É muito interessante fazer dessa forma, por
isso que aos pouquinhos vamos expandindo e evoluindo para mais squads.

Vamos ao segundo exemplo de dados de produto, que é um scorecard de eficiência do time de

produto. Talvez esse exemplo seja o mais próximo do que um Agile Coaches possa representar
para as empresas que vocês trabalham ou conhecem, mas talvez tenha uma ótica um
pouquinho diferente, então eu vou trazer como implementamos.

No caso da VTEX e de muitas empresas, muitos PMs trabalham com algumas métricas, mas
desconhecem outras ou até o benefício de olhar algumas métricas ágeis de forma geral. Os
líderes de squads, pessoas que influenciam as outras, então: Engineering Managers, de PMs,
pessoas que têm algum liderado direto, é interessante eles terem informações para
desenvolverem os times e isso a gente gerava não ter essas informações, além de não
conseguir desenvolver os times de forma muito eficiente, também gerava uma falta de
previsibilidade e entrega, alguma dificuldade de gerenciamento de backlog e, isso começou a
virar uma dor muito grande da liderança.

Primeiro veio da liderança, mas alguns PMs e Engenheiros também traziam isso de forma
proativa: ‘Quero ajuda para olhar métricas ágeis’, porque viam em algum curso ou de fato não
tinham tempo para olhar, mas queriam ajuda e apoio e a área de Product Operations pode de
fato, apoiar muito nisso. Só que não apoiamos de forma: apoia aqui, apoia ali, apoia aqui,
tentamos fazer uma forma um pouco mais escalável de gerar esse conhecimento para as
pessoas.

Como? Nos inspiramos bastante nessa referência que tem esse link nesse slide, mas é uma
referência de você ter um scorecard de forças de equilíbrio. São seis pilares de forças, métricas
ágeis que se compensam ali. Então, você tem sustentabilidade de produto, impacto no
negócio, quantidade de coisas lançadas, velocidade do lançamento, qualidade do lançamento e
aí você consegue, com essas forças de equilíbrio, ter uma visão, um scorecard mesmo de como
aquele squad está funcionando e onde você poderia mexer para ter melhores resultados.

Importante: isso não é para ser usado de uma forma cross. Então, a gente só de fato, apesar de
ser uma ferramenta única, ela não é para comparar um squad ao outro. Você não compara
itens lançados de um squad ao outro, isso não faz sentido. Você de fato quer usar só
nos squads, entender ler localmente esses números, para que cada squad localmente funcione
melhor. Isso trará naturalmente um resultado global melhor, mais interessante. Dito isso, você
não vincula uma meta de bônus ou algo assim, é uma ferramenta nesse momento, para ajudar
os times a trabalharem.
E aqui eu trago de fato o que está dentro desse scorecard, para cada um daqueles pilares. Por
exemplo, em quantidade, eu estou falando de tarefas, deploys, pull requests e isso também
depende de cada squad.

Isso aqui é como se fosse esses exemplos que estou trazendo aqui, é a base necessária para
que o squad reflita: como eu trabalho, o que eu deveria olhar para que eu entenda como está a
minha previsibilidade, o que eu poderia acompanhar para entender quantidade e
cada squad consegue refletir da melhor forma, mas a gente em Ops trazemos
um setup mínimo que ajuda demais a você sair da inércia. Todo mundo sabe o que tem que
olhar, todo mundo gostaria de ver um pouquinho.

Eu sei que não é muito outcome, trazemos até aqui uma coisa de business metrics de outcome,
mas tem bastante sim de output aqui, mas você precisa ter às vezes, algum nível de
conhecimento disso quando você está em zero. E aí, os times conseguem ir caminhando e
analisando, fazendo retrospectivas melhores e esse é o objetivo.

Então, o primeiro passo foi feito em Excel mesmo. Um Excel simples de atualizar
onde Product Operations dá esse arcabouço do setup e cada time consegue já fazer análises e
ajudamos a saber como interpretar uma métrica de número de deploys, como interpretar uma
métrica de lead time e por aí vai.
E por último, para fechar esse pilar de dados de produto eu quero trazer dicas de forma geral.
Vocês viram o que é um pilar que trabalha bastante com dashboards, com painéis, com
gráficos para alguma audiência. E para você trabalhar bem com dashboards para audiências,
você precisa pensar em algumas coisas. É um produto, o que você está lançando é um produto.
Você precisa pensar para quem vai usar, qual o objetivo? Em que momento ela vai usar? Vai
estar no desktop? Ela vai estar andando na rua? Ela está no celular? Tem alguma ação imediata
para ela tomar em cima disso? E por aí vai.

E para isso, isso vem bastante do meu background em trabalhar com data analytics lá na
Cortex, onde o meu produto muitas vezes era construir dashboards muito incríveis, que os
clientes pudessem construir seus próprios dashboards muito incríveis nas suas empresas. Eu
trouxe aqui um framework que eu gosto muito de usar para pensar com os times em
construção de dashboards interessantes. Esse framework chama-se Fogg Behavior
Analysis que é comportamento de Fogg, quem criou foi um pesquisador da Universidade de
Stanford nos Estados Unidos.

Esse framework diz o que? Ele fala sobre três pilares que geram um comportamento esperado
e quais são esses pilares? Motivação de uso, habilidade de usar e instruções que geram
os triggers, os gatilhos necessários para gerar algum comportamento e, basicamente, o que diz
é: Se você analisa se a pessoa tem a motivação necessária.

Então, as pessoas têm ciclos de motivação, muitas vezes sua motivação é alta, você consegue
fazer coisas mais difíceis quando a motivação é alta. Assim que você baixa um aplicativo novo
que está a fim de usar, você provavelmente preenche um formulário um pouquinho maior. Por
que? Sua motivação está alta, mas você não faria isso numa motivação baixa.

Habilidade é: O que é difícil de fazer, fácil de fazer. Você tem que tornar o mais fácil possível,
mas se a motivação está alta, você até consegue atividades mais difíceis assim para a pessoa,
naquele momento. Então, você tem que entender o momento da pessoa.
Instruções para você gerar os gatilhos, não adianta a pessoa ter a motivação, ter habilidade e
não saber usar, não saber quando ela tem que entrar. Ela tem que lembrar sozinha de acessar
aquele painel, por exemplo, trazendo para o exemplo aqui.

Esse framework ajuda muito a pensar nesses pilares, e aí são as perguntas que normalmente
eu faço aos times: Quando ela tem que acessar o painel? Ela vai do nada acordar e clicar nisso?
Não. Tem que ter um gatilho. Isso vai no slack? É um gatilho? Aonde que é? É uma reunião? A
reunião é o gatilho para então acessar? É uma mensagem de slack? Quantas vezes por
semana? Enfim, esses são só alguns pilares interessantes de você pensar para que você tenha
sucesso no uso e não só lance painéis e eles fiquem lá sem nenhum tipo de impacto, porque
esse é o objetivo no final de lançar qualquer coisa.