Iris – Oi, gente. É o maior prazer participar desse episódio. É o maior prazer estar aqui com vocês batendo papo sobre produtos. Estou bem feliz. Obrigada pelo convite.

Iris – Para quem não conhece, eu sou a Syuri. Eu sou product lead do Nubank. A minha história começou, agora que eu parei para pensar, há mais de 10 anos atrás, eu entrei em produtos por meio de um banco, um banco bem tradicional. E na época o produto era aquela coisa bem… como posso dizer? Bem requisito de negócio, a gente desenvolvia as funcionalidades, eu cuidava por internet banking, então a gente desenvolvia os produtos e colocava no ar, mas não era a mesma coisa que desenvolver os produtos hoje. Eu entrei no Banco Votorantim como estagiária, eu era publicitária na época, fiquei 4 anos desenvolvendo internet banking, e-mail banking, aquelas coisas que na época eram super modernas, poder pegar um empréstimo online, era algo que os bancos ainda estavam começando e eu fiquei 4 anos dentro desse escopo, dessa área. Por incrível que pareça, naquela época eu falava: “Cara, nunca mais vou trabalhar com tecnologia na minha vida”, porque era muito chato. Era cuidar de produto fazendo requisito, a galera desenvolvia, testava, achava bug, entregava, mas eu não via quase resultado, porque naquela época a gente não tinha essa coisa de testar com o usuário, validar hipótese, estar muito perto do consumidor final. Com isso, eu resolvi migrar para marketing, porque como eu sou publicitária eu sentia muita falta de estar em contato com o público final. Fiquei em marketing durante 4 a 5 anos, passei por todas as etapas de marketing, até que chegou o momento onde eu também percebi que o marketing era um viés muito mais de vendas, por mais que a gente ia aprender que o marketing cuida dos 4 Pês, ciclo de vida inteira do produto, no final do dia, em muitas empresas o marketing fica só na parte da aquisição, depois de 4 ou 5 anos atuando em marketing eu comecei a sentir falta de cuidar de uma visão mais global, de uma solução. E eu consegui realmente gerar impacto nos meus clientes. Com isso, já depois de uns 8 anos no mercado, surgiu a oportunidade na empresa Invest, como product manager. Nessa etapa foi quando eu percebi o quanto a disciplina de produto tinha mudado, o quanto o mercado tinha mudado e, de repente, surgiu todas aquelas fince words de agile, design thinking, product discovery, todo esse processo novo de desenvolvimento de produtos. Dentro da Easy, foi quando realmente, de fato, eu considero que eu comecei na minha jornada de PM, porque até então, trabalhar com produtos lá atrás era bem diferente. Eu trabalhei dentro da Easy, com todas essas partes da jornada, cuidei de aplicativo. Lá eu tive a oportunidade de lançar a plataforma de renda variável do zero, uma experiência que era nova no mercado, foi uma experiência que tinha o objetivo de ajudar as pessoas a começarem a investir sozinhas na bolsa, naquela época era tudo muito novo no mercado. Até que na Easy Invest, acho que foi a minha grande escola dentro de product management, até que chegou um momento onde a Easynvest foi adquirida pelo Nubank, e no Nubank eu peguei o desafio de fazer gestão de novos PMs e cuidar de toda a experiência do App do NuInvest, que na época era Easynvest, e agora, mais recentemente, cuidar de toda a etapa de monitoramento dos investimentos. Uma longa história aí.

Iris – Para ser sincera, quando eu voltei a ser PM, na verdade, quando eu comecei a ser PM dentro da Easynvest, eu passei no processo seletivo, eu tive que botar no Google: “Ok, o que faz um PM”? Porque eu tinha passado no processo, eu sabia que eu ia trabalhar no produto, eu sabia que o que eu ia fazer era uma coisa que eu queria, por causa do job description, mas não estava muito claro o que, de fato, eu ia fazer. E mesmo depois que eu entrei, levou alguns meses para eu descobrir exatamente o que um PM deveria fazer. Justamente porque não tem uma definição muito clara e depende muito do cenário de cada empresa. Eu acho que as premissas que a gente tem que assumir aqui, o product manager e a definição de Marty Cagan, que todo mundo já deve ver o inspired, enfim, mas eu acho que ele simboliza bem onde ele fica localizado, que é ser a ponte entre negócios, entre consumidor final, o cliente, entre tecnologia. Mas o que significa ficar nessa ponte? O PM é responsável por todo o ciclo de vida do produto. O produto tem desde a integração, a gente coloca no mercado, a gente vê se o mercado quer esse produto mesmo, ver se tem product market fit, começa a crescer até o momento de cair, até o momento de declínio. O product manager é responsável por todo esse ciclo de vida do produto e pelos resultados que ele vai gerar. O que é o resultado? O resultado de um produto é o valor que ele agrega para o negócio e o valor que ele agrega para o cliente. Não existe produto com sucesso se você não tiver atendendo uma necessidade muito latente do cliente, você tem que conhecer o cliente muito bem. Sendo responsável por um produto, sendo responsável pelo resultado do produto, o que um PM tem que fazer? Bom, ele tem que entender bem dos negócios, então ele tem que entender do objetivo do negócio, ele tem que entender aonde a empresa vai, tem que entender do mercado, ele tem que entender o quanto aquele produto que ele está liderando se conecta com a estratégia maior do business, ele tem que entender muito bem do cliente, qual cliente que o produto vai atender. Entendendo o cliente, saber quais são os problemas, quais são as dores que esse produto vai resolver. Porque, como que eu vou criar um produto sem saber o que ele vai estar resolvendo? Qual é a dor latente que ele vai estar atacando? E ele tem que conseguir fazer essa ponte de tecnologia, porque ele não desenvolve nada sozinho. Ele consegue juntar os insumos de business, juntar os insumos de consumidor e do cliente, e pensar em fazer dinâmicas de ideação para uma solução, mas quem vai realmente desenvolver e colocar no ar, e saber se é factível e saber se é viável é o time de tecnologia. E ele precisa se comunicar com o time de tecnologia para conseguir passar essa visão. Então o PM faz muito esse papel de conexão, comunicação, alinhamento. Mas a principal responsabilidade para ele, ao meu ver, é ele ser responsável pelo resultado de um produto ou de uma jornada do produto, ou de uma etapa, ou dentro de um contexto específico de um produto que já existe. Aí vem aquela coisa: A diferença de PM e PO.

Iris – Depende do cenário. O PM é o responsável, inclusive, pelo resultado do business. Ele tem tanto domínio do negócio que ele acaba cumprindo esse papel de dar a visibilidade. Quando ele não é essa pessoa, ele tem que, pelo menos, estar muito bem alinhado com o responsável de business para conseguir passar essa visão. Para mim, se a gente for olhar o desenvolvimento de um produto, qual é o principal risco que a gente tem? Do produto não funcionar. Então, risco de usabilidade, risco de valor, risco técnico de se realmente a gente vai conseguir fazer ou não, e o risco de business. Todo o processo de visão disso tudo, de aonde a gente quer chegar, de dar direcionamento, qual é o resultado que a gente espera, deveria vir do PM. Na prática, é o direcionamento, a visão, o que esse produto vai resolver para aonde a gente quer chegar? Aí, quando a gente começa a partir de: Ok, para a gente chegar lá, a gente precisa ter todo o mapeamento das oportunidades e todo o mapeamento das soluções. Mapeamento de oportunidades, eu acho que pode vir tanto de tech, quanto de product designer, UX, quanto do próprio PM, quanto das áreas parceiras, business, etc., para a gente conseguir mapear oportunidades para chegar nos objetivos de produto. Agora, na etapa da solução, eu acho que cada um acaba tendo uma responsabilidade muito específica. Então, reduzir risco de usabilidade, reduzir risco de realmente ter uma experiência que o usuário queira usar, para mim é 100% responsabilidade do product designer. Ele pode ajudar, ele pode coordenar, enfim, ele pode trocar, pode pegar insights, enfim, mas acho que durante todo o processo, o trabalho pode ter muita colaboração, o processo inteiro eu acho que ele é colaborativo, mas chega em alguns momentos que eu acho que eu consigo ver algumas coisas que são mais específicas de cada uma das disciplinas. Então, acho que product designer, para mim é muito responsável por garantir que essa solução que o grupo deu em conjunto, o usuário vai querer usar, ele vai conseguir usar, ele vai ter uma experiência boa. Quando a gente fala de reduzir o risco de valor, o usuário vai querer? A gente está realmente atendendo uma dor? Eu vejo também muito uma responsabilidade de product designer, mas também acho que é do PM, porque se o PM não souber qual dor ele está resolvendo, se ele não tiver uma certeza mais clara do valor que ele está agregando, ele não está cumprindo o papel dele. Então, acho que esse risco de valor, acho que o product designer e o PM, eles trabalham muito juntos. Para mim o tech lead é o responsável por ajudar a saber se é viável ou não, tecnicamente. Então, às vezes, o PM pode tentar ir lá e por conhecimento do background técnico, saber se aquilo é possível ou não, no time que é possível ou não, mas querendo ou não, isso não é responsabilidade dele. O tech lead, para mim, deveria ser a ponte entre aquele produto que a gente está criando e saber como a gente vai fazer esse produto, como a gente vai desenvolver, e até ajudar a entender qual time que a gente vai conseguir, seja por histórico do time, seja pelo know how do time que a gente já tem agora. E assim eu vejo quando a gente fala de definição de papeis. Agora, significa que cada um fica na sua caixinha? Não. Durante todo o processo de discovery, que é identificar as oportunidades que a gente vai atacar, priorizar as soluções que fazem mais sentido e discutir em conjunto, para mim eu vejo as três trabalhando muito próximo. Agora, o que diferencia o PM? O PM tem que garantir que isso aconteça. Então ele acaba tendo que ter a responsabilidade de dar direcionamento e garantir que o processo inteiro aconteça, e que as coisas estão funcionando. Ele acaba tendo que alinhar as pontas. Isso eu não posso esperar, por exemplo, do tech lead, eu não posso esperar que o tech lead vai dar a visão de produto, e que ele vai garantir que vai ter processos de discovery, não, esse é o papel do PM. Agora, quem participa em cada momento e como as coisas acontecem, eu acho que o ideal é que sempre seja de uma forma super colaborativa. Aqui no Nubank a gente não tem esse papel de tech lead, especificamente, na Easynvest a gente tinha. Aqui o time de desenvolvimento participa bastante das discussões, a gente tem outros papeis também, que é business analyst, business architect, enfim, então sempre são muitas pessoas que podem acabar colaborando com todo o processo. No final do dia o ponto é: O PM tem que garantir que as coisas aconteçam, e que aconteçam no time certo.

Iris – Olha, eu já vi duplas que não funcionaram e duplas que funcionaram. A composição premissa que fica claro para mim que quando funciona ou não funciona, o primeiro ponto é alinhamento e definições de quem faz o que, quando, como, onde, e a criação de uma relação de confiança entre essas duas partes. Então, duplas de designers e produto que eu vi que não funcionaram. Não era nem pelo escopo, não era nem pelo desafio, era pela falta de ter uma relação de confiança, onde a gente entende que tem o mesmo objetivo, e aí cada um vê como que pode colaborar. Se a gente fosse falar no “pé da letra” o que o PM faz e o que o designer faz, a gente poderia pegar cada empresa no modo, de um jeito diferente, mas no cenário onde o PM é responsável por dar um direcionamento, por trazer a oportunidade, e o product designer é o responsável por toda a ideação da solução, seja a condução da dinâmica, seja trazer as pesquisas, seja ir lá falar com o cliente, esse já foi o mesmo modelo que eu já vi. Já vi outros modelos onde o PM entra mais a fundo no discovery, ele conduz as dinâmicas e o product designer ajuda, em parceria, trazendo os insights e conduzindo a solução. E eu já vi exemplos onde o product designer acaba entrando só na solução e prototipação. Esse é o último caso, que é o que eu não recomendo para ninguém, eu acho que é o processo mais errado que, às vezes, acontece em algumas empresas. Para mim, product designer e PM têm que trabalhar juntos desde o começo da ideação das oportunidades, porque o product designer entende muito bem do cliente, o papel dele é entender o cliente, é entender as dores do cliente, é trazer boas provocações para a gente conseguir chegar no resultado. O papel do PM é entender do business, é entender do negócio, também entender do cliente e do valor que você está gerando para o cliente, e juntos eles trazerem as oportunidades. Agora, o que eu acho que não funciona é: Justamente por ter esse overlap, os dois não conseguirem chegar num acordo de trabalho, de qual vai ser a responsabilidade de cada um em cada etapa. Ou então, da empresa mesmo ter isso muito bem claro. Em alguns cenários, qual que é o grande ponto? Às vezes, você vai achar o cenário em que o PM é um pouco mais júnior e o designer é super sênior, aí nesse cenário, não vai ser o PM que talvez vai direcionar e fazer todas as dinâmicas e aquelas coisas. O designer vai lá e toma a proatividade, ele vai lá e faz a coisa acontecer. E não está errado, está tudo bem, é só ter um acordo, é só ter ensinamento: Quem está mais apto, ou quem tem mais conforto em fazer todo o processo. Tem que garantir que existem dados que reduzam os riscos de que aquele produto ou aquele caminho está fazendo sentido. Agora, na prática, acho que vai depender de cada uma das empresas e a maturidade de cada uma das disciplinas, mas acho que o principal é garantir essa relação de confiança e esses alinhamentos.

Iris – Isso é bem complexo.

Iris – Olha, eu atropelei, e aí é o grande ponto. Eu já passei por dois cenários. Eu tinha um cenário onde todos os PMs que a gente contratava eram PMs sêniores, porque é isso, o cargo exige uma complexidade de gerenciamento, de expectativas, alinhamento, comunicação, gestão de equipe por influência. Na verdade, não é nem gestão, acho que é muito mais motivar a equipe ou influenciar a equipe, sem ter uma gestão direta, envolve uma série de hard skills com soft skill, que uma pessoa em um começo de carreira não consegue cumprir. Só que qual é o problema? Você vai para o mercado, você só busca pessoas sêniores, e chega um momento que você não encontra pessoas sêniores para, às vezes, os desafios que você tem. O que eu achei legal aqui no Nubank, você tem uma letter muito específica, e que permite que você tenha product managers mais júniores, ou APMs. E qual é a diferença? Eu acho que é o contexto que você vai colocar ele e o nível de ajuda que ele vai precisar. Então, por exemplo, aqui no Nubank o product manager mais júnior, ele deveria estar no contexto bem controlado, ser muito bom, pelo menos, na parte da execução, conseguir lidar muito bem com comunicação, mas ele vai ter skills a serem desenvolvidos, por exemplo, em product discovery, porque ele não tem esse know how. Geralmente, quando eu começo a ver PMs entrando em começo de carreira, a maior parte começa com product owner. No sentido de, sabe aquela treta de nomenclaturas? A maior parte começa só no delivery da solução, digamos assim. Por quê? Porque é um caminho fácil, mais fácil talvez para as pessoas começarem. E vejo poucos PMs começando por business, que foi, inclusive, um pouco do meu caso, foi mais porque eu já conhecia o know how de investimentos, mas eu acho que a maior parte, o caminho mais simples para você começar é na execução do delivery, até você conseguir ir aumentando os seus skills, o seu know how. Então, acho que não tem como a gente esperar que a gente tenha realmente o PM sênior em todas as posições, eu acho que a diferença é como a gente dá desafios controlados e pequenos para que as pessoas possam se desenvolver. Às vezes, você coloca o PM numa etapa específica da jornada: Especificamente, o objetivo dele vai ser aumentar a conversão dessa etapa A e etapa B. Eu tenho o resultado claro, eu tenho o escopo controlado, ele vai conseguir estar lá dentro, às vezes, num time que já está mais maduro e vai pegando a experiência, com isso ele vai se desenvolvendo. Não vai ser o mesmo PM que eu vou colocar no desafio de criar um produto do zero, por exemplo. Então, acho que o papel de coordenação entre disciplinas, a gente consegue ir controlando, conforme o escopo. Eu acho que o grande ponto é as premissas que a gente já tem que ter, os skills, os soft skills já tem que estar na pessoa, mesmo ela não tendo conhecimento técnico. Então, não dá para ter um PM, mesmo que júnior, que não goste de falar com pessoas, que não goste de interação, que não tenha empatia, que não goste de ir atrás de dados e mergulhar em desafios, porque é isso que ele vai fazer nessa vida. E tem soft skill que a gente não consegue muito bem ensinar. Então, acho que tem esses caminhos de evolução, desde que, pelo menos, as pessoas tenham o soft skill necessário para a posição, que é conseguir lidar com ambiguidade em cenários mais genéricos e complexos, e sempre focando muito nessa parte de lidar com pessoas, empatia e comunicação.

Iris – Olha, é uma boa essa. Realmente, eu acho que tem alguns cenários onde o tech líder é responsável pela entrega, pelo engajamento do time e tudo. Em muita empresa, o PM faz o papel de organizar as histórias do que ele quer e vai para o time terceiro desenvolver, e aí ele acaba não estando dentro do time, aí não tem como ele fazer essa gestão mais por influência e tudo mais. É um caminho pelo o qual eu vejo vários PMs, às vezes, começando, principalmente em empresas um pouquinho mais engessadas, onde não tem squads, onde é mais uma fábrica de softwares e tem o PM só direcionando o que tem que ser feito. Eu acho que o problema disso, eu acho que não é nem a questão de: “Ah, você não está gerenciando as pessoas ou não”, eu não acho que o PM tem que gerenciar ninguém, a não ser que ele seja líder e aí ele tenha PMs abaixo, por exemplo, mas ele tem que conseguir liderar por influência. O que isso significa? Você tem o produto e eu tenho o objetivo, eu tenho o time que vai me ajudar a saber se esse produto está fazendo sentido, eu tenho esse time que vai me ajudar a construir esse produto, eu tenho esse time que é quem, de fato, vai entregar o resultado, porque o PM é só o coordenador da iniciativa. Se ele não consegue ter um soft skill de entender as pessoas, de motivar, de influenciar, ele não vai conseguir cumprir o papel dele. Então, ele pode não ser o gestor específico, mas essa skill de conseguir entender as pessoas e tentar trazer motivação para um objetivo específico é muito importante, porque, senão, vai acabar com que ele, provavelmente, vai tirar a solução de algum lugar, seja dos stakeholders. O grande problema que a gente vê, um bando de top down que vem aleatório, chega no PM, a gente não tem controle e entrega uma coisa que não tinha testado e vira uma bola de neve. A gente partindo do pressuposto que todo produto que a gente constrói deveria resolver um problema, deveria atingir o resultado, e meio para a gente conseguir isso é por meio de, na junção de disciplinas, que é isso que faz a diferença, a inovação e é isso que vai fazer com que a gente consiga entregar o produto mais rápido, com mais qualidade, inclusive, que a gente consiga testar mais rápido, o PM acaba tendo que fazer um pouco esse papel. Senão, acaba caindo naquela coisa de projeto. Senão, às vezes, acaba caindo um pouco nessa zona de projeto. São 50 mil requisitos, o time vai lá, desenvolve no canto dele, demora um tempão, vai entregar, descobre que não era o que precisava, enfim. Acho que no final do dia é tudo sobre motivação e engajamento mesmo das pessoas.

Iris – Acho que se você não tiver um objetivo muito claro, resultados muito bem alinhados do que é esperado, é ali que geralmente começam os problemas. Porque se a gente partir do pressuposto que a gente tem um objetivo em comum como um time, a gente tem o resultado esperado, significa que a gente vai medir aquilo que a gente vai fazer, e essas medições deveriam levar a gente aonde a gente quer chegar. Boa parte dos momentos, onde a gente está nesse “apaga incêndio”, muitas vezes é porque a gente não tem o objetivo muito claro, então o time fica lá com o escopo qualquer, do tipo: “Ah, vou cuidar de relatórios”. Qualquer coisa pode ser relatório, qualquer necessidade pode surgir para o time, e o time vai acabar sendo só um executor de tarefas, ele não está desenvolvendo produto, ele está executando tarefas que a gente nem tem a certeza do porquê, qual resultado que vai atingir, aonde vai levar isso. Eu acho que o primeiro ponto para a gente sair desse ciclo, é primeiro a gente conseguir definir muito bem aonde a gente quer chegar, ter essa visão de objetivo, ter essa visão de missão e ter o resultado acordado com stakeholders. Porque se você não acordar tudo isso, você acaba virando um tirador de pedidos. Então, realmente, alinhar com todo mundo: “Ok, esse é o time, essa é a missão, esse é o resultado que a gente vai esperar buscar para esse semestre”, que seja por OKRs, KPIs, algum tipo de métrica que a empresa atinja. A partir daí, tudo que é pedido deveria ser refletido, o PM deveria ter esse papel de pegar e validar 10 mil vezes se aquilo realmente que está sendo pedido, primeiro, se leva para o resultado que o time já tinha traçado e alinhado. Porque eu acho que a base é o alinhamento com stakeholders e com todos os envolvidos, levantado todos os riscos, seja de desenvolvimento, seja de design, seja de valor, para a gente saber se faz sentido mesmo. Aí com base nesse embasamento, conseguir argumentar e trazer, e propor outras coisas. Acho que enquanto a gente não tem isso claro, enquanto não tem objetivo claro, enquanto não tem o resultado claro, é muito fácil a gente acabar nesse “tira pedidos”, e aí é onde a maior parte dos times acaba se perdendo.

Iris – Acho que comunicação constante. E aí é um pouco o papel de produtos fazer constantemente alinhamentos. Eu vejo acontecer erros, inclusive, eu já cometi: “Ah, alinhamos o começo de semestre. A gente vai buscar tal resultado e vamos por esse caminho”, mas no meio do semestre várias coisas surgem, a gente muda de caminho, a gente muda de roadmap, as coisas se adaptam e a gente esquece de fazer esses realinhamentos e ir avisando o caminho que a gente vai chegando. Então, a gente só consegue autonomia se a gente tiver muita confiança no time e no caminho que as coisas estão vindo, mas se tiver também muita comunicação. Acho difícil dar autonomia, sem que exista a comunicação. Então, tem “N” formas que a gente vem tentando e acho que não tem nenhuma empresa que resolveu todos os problemas de comunicação do mundo, mas, pelo menos, acompanhamentos de stakeholders de resultados, seja uma vez por mês, seja a cada “X” frequência que faça sentido, eu acho que ter a flexibilidade de mostrar os caminhos. Se eles forem mudar, por que mudaram? E a empresa também conseguir entender de que as coisas não são cavadas em pedra, e que a empresa tenha uma cultura que permita também errar, porque eu acho que grande parte dos problemas hoje que acontecem é: A gente estabelece um caminho, a gente começa a seguir, mas no desenvolvimento do produto a gente vai descobrindo um monte de coisas que a gente tem que mudar, seja por time, seja por questões de resultado mesmo, que a gente bota no ar e percebe que não tem, seja porque surgiu uma informação nova. Então, o roadmap tem que ser vivo, ele tem que ser flexível, ele tem que ser adaptável. Só que para isso acontecer, tem que ter muito alinhamento entre PM, o time, e o stakeholder management, para que não seja uma surpresa: Combinamos A, depois de seis meses eu descobri que foi feito B, enfim, ou o time toma um caminho que ninguém sabia. Eu acho que no final do dia é: Como que a gente toma o cuidado de manter esses check points ao longo de qualquer ciclo? Seja em seis meses ou ao longo de três meses? Dependendo de qual foi o combinado, para que todo mundo entenda o porquê das coisas. Acho que o final do dia é: Todo mundo tem que entender o porquê.

Iris – A gente passa o dia tomando café, comentando sobre Big Brother. É isso aí.

Iris – Olha, não tem bala de prata não, porque eu acho que conflitos existem constantemente. Eu vou falar uma ferramenta mínima, que eu falo para todos os PMs dos meus times, e eu tento usar também, é o feedback constante de alinhamento. Então, acho que o primeiro ponto de conflito, geralmente começa porque eu não entendo o que você quer dizer, eu interpreto de uma forma errada, às vezes, as pessoas estão falando a mesma coisa, o mesmo objetivo, com palavras diferentes, mas por questão de tom, por questão de qualquer outra coisa, até ego, às vezes, as pessoas não se entendem e eu preciso escalar. Eu acho que o primeiro ponto, o feedback deveria fazer parte da cultura, e principalmente, num time que é multidisciplinar, num time que a gente tenha a premissa que seja colaborativo, num time que a gente entende que ela vai trabalhar com cocriação dentro do processo. Falam que os times mais performáticos são aqueles que a gente tem o ambiente seguro. Ambiente seguro, o que significa? Não é só um ambiente onde eu consigo falar da minha vida, falar da minha família e tal, é um ambiente seguro também que você consegue expor as suas ideias, se sentir ouvido, argumentar, discutir e também, a gente coloca aqui o disagree and commit. Talvez as suas ideias não vão ser seguidas, não vai ser a principal, mas uma vez que o time resolve esse caminho, você se compromete. Então, o primeiro ponto que a gente, pelo menos, tenta trabalhar bastante aqui é a questão do feedback. O time em si tem que ter essa cultura de estar aberto para ouvir, dar feedback, evoluir, ter empatia e tentar se resolver. Não resolveu, ainda temos conflitos e não sabemos como tirar: A ferramenta que eu vejo usarem bastante é a Matriz Raci, então tem que ter um tomador de decisão. Se não tem um tomador de decisão, por exemplo, no time muitas vezes o tomador de decisão é o PM, quando se fala do direcionamento do produto. Ah, não, mas a gente chegou no impasse técnico, por exemplo, aí é muito mais a escala de quem que seria o tomador de decisão. Então, se a gente fosse olhar hoje, por exemplo, nos times que a gente tem hoje, dentro do time você tem lá as disciplinas, o PM deveria conseguir fazer com que as pessoas cheguem no consenso, ou então no limite, ele toma a decisão quando é decisão de produto. Se for uma decisão técnica, a gente escala para quem é o líder de tecnologia dentro daquela ameaça, por exemplo. Acho que o primeiro ponto, garantindo que tenha feedback, garantindo que a gente tenha o ambiente seguro para troca, porque acho que para mim essas são as duas premissas. Se não tem isso, sempre vai ter conflito e o caminho vai ser sempre escalar. Mas acho que garantindo essas duas primeiras premissas, depois na terceira tendo uma matriz clara de tomada de decisão, é isso. Não chegou no impasse, simplesmente escala. O ponto é: A escalação não deveria ser uma coisa vista como uma forma extremamente negativa: “Oh, meu Deus, não fui escutada”, nem nada. Isso também deveria ser parte do processo da empresa, até para proteger um pouco os níveis de estresse e ansiedade. Então, saber o momento onde: Ok, eu tenho essa visão, você tem essa outra, não chegou no acordo? Beleza, escala, porque é isso. Olhando dentro da estrutura, a gente consegue colocar dentro do processo tomadores de decisão, às vezes, a gente consegue também aliviar a tensão que se forma dentro do time, porque quanto maior a tensão, às vezes, também acaba sendo mais difícil de reverter lá na frente, o trabalho de team building acaba sendo um pouco maior.

Iris – Eu acho que a premissa é: Tem que ter empatia, tem que gostar de falar com pessoas, tem que gostar de entender o usuário. Tem que gostar disso, porque a vida dele vai ser estar no meio de ambiguidade, de várias áreas pedindo coisas, várias áreas mandando demanda, vários clientes reclamando. Então, tem que ser uma pessoa que goste de estar nesse meio um pouco mais caótico, que goste de estar em lugares onde a solução não vai estar clara e que ela vai ter que ser a responsável por ir lá e resolver os problemas. Aquela coisa do novo the problem, sabe? Então tem que ser alguém que gosta de fazer as coisas acontecerem e que está aberta, curiosa, ter uma curiosidade nata, mas que está aberta para aprender e para evoluir. Porque não existe produto se você não tiver que interagir com as pessoas, então a comunicação tem que ser muito boa, a empatia tem que ser muito boa, saber ouvir tem que ser muito importante. E se não existe produto, se você não tiver uma curiosidade nata pelo cliente, por resolver um problema, ir lá e testar, e fazer acontecer, eu acho que um grande ponto também, falando de soft skill, é a questão de você conseguir se adaptar rápido e ser flexível para as adaptações. Porque se a gente vai testar uma coisa e não dá certo, você tem que ser rápido para trocar. Você está num ambiente muito complexo, que as coisas mudam. Uma hora você está lá no produto, surge uma demanda inesperada, e sim, às vezes, você tem que mudar o seu posicionamento rápido, o mercado, às vezes, lança uma coisa que você não está esperando e você tem que mudar a sua estratégia. Então, saber ser flexível, saber se adaptar aos cenários também, eu acho que é um super soft skill que qualquer PM deveria ter.

Iris – Eu ia falar: “Meu filho, ninguém consegue não. Está todo mundo no mesmo barco”. A gente tinha muito disso também. Eu, pelo menos, sementinha: “Nossa, quando eu entrar no Nubank vai ser tudo lindo, maravilhoso e etc.”, nenhum processo de criação de produto é lindo e maravilhoso, acho que tem processos que são um pouquinho mais azeitados para o cenário deles e processos menos azeitados. Mas mesmo no Nubank, a gente tem mais de 5 mil pessoas hoje dentro da empresa, cada BU faz o seu processo de um jeito que acha que é melhor para o cenário deles. No nosso caso aqui, dentro de investimentos, a gente está criando os nossos próprios processos de criação de produto, a gente também está em fase de construção. O grande ponto é: Não existe o processo ideal, toda hora que se cria um processo, depois de rodar um tempo você vai perceber melhor, é a base da atividade. Mas acho que para tranquilizar todo mundo, no final do dia o que vai fazer a diferença é o quanto a sua empresa, o quanto o seu time, vocês estão abertos para criarem processos que são focados na criação de produto, em escutar o cliente, em mensurar resultados. Se a sua empresa não está aberta a isso, não quer nem ouvir sobre pesquisa, sobre validação e não tem nem métricas, não adianta processos que isolou, porque vai muito mais no core da cultura. Agora, se a cultura está no lugar certo, se a mentalidade do diretor está no lugar certo, ele sabe da importância, ele sabe o que tem que ser feito, ele só não sabe como, resolver com processos eu acho que um dos menores problemas, digamos assim.

Iris – Obrigada pelo convite, foi um prazer. Da próxima vez quero encontrar vocês pessoalmente, porque faz tempo que eu não vejo pessoas pessoalmente, do trabalho. A gente está 100% home office, está difícil para a gente tomar uma cerveja, a gente bate mais papo, porque ainda tem bastante coisa para a gente trocar. Obrigada mesmo pelo convite.