Essa é a transcrição do podcast “Episódio 4 – Product Ops com Thiago Belluf”. O link para ouvi-lo está no final desse conteúdo.

Parte da galera da área de produto começou sua carreira ainda na faculdade, e com o Thiago Belluf, nosso quarto convidado, não foi diferente. No estágio do curso de engenharia de controle e automação surgiu o interesse relacionado à computação, quando percebeu, desenvolver software era um negócio que estava curtindo fazer. 

Começou como desenvolvedor e quando se deu conta já estava na área de produto. Na Chaordic liderou um time. Quando teve a certeza do que queria, começou a procurar oportunidades na área e então entrou no time da OLX, onde trabalhou por um pouco mais de 4 anos.

Em nossa conversa Thiago fala de como liderar um time e como se tornou Product Ops. 

Está estudando para ser um, ou está pensando ser? Acompanhe nosso papo, ele lhe trará muita clareza para o caminho que você está pensando seguir.

A: Senhoras e senhores sejam muito bem-vindos a mais um Product Backstage. No papo de hoje eu estou aqui para falar com o Thiago Belluf, aqui na OLX. Muito obrigado por me receber aqui Belluf. 

T: Valeu!

A: Cara, para a gente começar a esquentar nossa conversa, tu pode falar um pouquinho da tua trajetória, enfim… Tu está aqui na OLX hoje, o que que tu faz aqui hoje? O que que enfim… foi a tua trajetória até então?

T: Tá bom! Legal! Bom, minha formação é engenharia, eu fiz engenharia de controle e automação lá na UFSC, em Santa Catarina, né? Não tem nada a ver com o que eu faço hoje, é uma engenharia essencialmente assim, muito industrial, né? Então a gente estuda vários cases, assim, de indústrias, como modelar um forno de cerâmica, uma torre de extração de petróleo, mas tem um… Tem um pedacinho dessa engenharia que é muito focada em computação, né? E aí quando eu comecei a fazer estágios mais relacionados à computação, eu fui vendo que desenvolver software era um negócio que, enfim… Eu estava curtindo bastante, e aí entrei nessa carreira de desenvolvimento. Então, lá no início o que eu fazia? Eu trabalhava com desenvolvimento de software, era desenvolvedor, era uma pegada um pouco mais voltada para data science também. Então, os algoritmos base daquela Chaordic que eu ajudava a desenvolver, e aí, de repente, eu fui sendo quase que abduzido, sem perceber, para um lado mais de negócio, né? De produto… E até não sabia dar nome para o que eu fazia na época, mas olhando para trás na minha carreira, eu vi que eu passei de um cargo de data science, para um cargo que hoje eu chamaria de analista de dados, dentro das estruturas de produto, até que recebi um convite também ainda dentro da Chaordic para liderar um dos times de produto, onde uma das minhas responsabilidades era fazer a gestão do produto, entre milhares de outras coisas, era vender o produto para o cliente, tinha que fazer gestão de desenvolvimento, mas também fazer essa parte de gestão de produto. E aí quando eu vi que era isso, que eu estava curtindo realmente de tudo aquele bloquinho ali de gestão de produto, era o que eu realmente estava amando, aí eu comecei já mais consciente a buscar oportunidades em gestão de produtos, e acabei na OLX, estou aqui há 4 anos. 

A: Muito legal, cara! E esse seu background de engenharia, na tua percepção, assim, o que que te atrapalha e o que te ajuda esses conhecimentos que tu adquiriu em engenharia de automação?

T: Legal! Legal! Cara, assim… Acho que engenharia, de maneira geral, te ensina a resolver problema e fazer produto, é em essência, resolver o problema. Ser um pouco mais tangível, assim… Eu acho que a engenharia te treina com um pensamento lógico muito estruturado, muito objetivo, muito consciente, e essa habilidade hoje de conseguir pegar alguma coisa que está meio vaga, um problema que não está muito bem delineado ou enfim… Percepções, evidências e fazer essas conexões lógicas a ponto de chegar, enfim… Num problema mais bem estruturado, numa solução, enfim… Essa capacidade lógica que a engenharia me desenvolveu, eu acho que é a minha grande arma do dia a dia, assim… O meu grande instrumento de trabalho é a lógica, isso eu não tenho dúvida nenhuma, assim… Uma coisa que… Acho que esse pensamento muito objetivo me atrapalhou, principalmente no início de carreira, é que eu subestimava, acho que o poder, de algumas coisas um pouco mais abstratas, assim, sabe? Então, hoje eu tenho gostado muito de estudar um tópico que a gente chama de designer organizacional. Então, como criar os mecanismos que depois vão fazer a empresa rodar, e estudando designer organizacional eu comecei a me deparar com a força do que eles chamam de artefatos. E aí artefato é alguma coisa tangível, que você consegue ver no dia a dia, e por exemplo um símbolo é um artefato, uma fala é um artefato, o fato de alguém apresentar alguma coisa durante uma cerimônia é um artefato. E a engenharia… Acho que eu não acreditava no poder desses artefatos que lá não engenharia eu achava que eram, sei lá… Coisas que acontecem, assim, mas eles não têm um poder transformacional. E aí, agora, estudando designer organizacional, todas essas coisas que são mais abstratas, assim, eu acho que eu reconheço o poder delas, coisa que eu não reconhecia por conta da minha formação anterior.

A: Legal Legal! E essa mudança, né? Pow, tu saiu de dev, daí foi para PM e, depois de PM tem uma especialização, vamos dizer assim, em Ops. Isso aí foi uma coisa pensada para ti? Tu estruturou isso? Ou simplesmente aconteceu?

T: Não, cara, assim… A Janet, que é a nossa CPO, conforme a nossa organização foi crescendo, né? Então, quando eu entrei na OLX eram 5 PMs e em determinado momento éramos 20, e aí quando a gente chegou nesse tamanho a gente começou a enfrentar problemas que, obviamente, a gente não tinha antes, ela começou a pesquisar o mercado, como o mercado estava resolvendo aquilo, né? Como é que as empresas estavam resolvendo essa questão escalar time. Aí ela se deparou com esse tipo de time, dentro de uma estrutura de produto, que é operações de produto, daí ela, junto comigo, montamos o que seria uma primeira versão de operações de produto, que na verdade hoje é bem diferente, o meu entendimento de operações de produto em relação a hoje e um ano atrás é bem diferente, mas enfim… Foi um convite da Janet e aí a gente criou a área junto, e enfim… É isso aí. 

A: Acho que essa última parte é interessante de… O  conceito é diferente porque… A minha pergunta é justamente nessa linha, né? Eu vejo vários conceitos do que é Product Ops, eu acho que produto de uma forma geral tem essa zona de nomenclatura, começando pelo tradicional Product Manager e Product Owner que não tem uma definição clássica em cima disso, mas olhando para product ops especificamente,  o que que na tua visão é product ops?

T: Tá, assim… A gente costuma dizer que operações de produto é essencialmente um time de facilitação, né? É um time que está ali para fazer com que a estrutura de produto, as pessoas que estão ali fazendo desenvolvimento de produto, sejam os PMs ou todo mundo que ajuda os PMs, analista de dados, designers, enfim… É que esse grupo consiga ser mais eficiente. Então, para mim a responsabilidade de operações de produto é de uma maneira mais neutra olhar esse grupo de fora e avaliar de uma maneira sistemática e crítica onde estão os pontos de melhoria, onde estão os pontos de oportunidade. Então a primeira responsabilidade eu  acho que seria essa, fazer esse diagnóstico sistemático, é o core de operações de produto, e aí obviamente depois implementar novos mecanismos para resolver essas questões, também faz parte da responsabilidade do time, né? 

A: Entendi! E sendo mais direto, assim… Qual que é o valor que tu vê que um time de ops entrega para uma organização? Se tu fosse defender isso hoje, como é que tu defenderia, assim?

T: Legal! Assim… É… Quando um time de produto nasce, é óbvio que não existe operação de produto nele, mas com certeza absoluta alguém dentro da estrutura daquele time está fazendo o que, eventualmente, no futuro um time de operações de produto vai fazer. Normalmente, quem tem essa responsabilidade de observar o time e pensar em como ele pode ser mais eficiente, é em primeira instância o CPO, a liderança maior de produto, e depois todo o conjunto de gestores que estão ali dentro, né? Mas chega um determinado momento em que essa estrutura ela fica tão granularizada, que essas pessoas elas passam a ter visões… O CPO, tem uma visão sistêmica, tem uma visão geral, mas não consegue entrar tanto mais no detalhe porque, eventualmente… Inevitavelmente ele se afasta da operação. Se você tem uma estrutura com 50 PMs é muito improvável que você como CPO vai saber exatamente o que que o cara está vivendo, qual é a rotina dele. Então, o CPO ele perde essa habilidade, ele perde essa informação de como é que a operação está vivendo. E os gestores que estão próximos da operação, eles não têm a visão sistêmica, eles têm a visão local. Hoje na estrutura da OLX, por exemplo, a gente tem 11 ligas, cada liga tem uma liderança sênior de produto e, obviamente, que a liderança sênior daquela liga entende a operação daquela liga, mas não consegue identificar os padrões de oportunidade que se manifestam em todas as ligas. Então, operações de produto eu acho que é o time que no final das contas, é quase como se… É… Tivesse a visão sistêmica, junto com o CPO, mas que no dia a dia se aproxima da operação para poder identificar onde é que estão os problemas. E aí obviamente, pega essa informação, leva para o CPO e traça um plano de ação em cima daquilo. Eu costumo dizer que a gente é quase como se fosse os braços de um polvo, assim, né? O CPO continua sendo o polvo e a gente é os bracinhos que se embrenha, enfim, nos times e conhece a operação de fato, fala com as pessoas, estrutura aquilo num diagnóstico e atua. 

A: Legal! É… Eu acho que tem uma analogia muito grande quando você fala de liderança, quando você sai, por exemplo, de um PM para ir para uma liderança de um time de PMs, você olhar para esse time como se fosse o teu produto, né? Não da forma como tu estava lá como PM. E eu vejo muito forte essa coisa com product ops também, pelo jeito.

T: Com certeza! Com certeza! Assim… Quando a gente criou a área e quando eu contratei a primeira pessoa, o Wagner, que hoje está comigo, eu falei para ele: Olha, Wagner… Eu falei exatamente isso que você falou, que a gente tem que lidar com a nossa estrutura de produto como se fosse um produto, e a gente tem que aplicar as mesmas metodologias, assim, né? Eu falei que agora eu estou estudando bastante essa questão de design organizacional e a gente está fazendo uma parceria com uma consultoria de designer organizacional, e eles têm uma série de metodologias que hoje basicamente eu estou usando para resolver quase todos os problemas que estão no escopo de operações de produto, e ela foi criada super baseada em metodologias ágeis, assim… Então quando a gente fala de, por exemplo, tem que resolver alguma disfunção, a gente pensa num artefato e a gente desenha um experimento para testar aquele artefato. Então, a  ideia é sempre essa, um artefato é uma possível solução para uma disfunção organizacional, a gente planeja um experimento ágil, rápido, de custo baixo, digamos assim, de risco baixo, e aí depois que a gente valida aquilo, localmente, a gente pensa em como a gente instala aquilo. Então essa pegada de desenvolvimento de produto, essa pegada ágil é o jeito com que eu, pelo menos, tenho trabalhado em operações de produto.

A: Só para deixar isso mais palpável Thiago, qual foram, sei lá… Os últimos problemas que tu resolveu como organização de product ops, assim?

T: Legal! Legal! Então, hoje é sexta-feira, na quarta-feira a gente fez um offsite grande de produto, a gente pegou a nossa estrutura de produto toda e a gente olhou… O objetivo do offsite era fazer esse grupo olhar para si mesmo e pensar o que a gente tinha que trabalhar, né? E aí saiu uma questão que foi quase unânime assim, em todos os subgrupos ali dentro, saiu uma questão por exemplo de estratégia, de como a nossa estratégia ainda está muito difusa, ela não entrega prioridades muito claras, né? E aí quando a gente começou olhar o material que a gente usa para comunicar a nossa estratégia, a gente viu… Vai parecer muito bobo o que eu estou falando, mas é muito forte, a gente viu por exemplo, que a nossa estratégia hoje ela tem 12 pilares, e a gente estava comunicando ela através de uma mandala. Uma mandala é basicamente um círculo, um círculo não tem um início, não tem um fim, então você não consegue através da representação simbólica dizer qual é o primeiro pilar e qual é o último pilar, não existe um primeiro e um último dentro de um círculo. E essa falta de comunicação de priorização levava, por exemplo, na prática, na hora que os times tinham que definir algum trade off, eles não sabiam, por que eles não sabiam o que que era mais importante, o que que eles tinham que privilegiar na hora de definir um trade off. E aí o que que acontecia? Acontecia que o PM, dado que ele não tinha informação suficiente para resolver aquele trade off, tinha que executar um processo de escalar aquilo, e eventualmente aquilo escalava até o nosso nível de diretoria e, obviamente, que para escalar você demora tempo, você escala primeiro para o seu primeiro nível de gestão, para o segundo nível de gestão e esses níveis de gestão começam a se falar. Imagina que para resolver um trade off a gente passava de 3 a 4 semanas até aquela decisão chegar em alguém que conseguia resolvê-la. Isso traz uma ineficiência gigantesca para o grupo. Imagina se com 50 times, todos os times ficassem paralisados, dependendo 4 semanas de um processo de escala para resolver uma decisão. Então, o que eu estava dizendo sobre artefato, de uma coisa que parece relativamente boba, é uma coisa super tangível que a gente fez é: Cara, a gente não vai mais comunicar a nossa estratégia através de uma mandala, a gente vai comunicar a nossa estratégia através de blocos onde o da esquerda é mais importante que o da direita e isso entrega uma priorização clara para todo mundo que observa aquele símbolo, entendeu? Então assim… Um detalhezinho, mas que através desse processo de falar com o time, de estruturar um diagnóstico, de observar como a gente estava solucionando aquilo, a gente reviu o símbolo como uma maneira de endereçar essa confusão. Um exemplo.

A: Esse exemplo é um exemplo de comunicação, né? É como você comunica a estratégia adequadamente para todo mundo entender, e a hora que precisar fazer os trade offs de priorização, ter isso claro. Então vocês tocam em coisas de comunicação, tocam em coisas de Products Analytics, tocam em coisas de processo ou…

T: Sim, é basicamente comunicação, processos e treinamento. Então, ainda… Pelo menos na OLX é responsabilidade de produto, também, avaliar como é que a gente vai capacitar os nossos PMs, quais os skills a gente tem deficiência, como é que a gente vai desenvolver isso… Então essa parte de treinamento é bem forte, essa parte de comunicação é bem forte também. Então a gente cuida hoje, por exemplo… Nós somos os donos, os donos no sentido de nós desenhamos as cerimônias, a gente garante que elas vão estar sendo bem executadas, que elas cumprem o propósito, a gente cuida, por exemplo, da implementação, que é uma ferramenta que a gente usa para registrar e manter a estratégia tática. Então, é uma grande ferramenta de comunicação, a gente cuida dos newsletters,  então tem um monte de coisas de comunicação embaixo, e essa questão de processos, né? Então a todo o quarter a gente define os OKRs. Então, como é que vai ser esse processo? A gente desenha esse processo de definição de OKRs trimestrais junto com o time de estratégia, garante que todo mundo entendeu, garante que todo mundo está treinado, enfim… Acho que são esses 3 pilares, vamos dizer assim, em operações de produtos. 

A: Quantos PMs tem hoje, mais ou menos, no time da OLX?

T: São 30, nossa entrou um monte semana passada, são uns 35, mais ou menos. 

A: Distribuídos em São Paulo e Rio de Janeiro?

T: São Paulo e Rio de Janeiro!

A: Legal! É que eu… Acho que é uma analogia muito forte que eu tenho uma lembrança, nesse sentido, muito forte… Não é nem de produto, mas é de vendas, quando eu estava na Resultado Digitais ainda, que a gente começou a ver que… Cara, a partir de certo momento que tu tem uma quantidade de vendedores que eu tinha, para eu conseguir ter resultados melhores e otimizar mais, não adiantava eu colocar mais vendedor. Eu tinha que começar a criar time de operação de vendas para otimizar o trabalho de todo mundo, e eu acho que é uma analogia muito forte neste sentido.

T: Exatamente! Exatamente! É exatamente isso, assim… Eu acho que 5 PMs você coloca todo mundo numa sala, todo mundo sabe o que todo mundo está fazendo, 35 PMs com certeza você não consegue fazer isso numa questão de espaço físico, e aí como é que você consegue implementar uma ferramenta para compensar esse tipo de coisa é a essência do trabalho, com certeza.

A: E como é que começou esse time na OLX? Tu lembra de trigger disso? O que que triggou esse negócio de vamos pensar no time de Ops?

T: Então, é principalmente esse processo de definição de estratégia. Esse processo de definição de estratégia trimestral ele era um processo que era muito doloroso pra gente, né? Conforme a estrutura vai crescendo, se granularizando, você vai explodindo o número de dependências. Se antes você tinha um time que tinha um backlog que resolvia tudo que era relacionado àquela parte do produto, a gente quer às vezes a solução para ganhar velocidade e esse time que tem o escopo muito grande, você gera dois times. Dois times, dois backlogs, dois tomadores de decisão cuidando da mesma parte do produto, esses times têm uma dependência. Conforme a nossa estrutura foi crescendo muito, o número de dependências aumentou muito e o processo de definição de OKRs obviamente que ele tem que garantir que a gente não vai fazer nada contraditório. Um time não pode definir uma estratégia que joga com outra estratégia do time do lado, e quanto mais dependente de um time é de outro, mais importante é essa sincronização. E aí chegou num ponto em que a gente passava do quarter inteiro, no trimestre inteiro, um mês inteiro fazendo esse processo de OKRs até a gente conseguir chegar num conjunto que a gente falava: Ok, estamos prontos para começar a trabalhar. Isso não é factível, né? A gente passa 1/3 do tempo para poder fazer o plano, e então a Janet… Nessa época eu ainda era gerente de produto, ainda cuidava de um time, na verdade, eu estava cuidando de uma tribo e aí eu sofria com o processo… Eu sofria, eu passava um mês lá sem dormir, tentando definir bons OKRs, e aí junto com o time de estratégia eu comecei a repensar esse processo e falei: Cara, não está funcionando, desse jeito não está funcionando. A gente tem que fazer alguma coisa prévia antes, a gente tem que criar um fórum, enfim… E aí acho que foi, talvez, o primeiro projeto de operações de produtos, mesmo antes de operações de produtos existir, assim, na OLX.

A: E como é que o time está estruturado hoje? Quantas pessoas estão envolvidas? Enfim, como é que funciona a estrutura desse time?

T: Legal! Legal! Hoje eu estou na liderança do time, além de mim, a gente tem mais 3 pessoas. A gente costuma dizer que essas 3 pessoas eles são o core do time, né? Então tudo o que é essencialmente relacionado a esses 3 pilares que eu falei: comunicação, processos e treinamento, essas 3 pessoas ajudam a executar. E a gente tem mais 2 pessoas que têm uma figura específica que a gente de program manager, gerente de programa. Os program managers na OLX eles vivem dentro da estrutura de operações de produto, enfim… Tem até um porquê, e a responsabilidade deles é o que? Cada program manager lida com um tema específico. Então, a gente tem uma pessoa que lida com tudo que tem a ver com monetização, outra com tudo que tem a ver com a nossa experiência base de liquidez na plataforma. E a ideia do program manager é: Toda a iniciativa que precisa de um alinhamento de um grande número de times, precisa de uma sincronização forte, preciso de um processo de comunicação robusto, um objetivo muito claro, e essa responsabilidade antes era do PM, mas o PM por ter visões muito locais e por ter uma série de outras responsabilidades, às vezes, não conseguia fazer isso da maneira com que precisava, e aí a gente viu a necessidade de trazer alguém, de novo, papel de facilitação, não é um papel de decisão, o PM continua sendo a pessoa que define como é que o produto vai evoluir, o program manager facilita isso, facilita essas conversas entre milhares de grupos de produto e eventualmente até outros departamentos. Então, basicamente hoje a nossa estrutura, resumindo, é essa, né? Três pessoas que cuidam do que a gente chama de core, e 2 pessoas que têm esse papel de program manager para fazer essa facilitação, mas aí já mais próximos dos times ainda. 

A: Então, esse time fica centralizado, não fica necessariamente distribuído entre todos os times, né? Que cada time de produto tem um product ops?

T: Cada time, cada liga… A gente hoje tem uma estrutura de liga, que é um agrupamento de tribos, cada liga tem um program manager, um gerente de programa. Então essa é maneira com que product ops tem de se aproximar mais ainda da operação, e aí sim a gente tem esse outro núcleo, que está fora de todas as ligas, que daí cuida das questões horizontais. Então a gente tem as 2 coisas hoje.

A: E como é que os problemas chegam até vocês, assim? Tipo… É uma visão mais top down, digamos: Ah, o CPO está olhando para esses problemas e daí ele aponta? Ou é um negócio mais botton up, dos PMs vão levantando problemas, como funciona isso?

T: Assim, obviamente, os problemas aparecem de todos os lados. A partir do momento que você cria um time desses, um monte de coisas que antes não tinha destino passa a ter. Então, a gente acaba ouvindo de todos os lados, assim. Mas o que eu acredito mesmo é que para a gente resolver de fato os problemas, óbvio, a gente tem que achar as causas raízes e a gente tem que achar as causas raízes observando as manifestações, observando os sintomas. E os sintomas eles aparecem quando a gente está na operação. Então, o nosso plano… O plano que a gente executa hoje de trabalho, ele veio de operações de produto de uma maneira muito sistemática e estruturada, falar com o gerente de produto, com as pessoas que estão no dia a dia, falar com os desenvolvedores, falar com gerente de engenharia, e através desta coleta sistemática de sintomas, vamos dizer assim, a gente começa a entrar mais a fundo e gera um diagnóstico e um plano. Então assim… Sim, a gente às vezes executa algumas coisas que vem porque a Janet, a CPO, ela gostaria de fazer, mas a maior parte dos nossos problemas vem de baixo, vem na verdade da gente observando a operação. 

A: Entendi! Produto mesmo, falando com usuário e pegando o feedback… Cara, depois de quase 3 anos aí, na frente desse time na OLX, o que que tu diria que são as maiores conquistas desse time?

T: Nossa! Tá! Cara… Eu acho que esse processo de definição de estratégia que eu falei que foi o que iniciou a operação de produto, eu acho que hoje ele é um processo que roda bem, eu estou bem satisfeito. Não é mais um processo super doloroso, as pessoas não perdem o sono mais. Claro, tem muita coisa para melhorar ainda, em relação à estratégia, sempre tem, mas esse processo eu gosto, eu acho que ele está legal, está robusto. Uma coisa que a gente… Ainda está em construção, mas eu acho que está bem avançado, é uma parte relacionada a treinamento e desenvolvimento. A gente lançou no final do ano passado um programa de recrutamento que a gente chamo de loading program, que basicamente é para dar oportunidade para quem quer entrar na carreira de produto, né? Então, a gente foi para o mercado, quem quer entrar para a carreira de produto, entra através do loading. E aí, óbvio que para dar sustentação ao loading a gente precisa ter um programa de treinamento robusto ali dentro, a gente tem que trazer alguém que não está capacitado e tem que capacitar muito rápido. Para isso a gente criou todo um arcabouço treinamento usando a galera que está na OLX, a gente criou uma série de aulas que a gente gravou, que estão disponíveis numa plataforma online, a gente tem que estabelecer um processo de mentoria, a gente trabalhou junto com o RH para definir critérios de avaliação de performance, para poder dar sustentação à carreira dessa galera, e obviamente que isso agora a gente usa não só para os loaders, mas para toda a estrutura de produto e até para as pessoas que estão fora dessa estrutura de produto. Então uma coisa interessante é que quem está fora da estrutura de produto… O time comercial, eu acho que é o time mais emblemático, assim… Eles às vezes têm dificuldade de entender o processo, como desenvolver um produto do jeito que a gente acredita, às vezes o comercial ele entende um processo que é diferente. Então, a gente usou muito do conteúdo que a gente gerou para treinar os nossos PMs para treinar também o comercial nos nossos processos, o que daí obviamente cria empatia, né? Então eu acho que hoje colabora um pouquinho mais, um pouquinho melhor com o comercial, porque o comercial entende o porquê que a gente faz assim e não de uma outra maneira, entendeu? Então, eu acho que é isso aí! 

A: Legal! Eu acho que esse desafio de treinamento… Ainda mais quando, de novo, né? Quando a organização começa a crescer, eu vejo isso claramente na Nubank, por exemplo, hoje, ele sempre é um desafio, né? Porque você está contratando pessoas, eventualmente, muito boas, você tem, obviamente, pessoas em treinamento num mais júnior também, mas a troca entre essas as pessoas vai ficando cada vez mais difíceis se for depender só do orgânico, né? Tu falou, beleza, de ter vídeos gravados etc., tem mais alguma coisa que vocês fizeram nessa direção?

T: É, assim… Eu acho que essa questão de gerar um conteúdo que fica disponível independente da pessoa, através desses vídeos, é uma coisa. A gente estabeleceu algumas cerimônias também de aprendizado, então a gente tem hoje o que a gente chama de pintalks, que é talks em temas específicos. Então, por exemplo, a gente tem o experimentation talks, então é um open mic mesmo, a galera senta num círculo, num feed pool mesmo e traz os problemas de experimentação que eles têm no dia a dia, a gente faz isso uma vez por mês e aí a ideia é: Experimentation talks é algo que já está bem implementado, mas a gente quer fazer isso com analytics, a gente quer fazer isso com user researcher e enfim… Qualquer outro tópico que a gente considere que é core. Então, cerimônia de compartilhamento de maneira geral é outra coisa que a gente usa também e mentoria. Então, mentoria é algo que algumas… Eu acho que isso… Várias empresas sofrem, quanto mais horizontal a estrutura é, essas coisas começam a acontecer, né? A gente não tem… Tem várias pessoas que têm esse desejo de desenvolver pessoas, eventualmente, a gente não tem naquele momento um cargo de gestão aberto para colocar aquelas pessoas, e obviamente talvez elas nunca tenham feito isso antes, então colocá-las em um cargo de gestão sem ter uma experiência é algo que pode ser um risco. Então, a gente estabeleceu esse processo formal de mentoria para pessoas que miram para uma carreira de gestão que elas consigam já, de uma maneira menos formal, digamos assim, né? Você não vira gerente no papel, mas você está desenvolvendo alguém diretamente. Então a gente abriu esse papel de mentoria, e recentemente a gente até mudou os nossos critérios de avaliação de performance para pessoas que estão fazendo mentoria com outras, para que isso seja levado em consideração quando a gente for qualificar performance. Então é uma maneira… É mais um incentivo para que as pessoas estabeleçam essas dinâmicas de mentoria, e tem dado super certo, assim, eu estou super feliz, a gente tem 3 PMs, o Frank, a Fernanda e o Felipe, 3 Fs inclusive, a gente costuma brincar, que estão fazendo mentoria e cara… O resultado está muito além do que eu imaginava, assim, do que seria possível, está bem legal.

A: Legal! Legal! Isso é uma… Só para entender melhor como é que funciona isso, mas é tipo uma agenda? Tem slot fixo para eles, como é que funciona a dinâmica no dia a dia, mesmo?

T: Pois é… Então… 2 desses estão mentorando os loaders, né? As pessoas que entraram nesse processo de treinamento acelerado, e então, os loaders eles estão no mesmo time que o mentor deles está. Então, é um pouco mais fácil, eles já estão na rotina, eles têm a mesma rotina. O terceiro que está fazendo essa mentoria, mais… Enfim… Que não é no mesmo contexto, eles têm uma agenda de ones on ones, e têm um plano de desenvolvimento que é trançado pelo gestor direto e pelo mentor,né? Então, por exemplo, um ponto que a gente acha super difícil desenvolver com treinamentos nesse formato clássico de sala de aula, é estratégia. Uma visão mais estratégica, como definir estratégias de produto, a teoria ela não ensina o que precisa ser aplicado na prática, então, a mentoria tem sido a maneira com que a gente tem conseguido pegar pessoas que nunca fizeram… Definir estratégia de produto, conseguir definir melhor a estratégia para os times deles. Então, tem um misto aí.

A: Legal! E para fechar esse bloco, quando tu falou do programa do loading, ali, que é um programa de PMs, né? Acho que eu vi pouquíssimos desses hoje no Brasil, acho que você, se duvidar, é o único assim que eu vejo mais formal, eu sei que eles investem… Teve um negócio de trainee um tempo atrás, a gente na RD rodou alguma coisa, mas bem embrionária…

T: Sim, eu conversei com vocês na época que a gente estava montando o programa. 

A: Mas foi bem embrionária também. Duas coisas, né? Uma, se tu tem resultados já desse programa? E dois… Como é que ele funciona, assim? No sentido de que é uma turma? Entra todo mundo junto? As pessoas passam pelo mesmo treinamento? Enfim… Como é que funciona o dia a dia desses PMs?  

T: Legal! Legal! Tá bom! A gente… Quando a gente ia abrir o programa, a gente já esperava 2 perfis:  um perfil que é alguém que está iniciando na carreira, mas que tenha interesse em entrar quase diretamente na carreira de gestão de produto, talvez tenha 1, 2 anos de experiência em alguma outra área, e um outro perfil que é alguém que já é um especialista em algum assunto, então, um designer, um desenvolvedor ou enfim… Vários skils aí, e que quer migrar para uma carreira de gestão de produto. Então a gente já imaginava esses dois perfis. Quando a gente fez o processo seletivo no final do ano passado, pela maneira como a gente conduziu o processo de recrutamento, a gente só conseguiu recrutar o primeiro perfil, pessoas que estavam entrando no mercado e queriam entrar na carreira de produto. Então nós contratamos 2 pessoas, e a ideia é que no final do ano a gente vai abrir de novo para contratar mais 2 do outro perfil, que são os especialistas, né? Então o que eu posso te falar é do resultado que a gente está tendo em relação a treinar o primeiro perfil, porque é diferente, né? Um designer obviamente que ele já vai vir com uma bagagem, com uma maturidade profissional, diferente de alguém que tem 2 anos de experiência. Então assim… Para esse perfil mais iniciante, como é que a gente estruturou o programa? A gente tem os 3 primeiros meses, onde a gente tem treinamentos teóricos e até práticos também, mas assim… É essencialmente treinamento, tá? Então a gente fez uma parceria com a Tera, as pessoas chegam, elas já vão para o curso de Product Leadership do Tera, para quase tomar um banho de loja de produto, tem uma lista de referências bibliográficas que a gente passa e a gente estabelece algumas dinâmicas de falar sobre o que eles estão lendo… Esses cursos que a gente estruturou, internos, eles passam por esses cursos de informação logo no primeiro mês, e fazem uns boards in tradicionais, e daí no final, na segunda metade desses primeiros 3 meses, eles é… Ficam juntos com o time de análise de dados… Então, a ideia é que eles virem sombra de um analista de dados, porque a gente viu que esse skill de análise de dados é o que estava muito difícil de encontrar no mercado e que a gente precisava desenvolver internamente. Então pow, tá bom… Vamos já garantir que o loader vai ter esse negócio forte logo de cara. Então, eles passam um mês e meio sendo sombra de um analista, fazendo exatamente o que um analista faz. Então, eles aprendem a mexer no Tableau, eles aprendem a fazer query, eles desenham análises, enfim… E aí depois disso eles migram para atuação dentro dos times de fato. E aí são 2 blocos, um bloco de 6 meses, dentro de algum time, sendo sombra de algum PM, e um outro bloco de 3 meses, na mesma pegada. Então a ideia é que pelo menos dentro desse um ano de treinamento eles passem por dois contextos dentro da empresa. E aí a gente ainda nem terminou nosso primeiro ano, na verdade, a gente está fechando esse bloco de 6 meses agora, em dezembro, e o que a gente está tentando promover é que essas 2 experiências sejam em times que têm naturezas diferentes. Então, vou dar um exemplo, o Henrique agora, ele está num time de Advertising. Então, tem um conhecimento específico de advertising que é necessário ali, é… Tem problemas do tipo: Resolver o trade offs entre… Vou trazer receita, versus trabalhar a experiência do usuário. Então, tem problemas específicos desse mundo, e aí depois ele vai migrar para um time de busca, que tem outros tipo de problema, uma pegada muito mais de falar de produto de dados, de entender de algoritmos e tal. Então a ideia é essa, dois contextos, e contextos que têm essências diferentes, né?

A: Bom… Voltando para a questão de products ops, de uma forma mais global, hoje o que diria que são dores reais que o time teria que estar experienciando para justificar criar um time de product ops? 

T: Eu acho que todos os times vão ter dores que justificariam, é uma questão aí também de quando o investimento é possível, né? Não sei, não consegui ainda cunhar uma regra do tipo: Depois de 10 squads você ganha operações de produto, ainda não tive essa audácia aí. Mas cara, é isso, assim… O nosso problema apareceu quando a gente passou a de 15 Squads. Quando a gente passou de 15 Squads foi, na verdade, o momento que a gente estruturou tribos. Então a gente nem tinha tribos estruturadas antes, não havia tanta necessidade desse agrupamento formal. Aí quando a gente estruturou tribos, a gente começou a ver esses problemas de processo, e aí talvez 2 meses depois da estrutura de tribos foi quando a gente já criou operações de produto. Então assim, não sei se isso é uma regra, mas na OLX foi mais ou menos esse ponto em termos de tamanho. E, obviamente, a gente tinha a capacidade de pegar alguém e alocar ali e fazer um time, né? Então, tinha recurso para fazer isso também. Foi mais ou menos aí.

A: Já aconteceu de ter tipo um time de product ops formal, assim? Tipo alguém puxando isso?

T: Eu! Por isso virei product ops. Acho que a pergunta não era bem essa, mas acho que é isso, assim… A minha rotina… Eu estava passando por problemas da minha rotina que eu sabia que eu precisava resolver, eu não tinha responsabilidade formal de resolvê-los, mas se eu não resolvesse a minha rotina continuaria ruim, então essa iniciativa de ir junto com o time de estratégia, falar: Cara, a gente precisa rever o nosso processo de definição de OKR, porque se não vou ficar maluco. Então, meio que informalmente eu acabei puxando, e aí hoje estou com time não é à toa, é por conta desse início.

A: Legal! Justamente nesse ponto, né? Quais são as características que tu vê para uma pessoa, que ela precisa ter para liderar um time de product ops? 

T: Tá! Cara, assim… É um time… É um time de… Vamos lá! Product ops tem o objetivo de fazer a organização ser mais eficiente. A organização é formada de pessoas. Ter essa habilidade de conseguir entender quais são as disfunções que estão acontecendo no nível de pessoas e transformar essa coisa, que parece no início meio abstrata, para um diagnóstico bem estruturado, bem claro, para depois fazer atuação é uma habilidade core, óbvio, de product ops, mas na verdade de produto em geral, né? Mas enfim… Muita empatia, essa capacidade de se conectar com as pessoas, de conseguir criar um ambiente de segurança para que elas externalizem de fato quais são os problemas que elas são passando, para aí você ter o insumo correto para atuar em cima, sem empatia a gente não consegue ter acesso à informação que a gente precisa para fazer bons planos, né? Então eu acho que empatia é super importante, e cara… Disciplina, é uma coisa que inclusive eu não tenho, mas o meu time tem, ainda bem! Então, a gente se mune de pessoas que te complementam. Mas disciplina para conseguir fazer essa… Mudar uma organização,  mudar a maneira com que as pessoas trabalham é difícil porque isso implica em mudar não só comportamentos, mas crenças, né? E às vezes fazer esse nível de mudança pede muita resiliência, pede muita insistência, digamos, né? Então ter disciplina para sistematicamente traçar uma ação, implementar num escopo, implementar ela num time, implementar ela em outros mais 5 times, e aí entender que cara… Funcionou no time 1 porque o time 1 tem essa característica, e não funciona no meu time 2, porque o time 2 tem essa outra característica, então ter essa disciplina para poder agir sistematicamente eu acho que também é outra coisa super essencial, assim.

A: E as pessoas que trabalham nesse time, né? Tu falou, beleza, tem 2 product manager e tem duas pessoas que trabalham diretamente contigo nesse core…

T: Três.

A: Três pessoas… Eles foram PM antes? São PM de formação? São pessoas de  formações diferentes? Enfim… 

T: As duas pessoas que são product managers hoje, elas vieram de empresas que têm produtos digitais e elas atuaram junto com o time de produto, então para elas a disciplina de produto não é algo novo, elas já tinham contato, mas elas não foram gerente de produto. Inclusive o que a gente está capacitando é, cara… Por mais que elas não sejam PMs hoje, elas têm que entender exatamente como um PM trabalha, que elas estão passando por treinamento agora é exatamente isso, mesma formação que a gente dá um PM, a gente vai dar para os nossos gerentes de programa também. As outras três pessoas que estão no core, uma delas foi PM e a gente considera super importante ter alguém que tenha vivido o que um PM viveu, porque tem que ajudar o outro lado agora, né? Então, eu fui PM, obviamente, e a Alessandra que está no time também foi PM. Então, a gente sabe as dores quando as pessoas relatam.  A gente viveu as mesmas dores. Uma outra pessoa é uma pessoa que a gente chama de trainee de operação de produto, porque é um cara que a gente, enfim… Trouxe de CS, o que é super legal também, porque ele vem com essa visão do que o usuário estava falando dos processos que a gente estabelece  lá na parte de atendimento. Então, o fato de ele vir de CS foi sem querer querendo algo bom. A gente não programou, mas hoje a gente viu valor, ter alguém de CS representado ali dentro, e a outra pessoa ela vem de consultoria. Então essa habilidade, de por exemplo, de cara… Entrar num contexto que não conhece, rapidamente ler aquele contexto e estruturar aquilo de um jeito tangível, e atuar em cima, pow… É isso que uma consultoria faz! O Wagner hoje ele faz isso com maestria, e cara… Sem o Wagner ali, com certeza, a gente não estaria operando do jeito que a gente está. 

A: E…. Quais são suas dicas para quem está começando um time desse hoje?

T: Tirem um tempo para entender de fato os problemas da sua organização. Quando a gente começa um time de… Quando a gente começou o nosso time de operações de produto, tinha um monte de coisa que a gente achava que era super óbvia, que a gente queria sair fazendo no dia 1. Óbvio que a gente precisa fazer treinamento, é óbvio que a gente precisa implementar ferramentas de comunicação nova e aí, de repente, a gente já estava lá avaliando o aba e fazendo cotação, e vendo como é que a gente iria fazer treinamento do aha e tal. E teve um momento que a gente se perguntou: Cara, mas pera aí rapidinho… O que que a gente está querendo endereçar com o aha? O aha é uma ferramenta complexa, a gente vai pedir para a galera mudar bastante o processo de trabalho, tem que valer muito a pena, a gente tem que justificar de uma maneira muito clara, senão as pessoas não vão se engajar com essa implementação. E aí foi que a gente deu, vou falar 2, mas foi 10 passos para trás, porque a gente parou por praticamente uns 4 ou 5 meses, e foi fazer esse processo de observação sistemática que eu descrevi antes. Então a gente foi falar com todos os PMs, todos os gerentes de engenharia, todos os stakeholders principais de produtos, a gente organizou tudo isso num diagnóstico que ficou extremamente rico, e aí depois a gente reviveu a iniciativa do aha, mas agora com um objetivo muito mais claro. Basicamente, o que eu estou falando, agora, se alguém está me escutando é um PM, a gente fez um discovery antes de desenhar uma solução. Então eu acho que é isso, assim… Segurar um pouquinho a ansiedade e garantir que a gente tem muita clareza dos problemas. Parece meio óbvio, mas é isso. 

A: Ah, legal cara. E eu acho que tem muito esse negócio de… Porque o que vocês estão fazendo na prática ali, me corrige se eu estiver enganado, mas é uma série de frameworks para como você vai fazer tudo, né? Desde o processo de comunicação e etc. E como todo o framework tem aquele balanço entre até que ponto eu entrego as coisas num ponto que ela está bem modelada, e aí fica fácil de qualquer um aprender a aplicar aquilo, mas também não engessa muito o processo porque senão você começa a tirar a liberdade de cada um fazer do seu jeito em algum nível também, né? Isso eu imagino que seja um desafio enorme.

T: Super desafio! Por exemplo, a implementação do aha é algo que a gente puxou, tocou, mas sempre com um quê de desconforto, né? Porque cada PM já tinha o próprio processo de gerenciar ali a sua estratégia, sua tática e sua operação. A única ferramenta que a gente tinha antes do aha  implementada, que todo mundo usava, era o Jira, que é basicamente uma ferramenta de operação, uma ferramenta de dia a dia ali, e a gente ficou se perguntando se a gente implementar uma ferramenta do nível acima do Jira, né? Para a parte de estratégica e tática, se seria algo que ia engessar… E o que a gente fez foi: Você tem milhares de maneiras de implementar a mesma coisa, a gente, de novo, nesse processo de observação aí de como cada PM estava trabalhando, a gente identificou, tal… O que que é padrão? E o que que é específico? Então qual é o nível de customização que eu preciso deixar o aha  ter para que eu não chegue lá e martele alguma coisa que não tem nada a ver com a maneira com que aquele PM está trabalhando há 2 anos, entendeu? Então eu acho que a gente conseguiu chegar ao meio termo. A gente fez uma implementação do aha  que dá certa flexibilidade. Então, por exemplo, a gente tem… Vou tentar dar um exemplo bem mais prático assim… Esse do aha  que eu acho que foi uma… Foi uma… Algo que a gente demorou para dizer: É a solução mesmo! A gente faz o mapeamento, a gente faz um link do aha com o Jira, né? Então a ideia é que se você faz alguma ação no aha, ela se espelha automaticamente no Jira, para diminuir a necessidade de manutenção, em consistências e etc. E aí tem PMs que no Jira trabalhavam, por exemplo, uma issue, era um user story inteira, e eventualmente aquele negócio tinha várias interações dentro, então eles gerenciavam aquilo através de subtestes. Outro PM não usava uma issue, usava um epic para fazer aquilo e cada issue era uma interação dentro da história lá e tal… Então, a gente viu que a gente tinha esses 2 jeitos de trabalhar, e a gente fez um mapeamento para o aha, onde a gente uniformizou tudo, e a gente chama no aha, independente do… O PM ele pode continuar trabalhando de qualquer um dos 2 jeitos, mas a gente faz um mapeamento que para o aha a gente leva tudo para um nome lá e a gente meio que uniformiza. Isso tudo foi feito de maneira transparente, para o PM tanto faz ele pode continuar trabalhando exatamente igual, mas a gente conseguiu através da automatização ter essa uniformização na ferramenta, entendeu? É algo que não era óbvio para a gente, no início. É algo que a gente nem sabia se tecnicamente era possível com o aha, e a gente descobriu que era. Mas por quê? Porque a gente teve exatamente essa preocupação que você descreveu agora, né? De como é que a gente implementa algo para fazer o time evoluir sem engessar?

A: E foco, né? Porque vocês estavam focados nisso. Porque é engraçado, eu tive uma experiência terrível como aha, por exemplo. A gente tentou implementar ele na RD, isso foi sei lá, em 2016 ou 2017, não lembro, e até quase piada interna nossa lá, porque foi algo tenebroso, assim… E eu acho que tinha muito disso, de: Beleza, a gente estava tentando colocar um framework na época de como fazer… Os roadmaps estavam todos lá, estratégia, iniciativas que a gente tinha e etc. Só que tinha um custo de atualização disso que era relativamente alto e a gente não conseguiu fixar esse linear ali de tipo: Cara, até onde que eu falo exatamente como tem que ser isso? E até que ponto eu deixo livre para cada um fazer do seu jeito, e daí sempre pensando: Pow, quem vai estar lendo isso, que nem sempre era alguém de produto, a gente queria abrir isso para a empresa como todo, mas a gente não conseguiu chegar nesse ponto.

T: Eu acho que a gente não chegou aí também, onde a gente gostaria, tem um monte de problema ainda, por exemplo, essa questão de… A maneira com que o PM coloca a informação lá é algo que faz todo o sentido para o time dele, mas que para alguém do comercial não faz sentido nenhum, porque tem termos ali que a pessoa não faz ideia, ou nível de granularidade que o PM está trabalhando em cima do aha não é o que a gestão queria ver, por exemplo… Cara, a gente ainda tem esses problemas, a gente está pontualmente indo de time e time resolvendo, mas enfim… O aha, a minha hipótese por trás é de que ele só vai funcionar se ele entregar algo para o PM, se for uma ferramenta que o PM tem que alimentar e que não resolve problema nenhum do PM, então o aha nunca vi funcionar. Cada PM já tinha o seu conjunto lá de planilhas e ppts que usava para gerenciar rotina. A ideia é: Cara, então migra para uma outra ferramenta. Essa meio que foi a nossa premissa básica, assim né? Se ela não entrega valor para o PM ,então é uma documentação vai morrer.

A: Faz bastante sentido, e eu acho que como tudo né, cara? A evolução contínua da coisa ali, tipo… Ter alguém focado nisso, olhando para isso, a chance disso evoluir, por mais que comece meio torto, mas de  evoluir para um lugar onde começa a fazer mais sentido com o passar do tempo é gigantesca, né?

T: Sim! Sim! Ter um dono, claro, né?

A: Show cara! Muito obrigado! Vamos para o bate-bola? 

T: Vamos!

A: Show! Uma ferramenta de trabalho indispensável para ti?

T: Cara… Estava pensando nessa resposta, mas mindmaps. Adoro o mindmaps! De novo, né? Engenharia de controle e automação… 5 anos sendo condicionado a ligar caixinhas e criar conexões lógicas, mindmaps para mim é isso, mas eu acho que o poder do mindmap é pegar algo que está na sua cabeça colocada de uma maneira que eu consigo validar para saber se a comunicação que eu precisava estabelecer foi correta, entendeu? Então, quando eu tangibilizo as coisas no mindmap e eu falo: É isso! É isso que você entendeu da minha fala? Eu acabo confirmando, garanto que não teve nenhuma quebra. Mindmap para mim cara… Foda!

A: Qual teu principal hack de gestão de tempo?

T: Gestão de tempo? Eu sou péssimo em gestão de tempo, mas assim, uma coisa que… Nossa vai parecer muito boba… Eu abro milhares de abas, como todo mundo, eu acabo… A minha atenção divaga e tal, e aí uma coisa que eu tenho feito é… Eu abro uma janela e pego só a aba que eu quero focar naquele momento e coloco naquela janela, todas as outras abas estão abertas, mas elas ficam escondidas. Cara, é um troço tão bobo, mas mudou a minha vida… Sério, parei de me distrair com milhares de coisas.

A:  Animal! O que que tu está lendo agora? 

T: Cara… Nossa, agora eu não estou lendo nada técnico, não. Eu estou lendo… Enfim… Eu estou lendo um livro, enfim… É um livro de ficção, assim… Mas a última coisa técnica que eu li, não foi um livro, foi um material que está publicado. Essa consultoria de design organizacional que está trabalhando junto com a gente chama Target Teal, eles têm uma metodologia que chama organizações orgânicas, é O2, e eles publicam a metodologia na íntegra, eles dizem que é uma tecnologia social open source, eu acho super legal o termo que eles usam, e me debrucei em cima material e fiquei maravilhado, assim… Na verdade o tópico do momento para mim é design organizacional, e a metodologia deles que está publicada no site deles para mim é um material fantástico.

A: Show! Quais são os 3 livros que tu recomendaria para qualquer PM?

T: Cara, assim… São os que a gente recomenda para os loaders, meio óbvios, mas o Inspired, eu acho que o Inspired é maravilhoso por que… Cara… Ele te ajuda a fazer sentido de um jeito muito didático, né? Entra numa empresa de produtos, quais são os papéis ali dentro? Quais são os problemas que toda a empresa tem? O Inspired ele te dá essa visão rápida de tudo, superficial até certo ponto, mas completa… O Strategise, porque… Não tem como fazer produto sem ter uma estratégia, uma visão clara e, avaliando PMs em processos seletivos é uma das grandes deficiências, eu acho, do mercado. Então, estudar isso! E o Strategize eu acho que é um livro super legal. E cara o… Roadmap é… Roadmap Relaunched é um dos livros que eu sempre indico também, porque eventualmente, por mais que você seja do grupo que acredita, ou que não acredita em roadmap, roadmap vai bater na sua porta, em algum momento na sua carreira de gestor de produto, então que você saiba o que você está fazendo quando for montar um, se for montar um, né?

A: Quais são as tuas principais fontes de informação de produto?

T: Fonte de informação de produto? Cara… Eu tento falar bastante com as pessoas, assim. Eu tento manter bastante contato com as outras pessoas que eu conheci da comunidade… Vira e mexe a gente faz call para fazer benchmark, dos dois lados, tanto eu pedindo informações, quanto abrindo informações da OLX, eu acho que a gente tem que aproveitar esse poder da comunidade, é uma comunidade que está super legal aqui no Brasil, é uma unidade que já está bem grande, que está crescendo cada vez mais rápido e cara, é isso assim… E aí eventualmente, toda vez, é uma referência nova que através desse contato eu consigo. A Traget Teal veio de um desses contatos, por exemplo, e hoje design de organização é meu novo vício, então, comunidade. 

A: Legal! É animal! Eu acho que… Cara, eu também adoro fazer benchmarking com outras empresas e mesmo de maturidades diferentes, porque tu sempre aprende e, às vezes, são coisas que tu passou  há 5 anos atrás, está passando agora, mas… De novo, tecnologia mudou, nível de conhecimento mudou… Às vezes, o cara está resolvendo aquilo agora num ponto completamente diferente de como tu resolveu, então, acho super legal. Quem te inspirou?

T: Quem me inspirou? Nossa, que difícil essa! Quem me inspirou? Cara, eu tenho… Quando eu estabeleço mentorias também, eu sempre peço para a galera fazer um exercício, assim, de coisas que você valoriza como profissional e quais são as suas referências para isso, né? E aí eu tenho… Costumo falar que as minhas 5 referências tem um dedinho para cada uma delas, assim… E a minha primeira referência é  o cara que fundou a Chaordic, um dos caras que fundou a Chaordic, o João Bernatt, é… Cara, aquele cara é esses unicórnios aí que a gente… Um unicórnio alado, e ainda que brilha no escuro, eu acho que o João é um desses, assim. É um cara que… Extremamente inteligente, extremamente rápido no pensamento, extremamente lógico, estruturado, super técnico, mas que ao mesmo tempo quando abre a boca te inspira num nível que cara… Você quer seguir aquele cara. Entendeu? Então, assim, você respeita ele porque ele vai te ensinar alguma coisa técnica que você não fazia ideia, e você respeita ele porque ele vai levar uma empresa para um sucesso só com o poder do microfone, sabe? O João com certeza é minha primeira inspiração aí na carreira.

A: O que que é um bom PM para ti?

T: Quando a gente faz esse offsite, a gente fez uma cartinha de recepção para as pessoas e a minha chefe escreveu um textinho lá e eu complementei com uma frasezinha que eu falei: Cara, Janet, vamos comunicar isso para mim. Isso aqui é o coração de um bom PM. Cara… Eu acho que um bom PM é o que consegue, obviamente, deixar o ego de lado e agir com neutralidade, né? Pode parecer bobo e óbvio isso, mas assim agir com naturalidade, agir sem ego é quase contra a natureza do ser humano, né? O ego está ali, cumpre uma função ali para a nossa sobrevivência, é natural ele se ativado instintivamente em vários momentos, e eu acho que conscientemente você conseguir ser despir do ego é um negócio super difícil porque, de novo, é contra a natureza do ser humano, mas se não for a partir de decisões neutras, você não vai criar um produto realmente foda. Então eu acho que neutralidade, se despir do ego é o coração ali de alguém que está fazendo isso com maestria. 

A: Bom… Eu acho que cultura experimentação ajuda muito nisso, né? Tu antecipa muito esse negócio de não se apegar àquela ideia e a validação dela, naturalmente, passa a ser um KPI, um número, alguma coisa que…

T: É algo que não é você, né? Essa neutralidade.

A: Cara… Para a gente fechar, eu acredito que nesses anos todos de experiência que tu tem aí, tu adquiriu algum conhecimento, alguma coisa que… Algum aprendizado que te guia sempre… Que aprendizado foi esse?

T: Nossa… Eu só consigo pensar em alguma coisa técnica, na verdade, um conceito que eu… Que me foi apresentado quando eu estava fazendo esses estudos de designer organizacional e que agora eu costumo dizer que… Bom, para quem foi desenvolvedor sabe o que que é linguagem orientada ao objeto, eu costumo dizer que meu pensamento agora é orientado ao artefato. Esse conceito de artefato, é um conceito que quando eu me deparei assim, deu forma para um monte de coisa que não tinha forma na minha cabeça. O que que é um artefato? Basicamente, um artefato é qualquer coisa tangível na sua rotina, e que leva à comportamentos, que levam à crenças, que espelham as suas crenças, assim… Então, o que eu quero dizer com isso, né? Com essa responsabilidade de operações de produto, que é basicamente mudar a maneira com que um grupo trabalha, como é que se muda isso? Você pode tentar mudar as crenças do grupo, a partir da mudança das crenças, você espera que novos comportamentos surjam, e aí o resultado que você queria ter vai ser atingido. Mas mudar a crença é algo muito difícil. Crenças são coisas que a gente constrói e que, às vezes, a gente nem sabe que a gente tem, mas elas estão ali agindo. E a gente pode fazer esse tipo de mudança de um outro jeito que é através da implementação de artefatos, então, o que que é um artefato? Um artefato pode ser um símbolo, como descrevi a mandala da estratégia versus, simplesmente, pilares ordenados. Pode ser uma cerimônia, pode ser um título de uma newsletter, por exemplo, pode ser… Cara, milhares de coisas podem ser artefato. E aí quando eu entrei em contato com esse conceito, eu comecei a observar tudo em função de artefatos. Então quando eu entro hoje, por exemplo, numa cerimônia de planning de um time, e fico sentado bem no cantinho, só observando, eu começo a ver que o fato do gerente de engenharia puxar a cerimônia e não um gerente de produto, isso é um artefato poderoso, aquele grupo opera de uma maneira que tem como referência primária a engenharia e não o produto, isso leva uma série de decisões. Aquele grupo sempre faz uma piada e deixa o ambiente leve antes de começar, aquilo é um artefato… Meu ponto é: Eu comecei a observar tudo em termos de artefato, eu quase defino o mundo agora como um artefato. Esse conceito, para mim, é super poderoso, é o que, cara… Nossa, acho que me deu um nível de consciência que eu nunca tinha atingido antes, assim, sabe?

A: Animal! Bela propaganda de design organizacional.

T: É! Estou viciado. Falei!

A: Show cara! Muito obrigado pelo papo. Parabéns aí, pela trajetória toda aí. E continuamos nos vendo.

T: é isso daí, está certo! Valeu! Um abraço.

A: Esse e outros episódios do product backstage você encontra no iTunes, no Spotify e nos melhores players do mercado. Toda a descrição desse episódio com os livros que Belluf indicou e etc. vão estar no productbackstage.com.br. Um grande abraço e vejo vocês no próximo episódio.

Escute esse podcast pelo Spotfy clicando aqui!