Essa é a transcrição do podcast “Episódio 14 –  “Product Development com Rafael Dahis”. O link para ouvi-lo está no final desse conteúdo.

Rafael Dahis é o convidado do 15º episódio do nosso Product Backstage. Carioca, formado em Engenharia, resolveu no final da faculdade criar um produto próprio, assim surgiu o interesse e a paixão de trabalhar com produto, já que o seu plano, a princípio, era trabalhar com engenharia.

Depois de formado Rafael começou a trabalhar em startups como PM, trabalhou na Orma, Peixe Urbano, Twitter, Facebook, e hoje trabalha como product lead no Instagram. Sua principal missão é trazer e receber novos usuários para dentro da plataforma.

Nosso papo é uma verdadeira aula sobre produto, conversamos sobre a carreira do Rafael, senioridade de PMs, onboarding, estrutura de times, como conduzir um processo de desenvolvimento de produto e muitos outros assuntos.

A: Sejam muito bem-vindos a mais um product backstage. Hoje eu tô aqui tendo a honra de entrevistar o Rafael Dahis que trabalha hoje no Instagram como product lead, e a gente vai bater uns papos super bacanas sobre as experiências dele e sobre gestão de produtos de uma forma bem ampla. Então, Rafael, cara, muito obrigado por ter aceitado meu convite, é uma honra te ter por aqui e já começa a te fazendo uma pergunta aí pra entender como é que foi essa tua trajetória cara, até chegar no Instagram?

R: Obrigado, antes de tudo assim,  super obrigado por conectar e me fazer esse convite de falar com vocês. Acho que desde que eu me mudei, eu tenho me mantido em contato com as startups, com as empresas do Brasil, e é muito legal um tipo de podcast desse que é bem alto nível e bem focado já em problemas complexos de quem tá trabalhando no dia a dia de PM. Muito animado de fazer parte disso e poder contribuir. Hoje em dia, como você falou, eu sou product lead no Instagram… Eu já tô há mais ou menos 6 anos agora, no Instagram da mais recente pro começo, no Instagram eu cuido… Basicamente, o problema que eu tô tentando resolver é como a gente vai trazer e receber os próximos um bilhão de usuários na nossa comunidade, então, qualquer usuário de internet que não tá usando o Instagram hoje em dia é o meu foco, e é diferente de qualquer outro PM ou product root do Instagram, porque normalmente um PM vai tá focado em usuários, provavelmente dentro das outras plataformas, e eu tô focando naquelas pessoas que não tão usando. Então o meu trabalho é tentar entender quem são esses não usuários e como que o Instagram pode realmente fazer parte da vida deles no dia a dia, pode agregar valor tanto na conexão com os amigos quanto na conexão com os interesses deles. E posso falar um pouquinho mais sobre isso depois. Como eu cheguei aqui? Bom, fiz faculdade de engenharia e tava preparado pra trabalhar com engenharia, com machine learning, eu tava muito interessado nessa área e aí já no final da faculdade eu resolvi criar um produto próprio, criar um produto meu mais como projeto final da faculdade e aí me apaixonei, aí falei: cara, vou mudar de planos! E eu na verdade quero fazer isso, eu quero construir produto, pensar de uma maneira geral em trazer alguma coisa nova e resolver o problema pros usuários, e como eu trago isso pro mercado, como eu consigo o maior número de usuários possível pra minha plataforma. Então esse produto era um produto assim, universitário vamos dizer assim, era chamado Carrasco na Mata, um produto de avaliação de professores feito quase que em módulo de Hackathon mesmo, mas aquilo que realmente despertou o meu interesse e me fez decidir entrar nesse mundo de produto. Depois disso, assim que eu me formei comecei a trabalhar com startups, já como product manager, eu trabalhei na Orma e no Peixe Urbano, ambos em fases iniciais e em fases de growth, pra mim foi uma super experiência, e um pouco depois disso foi, na verdade, quando eu fiz essa mudança pra começar a trabalhar com essas empresas do Vale do Silício. Eu comecei a trabalhar com o Twitter, inicialmente focado no Brasil e trabalhando do Brasil e eventualmente me mudei pra São Francisco, pro headquarters aqui, e depois por aí vai. Fiquei uns 3 anos, montei uma startup em São Francisco, eu tive essa experiência de como é também criar uma coisa do zero e começar uma empresa daqui, foi super interessante, não deu certo mas é uma das experiências mais assim… É… Enriquecedoras que eu poderia ter tido, e depois disso, quando a empresa começou a não dar certo, eu fui pro Facebook e dentro do Facebook fiz essa mudança pra trabalhar no Instagram. Então mais ou menos a trajetória de uma maneira geral dos últimos, sei lá, 10 anos, mas eu posso falar de qualquer momento em particular que faça mais sentido ou que seja mais interessante pro pessoal.

A: Show! Cara, eu acho que… Eu vou pegar, enfim, começando um pouco mais lá de trás só pra confirmar, a engenharia que tu fez foi engenharia de computação, certo?

R: Exatamente. Sim! 

A: E no Rio? Tu é carioca?

R: Sim, fiz na UFRJ, no Rio.

A: Legal! E daí eu queria pegar um gancho mais nessa tua transição de Peixe Urbano pra Twitter, como é que tu fez isso acontecer? Enfim, como que isso aconteceu pra ti?

R: Acredite se quiser, mas tudo começou com cold email, foi literalmente mandando um email na cara de pau, 100% brasileiro, não tenho nada a perder. Eu tava no LinkedIn, sei lá o que eu tava vendo, encontrei o perfil de um vice-presidente do Twitter, simplesmente o cara botou no perfil dele: estou contratando e aqui tá o meu email. Eu falei: não tenho nada a perder, mandei email pra ele e falei: oi, sou o Rafael, eu moro no Brasil, eu faço isso aqui, tá aqui o meu currículo e obrigado. E aí, não tava nem esperando muito, mas esse vice-presidente respondeu, e não só respondeu como também encaminhou o meu currículo pro diretor que tava embaixo dele e falou: dá uma olhada no que a gente tem aí de interessante. O diretor compartilhou o currículo com o Broke Product Manager que falou: o que você tem aí… E por aí vai. E fui construindo essas conexões com o Twitter. Acabou que naquele momento nada foi muito pra frente, muito por conta de questão de imigração, e até pra quem pensou ou tá pensando em um dia se mudar, não é fácil, e tem que sempre considerar essa dificuldade que é o fato do visto, mas enfim… Tava trabalhando no Peixe Urbano, tava feliz no Brasil, 6 meses depois, mais ou menos, uma das pessoas que eu conheci entra em contato comigo falando: olha, Rafael, a gente tem uma vaga que é pra você basicamente, a gente tá contratando um PM pra ser o líder de growth no Brasil, só tem um problema, você eventualmente teria que se mudar aqui pra São Francisco… Aí eu falei: cara, problema não é, sempre foi o meu sonho, eu já tinha até vindo pra cá conhecer e conversar com várias empresas… Eu falei: maravilha, essa vaga vai ser minha. Eu passei pelo processo normal e comecei a trabalhar, passei nesse processo sem esperar o visto, esperar estar pronto pra me mudar, eu passei um ano e meio mais ou menos trabalhando dos escritórios do Brasil, foi super super interessante. Eu comecei em São Paulo, que era basicamente um escritório recente do Twitter, que era uma escritório de vendas, começando ali naquela época, acho que no começo tinha umas 10 pessoas, acho que hoje em dia deve ter quase 100 pessoas, e depois de uns 3, 4, 5 meses surgiu a oportunidade de começar um escritório no Rio, então era basicamente eu e mais uma pessoa numa salinha de coworking, literalmente fazendo a fundação do que eventualmente seria um escritório do Twitter no Rio de Janeiro, e eu obviamente abracei a oportunidade, voltei pro Rio enquanto ainda podia curtir esse meu último ano no Rio antes de me mudar pra São Francisco. E foi super legal até, porque hoje em dia, até hoje em dia mesmo eu continuo usando muito essa experiência que eu tive de trabalhar com escritórios locais e ter essa experiência… O que que é estar num escritório de sales, o que é estar num escritório que não é o escritório nave mãe, vamos dizer assim, de uma empresa, e até hoje quando eu passei pelo Facebook, e hoje em dia no Instagram acabo sendo um pouco essa ponte, então tem alguma conversa com a história da França no que diz respeito a produto, growth, eu vou ser esse representante, tem muita conexão com histórias do Japão, da Índia e por aí vai, e acho que muito disso vem com essa empatia que eu criei de entender como é que é realmente o trabalho, o dia a dia e o mindset de um escritório que tá fora do headquarters, e é uma paixão minha que eu graças a Deus continuo podendo continuar envolvido nesse tipo de tópico.

A: Animal! E cara, tu teve uma trajetória de super sucesso, tá tendo uma trajetória de super sucesso nos EUA, especificamente mais um em bay area, então como tu falou, Twitter, Facebook, Instagram, empreendendo aí também e etc. e também tu teve uma passagem super bacana aqui no Brasil, Peixe Urbano e tudo mais, e fora as consultorias que eu sei que tu dá aqui no Brasil e mentorias e etc. então eu acho que tu tem uma visão muito legal desses dois mercados, como é que tá a disciplina de product manager nos EUA e Brasil, e queria ver de ti como é que tu enxerga essas diferenças, se é que tu enxerga alguma coisa entre Brasil e EUA, e se enxerga que diferenças são essas?

R: Legal! É inevitável comparar, e obviamente que é uma pergunta que é muito comum, assim, sempre que eu converso com alguém do Brasil, e eu acho que eu… Pra começar, eu não vejo diferença em pessoas, primeira vez que eu vim pro Vale do Silício achei que eu iria encontrar as pessoas mais inteligentes, sagazes do mundo e que era completamente outro nível… E não. Na verdade, as pessoas no Brasil são extremamente muito melhores até do que as pessoas que eu trabalho aqui, então pra começar, acho que isso é muito importante lembrar, acho que não é uma diferença de pessoas, não é uma diferença de cultura. Eu nunca vou falar assim: o brasileiro é isso e o americano é isso, acho que não é bem por aí, mas existe algumas diferenças na maneira de si trabalhar e como esses PMs se organizam, que eu acho que não tem a ver com a cultura de um país ou de outro ou…  Ou nada, obviamente, a ver com a sociedade. Acho que em termos de empresa… No Vale do Silício, em particular, existe uma cultura muito forte de incentivos e amarrar muito bem os incentivos pra todo mundo que trabalha numa empresa, isso vem desde você dar equity dar ações pra todo mundo que trabalha na sua empresa, pra realmente todo mundo se sentir dono, quanto na prática, no dia a dia, literalmente criando uma empresa em que todo mundo tem espaço e que inovação pode vir de qualquer lugar, em que a hierarquia ela existe são pra ter uma certa estrutura de coordenação, mas ela não previne nenhum tipo de ideia que venha de qualquer lado da empresa, até isso eu acho muito interessante, uma coisa que obviamente hoje em dia no Brasil já acontece mais, mas ainda é um gap que eu gostaria de ver sendo fechado ao longo do tempo, criar mais incentivos pra que todo mundo que trabalha numa certa empresa realmente se sinta dono e opere como dono. Acho isso muito importante, e eu até levo muito isso no meu dia a dia como trabalhando com produto. Outra coisa que é interessante, que é muito comum quando eu recebo algumas pessoas do… Ou falo com algumas pessoas do Brasil é perguntas do tipo: cara, mas qual framework você usaria? Qual é o blog que você leu, que gerou as ideias e defini como é que você trabalha? Tem um pouco assim de… E eu era 100% assim, antes de eu me mudar, eu comprava todos os livros quando acabava de lançar e tentava… Lia o livro e tentava aplicar exatamente by the book no meu dia a dia, como se o livro ou o blog fosse o segredo do sucesso. E é engraçado que aqui não existe isso, talvez porque a gente tá um pouco mais próximo do source, de alguns desses livros, de algumas dessas ideias, mas também porque a gente não é… É muito fluido o trabalho aqui, a gente sabe que não vai ser nada by the book, cada empresa vai ser diferente, cada equipe vai ser diferente, cada pessoa vai ser diferente e você vai criar o seu próprio processo, entendeu!? Então, se você me perguntar até como eu trabalho hoje em dia, não tenho um nome de um framework pra te dar, uma coisa que eu criei com a minha equipe, que eu evoluo a cada semana, então isso é uma coisa interessante… Às vezes quando eu converso com as pessoas do Brasil, tem um pouco dessa noção de me dá um menu de frameworks que eu posso usar e qual dessas opções eu posso escolher pra aplicar amanhã? Eu acho que é um pouco da ilusão que se cria de que existe fórmulas de sucesso, acho que não existe, realmente a questão é entender o problema que você tá tentando resolver, a missão da sua empresa, como é que as pessoas trabalham e criar o seu próprio processo, isso é uma coisa que sempre que eu converso com as pessoas do Brasil, e palestras e coisas e tal, eu tento, de certa forma, quebrar um pouco esse mito. A gente pode falar um pouco mais sobre isso também. Mas de uma maneira geral, acho que essa busca por um framework que eu posso copy and paste no Brasil é bem diferente, eu não vejo isso acontecendo no dia a dia do Vale do Silício

A: Bacana! Certamente a gente vai falar bastante sobre essa questão de processo de fazer produto. Antes de entrar nesse assunto especificamente, eu só queria pegar um gancho no comecinho da tua frase, quando tu tava se apresentando, que tu mencionou o fato de que hoje tu lidera um time no Instagram que é mais voltado pra…  Como é que se adquiri mais clientes, pra não clientes do Instagram, e acho que é curioso, até eu tava lendo umas coisas esses dias justamente sobre esse mindset de que se você imaginar a grande maioria das pessoas não é o teu usuário ainda no seu produto e como é que você faz produto pra não usuários… E justamente tu mencionou algo nessa linha aqui. E daí eu queria escutar um pouquinho de ti, como é que tá sendo essa experiência e o que que tu tem aprendizado nesse negócio de criar produto pra não usuários, pra justamente conseguir atrair essas pessoas de alguma forma?

R: Cara… Eu acho uma pergunta… Até porque é a pergunta que eu me faço todo dia, principalmente sendo a única equipe do Instagram que realmente tá focada em não usuários, a gente tem que se questionar e propor como é que vai ser esse nosso processo, esse nosso approach. Que é um pouco diferente, só pra esclarecer pra quem tá ouvindo, quando você trabalha com produto… Quando você trabalha com usuários você tá às vezes tentando entender assim: o que que esse usuário tá tentando fazer aqui no meu produto, e quais barreiras que ele tá encontrando e como é que eu posso tornar isso um pouco mais simples, ou quais os outros produtos que ele tá usando e como ele poderia passar a usar essas outras soluções dentro da mesma plataforma que você constrói. Então você tem um pouco mais de acesso aos dados, você pode observar o behavior, você tem até mais acesso os usuários no researcher, as pessoas que você conhece tão usando o produto e você pode conversar com eles, se for uma empresa B2B você pode falar com esses clientes, então é tudo um pouco mais próximo. Quando você vai pra um mundo em que você tá não usuários, e na verdade esse é o caso com muitas startups, quando tão começando você tem uma base muito pequena e você tá tentando abraçar um mercado novo de milhões de pessoas que não tão usando o seu produto. Você basicamente tem que entender o que a gente chama de job to be done. O que que essa pessoa tá tentando fazer naquele determinado espaço que o seu produto trabalha e, se é uma necessidade forte pra pessoa, ela tá resolvendo de alguma forma, pode não ser exatamente com um competidor direto seu, mas de alguma forma ela tá encontrando alguém pra fazer esse job, tá contratando alguma solução pra esse job. Deixa eu pegar um exemplo, no Instagram você tem esses dois lados, você tem esse lado de que é uma plataforma pra você conectar com seus amigos e seus melhores amigos, e por outro lado é uma plataforma também pra se conectar com seus interesses. Uma maneira da gente descobrir quem são esses não usuários e o que que eles tão fazendo é entendendo como eles conectam, vamos dizer, com os amigos deles hoje em dia. E entendendo as soluções que eles utilizam pra isso e porque eles consideram utilizar essas soluções e não outras. Então, no caso, você vai descobrir que eu conecto com meus amigos através do whatsapp, então, o whatsapp me serve… Foi uma boa solução pra esse tipo de necessidade que eu tenho, por isso, isso e aquilo… E aí à medida que você vai conversando com esses não usuários, você vai também encontrando oportunidades em que as ferramentas atuais que eles usam, os produtos que eles tão empregando pra esse trabalho, não são 100% perfeitos. Aí quando você começa a ouvir um palavrão ou outro, uma cara de frustração quando o usuário tá falando sobre a experiência dele, e aí são boas oportunidades pra você encontrar um posicionamento para o seu produto. Às vezes você descobre que tem um overload de notificações naquele certo produto, ou que o outro produto tem que tá conectado com muita gente, como é que você cria uma rede um pouco menor? Então isso modifica o seu próprio produto pra ter um fit melhor com relação ao que que esses potenciais usuários no futuro vão tá querendo, ou às vezes é só uma questão de posicionamento, às vezes as pessoas não sabem que seu produto pode ajudar eles naquele determinado job to be done, e aí você trabalha numa questão de articulação, de quais são os suas propostas de valor, como é que você pode fazer as pessoas entenderem isso, como é que você pode dar um preview, uma prova pras pessoas que você… Que o seu produto poderia ser qualificado pra aquela atividade. Então assim, de maneira geral, processo não muda muito, continua sendo um processo super people centric, entender o que que tá passando pela cabeça das pessoas, como elas get something done, como é que elas eventualmente poderiam considerar o produto que você tá trazendo pro mercado… Acho que a grande diferença é a audiência, você vai tentar ter essas informações com outro tipo de métodos, porque você não ter disponível os dados do produto, as métricas de como as pessoas estão usando o seu produto.

A: Imagino que seja um negócio bem qualitativo em muitos níveis e bem exploratório, porque tem muita coisa pra descobrir nesse meio do caminho.

R: Isso. Tem diferentes motivos, nem sempre é só um motivo… A gente criou um framework chamado ABCD que A é awareness, as pessoas nunca ouviram falar desse produto, no caso do Instagram não é obviamente o grande problema a se resolver. B, que a gente chama de barrier, que é: a pessoa até poderia querer usar o seu produto, mas ela não tem como, então é o caso muitas vezes de países emergentes e lower social economics levels, então você tem um android que foi me dado pelo meu primo, esse android não tem uma memória muito grande nem pra botar aplicativo, ou a minha internet é cara, eu não vou gastar a minha internet vendo stories… Coisas desse tipo, então você tem que resolver esse tipo de barriers se você quiser ter um próximo 1 bilhão de usuários, e aí o C o D são consideração e decisão. São pessoas que poderiam tá usando o seu produto, mas ainda não veem tanto valor nisso, ou se veem valor simplesmente vão adiando, não tem muito senso de urgência pra decidir usar o seu produto hoje. E aí você tem todo um trabalho de mostrar pra eles que realmente o seu produto pode ser útil no dia a dia e criar esse senso de urgência pra ele já adotar o produto o quanto antes.

A: Cara… Agora, enfim, fazendo o gancho aí dessas… A gente mencionou já em dois momentos, essa questão de processo pra construir produto, e nesses teus mais de 10 anos de experiência aí trabalhando com product manager em diferentes empresas, e eu queria entender mais nessas formas todas diferentes que tu aprendeu de fazer produto, qual que é o teu processo hoje? Como é que tu faz isso hoje e que dicas que tu pode dar pra gente nesse sentido?

R: É engraçado, porque é até um processo que eu acho que é um pouco único, assim, até no Instagram eu acabo compartilhando um pouco mais com outras pessoas na área de produto sobre como é que eu faço que é o seguinte, eu quero me tornar desnecessário pra minha equipe no dia a dia, assim, literalmente, às vezes, 2 semanas atrás eu tirei um dia off porque eu queria ver se a equipe funcionava bem sem mim, em várias reuniões que eu poderia tá entrando, mas eu decido não participar porque eu quero ver se realmente eu ainda tô sendo necessário e quase como um bottleneck que as coisas dependem de mim pra funcionar ou não, então eu tô feliz se eu conseguir participar de menos coisa e ter mais leverage nesse sentido, usar meu tempo pra coisas que são mais impactantes enquanto o dia a dia da equipe as pessoas que trabalham na minha equipe tão lidando muito bem com isso. E pra chegar nesse ponto eu tenho esse perfil ou esse approach de empoderamento da minha equipe, criar esse senso de ownership, esse senso de responsabilidade e motivação muito grande em cada pessoa que trabalha comigo e obviamente suportar eles em termos de processo, de ferramentas, de coaching e tudo mais, então, na minha equipe eu até brinco que assim, ou até outras pessoas brincam: não olham pra minha equipe, é?  Todo mundo é owner alguma coisa, né? E é assim que eu funciono… Mesmo a pessoa que acabou de entrar, zero meses de experiência, eu viu… A gente vai entender mais ou menos,  aliar os interesses, ver pra onde aquela pessoa tá querendo ir, o que que é importante naquele momento, e a gente vai encontrar alguma coisa pra ela own, nem que seja uma feature pequena que a gente tá fazendo, mas essa feature vai ser owned por aquele engenheiro junior que acabou de começar na equipe. E aí você trabalha com a sua equipe o que que é own, o que que é ser responsável, é muito mais do que pegar um produto e executar da maneira que foi especificada, acho que own tem toda a atenção que você dá a coisas que também não foram especificadas, como você descobre o que que tá em volta, qual o background, o que que é importante num nível um pouquinho maior, como você monitora e gera ideias, e observa trends ao redor daquele produto que você tá construindo, como você mantém todo mundo atualizado sobre o que tá acontecendo no seu produto ou naquele projeto que você é o responsável, e por último como você compartilha o que você tá aprendendo. Então é uma visão bem ampla do que significa ser o dono de algum projeto ou de alguma parte do processo e isso eu tento introduzir na minha equipe. Não vou dizer que é fácil, muitas pessoas, principalmente vindo de outros backgrounds, de outras empresas onde as funções delas era muito mais executar o que foi mandando, né? Tem um momento ali de que: opa! Calma aí! Me manda fazer alguma coisa Rafael… Eu tive essa conversa com um engenheiro que tinha entrado na minha equipe e eu expliquei pra ele como é que eu funciono, como é que a minha equipe trabalha e ele ficou confuso, ele falou: cara, só me manda… Me diz o que tem que fazer, me dá um doc pra eu ler e que eu tenha só que executar e te mandar a tarefa pronta. E eu falei: cara, funcionaria, mas não acho que é como a gente alcança o nosso sucesso no longo prazo, eu quero que você realmente participe desse processo de descobrir o que tem que ser feito, de realmente care sobre o resultado, sobre o problema que a gente tá resolvendo e enfim… Depois de umas semanas, esse cara já tava brilhando, extremamente proativo, ele era literalmente um desses caras que eu não precisava participar das reuniões que ele tava liderando, não precisava cobrar nada, ele tava simplesmente abraçando e adorando essa ideia de que ele era o dono de uma certa área da nossa equipe e do nosso problema que a gente tava tentando resolver. 

A: Bacana, cara! Acho que nessa tua resposta teve duas coisas que me intrigaram aqui, porque recorrentemente quando eu tô conversando com outros PMs esses desafios sempre surgem, que é justamente como é que você envolve o time, especialmente o time de engenharia, o time de desenvolvimento durante esse processo de discovery de uma forma geral, que não seja só como tu falou ali, só ser um tomador de pedido, tipo faz isso, faz aquilo, faz aquilo outro… Mas te ajuda no processo de descobrir o que fazer, e no outro, do outro lado, como que também as coisas que tu tá descobrindo como PM, tu passa isso pro time, pra que, enfim, o time também se sinta parte desse processo por mais que de repente… O time de engenharia não esteja presente em uma entrevista, alguma coisa, mas de alguma forma tu vai fazendo touches desses conhecimentos pra eles entenderem o que que tá acontecendo ali no contexto geral do time. Mas especificamente sobre essas duas coisas, tu  tem dicas de como é que  tu faz isso?

R: Acho essencial não criar tanto essa divisão entre discovery e a execução do projeto por si só, porque se a gente deixar a equipe como um todo ser uma equipe única, não divido a minha equipe ao meio… Vocês tão falando com os usuários e o resto da equipe tá só executando o projeto, na verdade é só uma equipe só e todo mundo é sempre convidado a participar dos projetos desde o começo. Então, na prática, algumas coisas que a gente faz, primeiro, já desde o começo de algum projeto, mesmo nessa fase de discovery a gente já cria uma mini task force, um grupo pequeno e que vai ter representação de qualquer função da equipe, vai ter já, mesmo naquele momento que a gente não sabe nem o que que a gente vai construir eventualmente, já tem um engenheiro que é o engineering owner daquele problema, e aquele engenheiro já tá super interessado, ele já representa, ele já comunica com o resto do time de engenharia o que que a gente tá descobrindo naquela fase. Então isso é uma coisa legal, pelo menos do que você pode fazer amanhã ou segunda-feira na sua equipe é começar a montar esse time de uma maneira que ele é constante, ele se forma bem nascido antes realmente de você nem entender exatamente o problema que você tá resolvendo, mas é uma equipe que já tem representação de todas as funções, então tem um pouco menos de handover entre as partes do processo, não é que primeiro você vai ter só o researcher, só o data scientist trabalhando no problema, depois vão passar a bola pra um designer que vai passar pra um engenheiro… Porque as pessoas só vão ter um contexto de uma parte do processo. Então desde lá do começo já que tem uma equipe multifuncional que vai envolver todo mundo, acho que isso ajuda muito, e obviamente clarificar com cada um que tá trabalhando que aquilo faz parte do trabalho deles, alinhar os interesses e objetivos dessa forma, você não quer que um engenheiro ou um designer ele ache que tá perdendo tempo participando dessa fase mais incipiente do produto, e outra coisa que eu acho super importante é literalmente convidar e tornar o processo muito colaborativo no que diz respeito a esse contato com o seu público alvo. Então, não tem nenhuma research ou uma viagem de research que a gente faça, talvez pra outra cidade ou outro país, que a gente não inclui representações de todas as partes da equipe. Hoje em dia, até que a gente tá fazendo muito mais entrevistas remotas, a gente sempre tem o link aberto, a gente incentiva muito a equipe toda a assistir, então por exemplo, quando especificamente a gente tava trabalhando no escritório a gente marcava, bloqueava o calendário e fazia o que a gente chamava de watch party, literalmente pedia comida, fazia alguma coisa especial e todo mundo ia pra uma mesma sala como se fosse assistir um filme, mas em vez de ser um filme assistia uma sessão de user research ao vivo, e a gente discutia um pouco dos insights depois disso. E com tempo as pessoas vão adorando esse processo, vão realmente começando a conectar o que que elas tão fazendo eventualmente, assim… Construindo essa funcionalidade aqui… Como assim? De onde surgiu esse problema? Muitas vezes chama pelo nome, aquele participante da nossa pesquisa, o nome dele é João e ele que contou aquilo e foi aquilo que inspirou esse produto que a gente tá criando. Então fecha o ciclo de uma forma que eu acho que funciona muito bem e todo mundo na sua equipe tem o contexto. Até quando você perguntou assim: como é que você passa pra sua equipe o que você tá aprendendo, de novo, até na minha ideia de me tornar desnecessário, eu não quero ficar no meio dessa comunicação, eu convido eles pra aprender junto comigo. Então tem essa ideia que eu nunca sou o centro da equipe, na verdade, eu quero que a minha equipe seja uma rede interconectada onde todo mundo tem contato com todo mundo e todo mundo tá participando de todas as fases do processo.

 A: Animal! E olhando pra esse processo todo que a gente conversou aqui e pensando mais no início da tua carreira pra como tá agora, tu vê alguma diferença nesse período? 

R: Acho que se eu olhasse lá pra quando eu comecei a trabalhar com produto, eu acho que eu realmente não tinha essa visão um pouco mais… Toda hora eu tô falando de equipe, de objetivos e de incentivar ownership, obviamente eu não tinha isso quando eu comecei a minha carreira como PM, foi uma coisa que evoluiu com o tempo. Acho que quando você começa como PM muitas vezes você está lá no… Principalmente quando eu comecei no Brasil eu tinha essa ideia de que o PM era o cara que fazia o método ágil acontecer, então, você organizava os sprints, você ajudava nas estimativas de pontos e tinha um Kanban board que era maravilhoso, então, era muito processual… Essa é maneira de como escrever specks e tudo mais, foi interessante que quando eu me mudei pra… Desculpa, antes de me mudar, quando eu comecei a trabalhar no Twiiter, eu tava só viajando daqui pra lá, eu tive uma conversa com o head de produto do Twitter que eventualmente mudou completamente o meu approach, acho que não na hora quando ele me contou, mas eventualmente me ajudou a repensar a maneira de trabalhar, e eu introduzi, falei: cara, eu trabalho no Brasil e no escritório do Brasil do Twitter e acabei de começar aqui, qual é a dica você me daria se tivesse que me dar uma dica só? E aí ele falou: bring the donuts, que é uma expressão daqui, pra te falar a verdade eu nem sabia o que que significava quando ele me contou, então eu meio que guardei aquilo na minha cabeça e depois quando cheguei, quando acabou a reunião eu fui pesquisar o que significava, e literalmente o que significava é trazer o donut pra sua equipe, seja um dia pra deixar a galera animada ou quando você tem alguma coisa pra comemorar, ou um orçamento, um projeto personalizável, é aquela pessoa que realmente faz aquele pedido do delivery e traz a cerveja ou o donut ou alguma coisa pra animar a equipe. E a verdade é que naquela hora quando eu vi isso eu fiquei um pouco frustrado porque eu pensei: não acredito, eu estudei pra caramba pra chegar aqui… Eu decidi agora, acabei de decidir… Começar a trabalhar no Twitter pra eventualmente vir morar em São Francisco e literalmente o cara tá me falando que a maior dica que ele pode me dar é que eu deveria ser esse cara que traz o biscoito, traz o lanchinho pra minha equipe, eu quero saber de processo, eu quero saber de framework, eu quero saber de como eu posso ser o highest performing PM do mundo… E essa dica é uma dica muito ruim. E eu basicamente ignorei, e volta e meia eu usava essa história pra falar: pô, esse cara, você acredita que ele me deu esse conselho? E a verdade é que, sei lá, talvez um ano, dois anos iniciais, trabalhando no Vale do Silício, não foram fáceis, foram esses anos de transição, e aí num momento desses eu pensei: cara, o que eu posso fazer de diferente pras coisas começarem a funcionar de  verdade? E aí eu lembrei desse conselho desse head de produto… Eu falei: cara, bring the donuts. Aí eu falei: cara, vou experimentar. E comecei a pensar um pouco nessa função do PM de ser literalmente essa cola entre o time inteiro, essa pessoa que se importa com cada um dos indivíduos que trabalha na sua equipe, constrói esses relacionamentos, que tem essa visão mais holística de como a equipe funciona, e na prática a experiência funcionou muito bem, eu passei a me importar um pouco menos com o dia a dia do projeto e os mini detalhes do produto, passei a delegar muito mais essas coisas, e quase que tomar um passo atrás e ficar olhando a minha equipe um pouco mais de longe, ter uma visão mais ampla sobre como é que a equipe trabalhava, né, e acho que foi dali pra frente na minha carreira aqui no Vale do Silício, que as coisas começaram a funcionar muito bem, e hoje em dia é uma parte muito fundamental de como eu trabalho, acho que vocês vão ver da maneira como eu conto, é um approach muito team oriented, tipo, é como é que eu crio a estrutura e a cultura que vai ajudar a gente a atingir o nosso objetivos? E acho que o resto é um pouco a consequência disso, você primeiro cria uma equipe muito forte, cria uma cultura muito interessante de produto e acho que se você cuidar disso, se você cuidar desses fatores o resto acaba acontecendo muito bem. É uma mega mudança que… O engraçado é que começou exatamente… Eu ouvi falar exatamente quando eu comecei a trabalhar no Vale do Silício, ignorei durante um tempo e depois quando eu adotei foi quando eu realmente vi as coisas melhorarem muito rápido na minha carreira. 

A: Cara… Voltando ao processo em si de desenvolvimento de produto de uma forma geral, e beleza, a gente pode pra simplificar aqui a conversa, vamos falar que existe uma fase de discovery, uma fase de delivery, com todas as características que tu mencionou, do time trabalhando em conjunto nesse processo todo e tu sendo idealmente desnecessário nesse processo, mas como é  que tu vê o teu papel como PM, ou o papel de um PM, durante essas macro fases de discovery e delivery, e quais são as principais responsabilidades de um PM nesse processo? E vou adicionar aqui também como que tu faz esse processo de se tornar dispensável durante esse processo todo de desenvolvimento de produto?

R: É legal a gente ter um framework, assim, uma approach parecido, só que a gente cria mais uma fase nesse processo, no Facebook isso é muito forte, que é quase como se a gente quebrasse essa parte do discovery em duas partes que é understand e identify, então no total o nosso processo tem 3 fases que seria understand, identify and execute. Understand é 100% problema, você vai se segurar pra não pensar em solução, você só quer entender o seu usuário, que problema você tá tentando resolver e todo o contexto possível que você pode ter sobre aquela atividade, e vai bem fundo. A gente acredita que se você tem um problema muito bem definido acho que o resto vai fluir muito bem, o I, o identify já chega… Quando você para de falar um pouco de descobrir novos problemas você começa a pensar em soluções, mas o importante é que a gente chama de Identify porque a gente reconhece que tem muitas possíveis soluções, então, identify é esse processo de avaliar, decidir, testar algumas coisas diferentes e identificar qual é a estratégia certa pra se seguir. E por último é a execução, uma vez que você decidiu uma estratégia, vai fundo, vai construir o produto, vai botar ele no ar, testar, medir resultados. E aí voltando pra tua pergunta, eu acho que um dos papeis do PM é visualizar esse ciclo e estruturar o processo de uma maneira que tá bem claro, qual projeto tá em qual fase, que fase que cada pessoa tá colaborando… Outra coisa que eu acho muito importante é o PM quase que tá esclarecendo qual o limite entre essas diferentes fases, porque você não quer, por exemplo, se você ainda tá numa fase muito incipiente do seu produto que você tá tentando entender qual o problema que você quer resolver,  você não tem nem ideia, você não quer naquele momento começar a discutir soluções, então, muitas vezes o PM vai ser… Tendo uma visão um pouco mais macro, aquela pessoa que fala: não, não, calma, isso já tá chegando em solução. Então se você vai trabalhar às vezes com researcher ele vai falar: não, não, não vamos adicionar essa pergunta não que parece um pouco mais solution oriented. Ou você vai gerenciar expectativas com a sua… Sei lá, com designer, com engenheiro ou com content strategist que tá envolvido na sua equipe pra falar: não, isso aqui a gente vai… Sei que a gente tá ansioso pra pensar em ideias, mas agora a gente tá na fase de entendimento do problema, vamos guardar as ideias pra depois. E a mesma coisa quando você vai um pouco mais pra frente, quando você chega no momento de execução é assim: estabelecer o foco! Então o PM também tá tentando lembrar todo mundo que agora é a fase de execução, talvez a gente tenha outros problemas que a gente vai tentar resolver e a gente vai votar no nosso backlog, a gente vai botar no nosso roadmap pro próximo semestre, vamos dizer assim, mas agora a gente escolheu essa solução, vamos testar ela, vamos realmente não se distrair, executar perfeitamente pra gente poder colocar esse produto no ar o mais rápido possível e descobrir se essa é a estratégia certa ou não. Então, eu acho que um PM tá sempre mudando e trabalhando nessas três fases ao mesmo tempo, porque a equipe idealmente vai tá tendo projetos em diferentes fases, mas tem que sempre tá distinguindo, o que que eu tô fazendo nesse momento? O que que a equipe tá fazendo nesse momento? Pra ajudar a equipe a focar no objetivo certo, naquela fase do ciclo do produto dele. 

A: E, mais ou menos quanto tempo tu investe em cada uma dessas fases idealmente? Tu passa mais tempo numa do que na outra? Mais nessas fases mais de discovery do que na fase final de delivery? Como é que tu calibra o teu tempo e energia nisso? 

R: Boa pergunta! Assim, não é uma coisa muito intencional, acho que até eu tenho um bom equilíbrio, mas volta em meia a gente faz exercícios com alguns PMs que é se um PM começa a sentir que não tá tendo tempo pra estratégias, não tá tendo tempo pra understand o que a gente faça é um exercício muito bom que você pode fazer com qualquer pessoa da sua equipe, que é o seguinte: olhe o seu calendário, pega uma semana do seu calendário e começa a marcar com cores diferentes qual dessas reuniões que você tem que são focadas em understand, quais são focadas em identify, quais são focadas em execute, e isso tá representando o que você consideraria seu breakdown ideal de tempo? Se não, vale a pena fazer alguns ajustes.Então isso é uma técnica interessante pra ter certeza que você tá pelo menos dedicando um pouco de tempo pra cada uma dessas coisas da maneira que você gostaria… Isso depende do tipo de produto que você tá construindo, da fase da sua equipe e da sua experiência, dos seu nível também. Por exemplo, como eu te falei acho que na medida que você vai evoluindo na sua carreira, acho que você já vai passar um pouco menos tempo em execução e um pouco mais tempo em entendimento do problema, estratégia e o tempo que você vai passar em execução é muito mais orquestrando uma equipe do que efetivamente botando a mão na massa e escrevendo um speck ou trabalhando com outras equipes e coordenando ali um pouco do trabalho de design e engenharia e tudo mais, essas coisas vão tá meio que rolando, vai ter um PM na sua equipe cuidando disso. E outro ponto, acho que tem esse snapshot que você pode ter na sua agenda, pra meio que ver qual é o breakdown de tempo que você tá dedicando pra cada uma dessas atividades, e uma outra coisa, uma outra maneira de pensar nisso é ser um pouco overtime, ao longo dos meses deve ter um fluxo ideal dependendo do seu produto de como você vai investir o seu tempo. Por exemplo, um approach que eu tenho hoje em dia, é, no primeiro… A gente trabalha em ciclos de 6 meses, no Instagram, no primeiro mês eu sou muito focado em execução, basicamente dando aquele empurrãozinho inicial pra tudo começar a se mover, sair da inércia, e começar a se mover e isso acompanhando o máximo possível a minha equipe pros projetos realmente começarem a sair do papel, e depois disso eu vejo que normalmente, depois do primeiro mês o negócio já começa a andar sem mim, e aí eu posso começar a dedicar tempo às outras tarefas, as tarefas de research, as tarefas de priorização etc., e isso normalmente dura… Acabo deixando a maior parte do meu tempo nessas coisas nos meses seguintes. Como alguns checkpoints que eu posso rebalancear o meu tempo, então, por exemplo, apesar da gente ter um ciclo de 6 meses, a cada 6 semanas a gente faz uma análise assim: como é que tão indo as coisas? Já passou, por exemplo, já passou 25% do tempo nesse semestre, a gente tá em 25% de delivery em termos das nossas metas? Se não, talvez seja uma época boa de eu redistribuir o meu tempo, talvez  é uma época  boa pra eu me envolver um pouco mais com a execução e botar meu time pra puxar um pouco os projetos pra frente, ou não, às vezes eu tô indo muito bem, a gente tá indo muito bem em relação a determinadas metas de delivery, de resultados, eu falo: ótimo! Posso inclusive dedicar um pouco mais de tempo pra understand, pra identify, pra pensar nos próximos 6 meses, 1 ano da minha equipe. Isso é quase como um crédito que a gente acaba ganhando pra pensar grande, pra pensar no futuro e tudo mais. Acho que tem esses dois pontos, resumindo, pensar em distribuição do seu calendário numa visão semanal, como é que eu tô distribuindo o meu tempo, mas também numa visão a cada 6 meses, em que momento você tem que dedicar mais tempo a execução versus mais tempo pra estratégia e tudo mais.

A: E cara… Tu falou várias vezes de time, a importância do time, de novo, me ajudar em todo esse processo, ser bem participativo, e obviamente que, mesmo quando a gente fala de specks ou fala de qualquer coisa mais tática, digamos assim, que eu super concordo que idealmente acho que não é onde a gente deveria tá gastando a maior parte da nossa energia, mas eventualmente alguém pelo menos vai tá fazendo algo semelhante a isso dentro do time, se não for o PM, vai ser o engenheiro, vai ser um outro PM mais júnior, vai ser, sei lá, qualquer outra papel nessa linha, como que é essa formação ideal de time aí dentro do Instagram, ou mesmo na tua experiência, enfim, como é que esses times são idealmente formados?

R: Essa pergunta é boa porque às vezes eu meio que assumo que como eu tô inserido nesse contexto e aqui, pelo menos no tempo que eu passei no Twiiter, Facebook, Instagram, tem um determinado modelo, eu take for granted, eu assumo que é assim que toda empresa opera, então vale falar um pouco sobre isso. Então primeiro vamos falar um pouco das funções, acho que tem um mínimo squad que vai ser necessário, na minha opinião, principalmente se você vai querer fazer tanto o entendimento do problema quanto a identificação de soluções, quanto a execução em si, que vai ser N engenheiros, então assim, o número de engenheiros que depende um pouco do produto que você tá trabalhando, do seu nível, etc., mas também vai ter uma pessoa de dados, cada empresa tem um nome pra isso, no Instagram a gente costuma chamar de cientista de dados, um pesquisador, um designer e acho que é isso. Então você tem um mínimo squad que vai ter aí um PM. Você vai ter um mínimo squad que vai ter um grupo de engenheiros, uma pessoa de dados, um pesquisador e um designer. Obviamente, acho que no Facebook e Instagram, as maiores empresas, as equipes são bem maiores do que isso, acaba tendo um pouco de duplicação de funções, então, a minha equipe é comum, por exemplo, você ter uma equipe com dois ou três analista de dados, você ter dois pesquisadores, você ter dois designers e, sei lá, 10, 12 engenheiros, as equipes acabam ficando bem grandes, mas acho que no mínimo teria, sei lá, umas 7, 8 pessoas e uma equipe muito multifuncional. E acho que outra coisa importante, que eu sei que não é a realidade de muitas empresas, mas eu acho super importante pra fazer esse modelo dar certo, acho que é importante você ter todas essas funções dentro da sua própria equipe pra equipe se sentir auto suficiente e não tá dependendo de muitas outras equipes e muitos outros alinhamentos externos pra tudo acontecer, então, se você na sua empresa você tem, sei lá, uma célula de design que é separado e aí o que acontece é que cada equipe tem que pedir um pouquinho de atenção e lutar por uma priorização no tempo dos designers, aquilo vai gerar, tornar, trazer um pouco mais de tensão e fricção pra sua operação. A mesma coisa com o researcher, com dados… Se a sua equipe não tiver essas pessoas quase que dedicadas, vai ser muito mais difícil de operar, porque você tá adicionando outras variáveis e outras dificuldades ali pra literalmente a sua equipe get things done. E você não vai criar essa network que eu tava falando porque não vai ter essa noção de identidade, todo mundo tá realmente trabalhando pra aquela equipe. Então vai ser muito mais uma conexão entre as pessoas que tão full time na equipe do que as pessoas que tão ajudando através de serviços, vamos dizer, com 10, 20 ou 30% do tempo delas. Então acho super importante você ter uma equipe que é suficiente, todo mundo tá 100% dedicado e você ter todas essas funções representadas numa mesma equipe pra criar essa ideia de uma equipe… Não só uma equipe de produto, engenharia, uma equipe cross functional que inclui dados, pesquisa, design e tudo mais.

A: E o escopo desse time, o objetivo desse time em si, pela tua fala já deu pra entender claramente que cada time tem uma meta associada, uma métrica que esse time precisa impactar, mas esse escopo no teu caso, por exemplo, é quase que uma segmentação de cliente diferente. Normalmente, é um escopo mais orientado a uma feature, a uma área do produto em si, são times orientados aos objetivos que podem mudar esses objetivos com o passar do tempo, é segmento de cliente, enfim, como é que são quebradas esses times aí dentro?

R: Boa pergunta! Eu acho que essa ideia de feature, quebrar por feature não é  ideal porque acaba um pouco engessando a organização e até fazendo com que as pessoas daquela equipe pensem muito só naquela feature, então, eu gosto de abstrair um pouco disso e fazer com que as equipes foquem em problemas. Então a feature, talvez aquela feature vai ser uma excelente solução pra aquele problema, eu acho que tem outras que podem ser consideradas, então na prática o que eu vejo acontecendo no Instagram por exemplo, e no Facebook também, você tem umas equipes que são focadas em problemas, e você tem algumas equipes que são focadas em segmentos da população. Então, por exemplo, vamos falar no Facebook… Vai ter uma equipe de grupo, por exemplo, que tá focada nesse problema de: cara, eu quero conectar com as pessoas que compartilham o mesmo interesse que eu tenho, e hoje em dia grupos é uma solução, mas essa equipe pode acabar pensando em outras soluções pra esse problema, ela tá 100% autorizada e tem autonomia pra explorar coisas fora do escopo da função de grupos, quando eu falo grupos é o problema que eles tão tentando resolver e não só a feature do Facebook. Mas também você vai ter equipes mais horizontais, então você vai ter uma equipe pensando em Índia, você vai ter uma equipe pensando em Japão, você vai ter uma equipe pensando em adolescentes e aí essas equipes tão tentando entender o que que a gente precisa fazer no Facebook pro Facebook se tornar mais relevante localmente, vamos dizer, na Índia. Ou pro Facebook continuar tendo uma relevância interessante entre os adolescentes, e aí dentro disso vão ter vários problemas que essas equipes tão tentando resolver, e dentro de cada problema várias features que eles podem tentar construir. Então, acho que essa ideia de que como você desenha essa sua organização e como você organiza as equipes, acho que é muito importante pra como o produto vai se manifestar na prática pros usuários. Então acho muito importante pensar nisso e tentar também não engessar, tentar trazer um pouco de flexibilidade e foco nas pessoas, na people first, foco nos seus usuários e no problema que você tá tentando resolver acima das soluções, então até tentando representar essa filosofia da maneira como se organiza as equipes também.

A: Uma dificuldade que eu vejo sempre quando se tem estruturas mais focadas nisso, focadas em problemas que eu preciso atacar ou o mesmo segmento de cliente etc. é mais voltada a manutenção e operação das coisas que já existem, então vamos supor que existe uma área do produto, uma feature X do produto que não esteja incluso em nenhum dos objetivos, em nenhum dos times hoje, nenhum time tem o objetivo de mexer ali, digamos assim. O que que acontece quando você precisar dar manutenção naquela área? Se acontecer um bug, acontecer algum problema que você precisa atualizar lá alguma coisa e não tem nenhum time que é responsável por aquilo, como é que vocês lidam com isso dentro dessa estrutura?

R: É interessante, eu tô até rindo porque esse é um caso muito recente pra gente e eu tenho um exemplo muito claro do que que acontece. A gente intencionalmente aceita ter partes do produto que não necessariamente vai ter uma equipe responsável por ele, trabalhando nele ativamente e isso é pra poder ter essa flexibilidade e focar nos problemas que são mais importantes naquela fase. Não quer dizer que o produto tá abandonado, porque o produto funciona, mas quer dizer que não é porque o produto existe que você tem que botar, dedicar uma parte grande da sua equipe a ele, senão você acaba dedicando muito recurso pras coisas que já existem e pouco recurso pras coisas que vão poder vir a existir no futuro. Mas isso realmente cria o problema que você falou, que às vezes tem alguma coisa pra resolver, tem uma urgência num certo produto que não claramente ninguém é responsável por isso, vamos dizer assim, e aí a gente vai um pouco de case by case, acho que se rolar algum problema nesse produto que não tem nenhuma equipe por trás, a gente encontra as equipes adjacentes, o líder daquela área consegue identificar e ajudar a priorizar e vai botar no radar de alguma equipe, não vai ficar sem… O problema não vai ser não resolvido, mas pelo menos a gente não vai ficar em adiantamento, dedicando uma equipe só pra aquilo se a gente não acha que aquilo é o futuro da nossa plataforma, então essa é uma maneira que a gente descobriu, um certo híbrido, que a gente não deixa nada efetivamente abandonado, mas a gente pode dedicar mais recursos pro futuro da empresa e não pro passado. 

A: Mais aceitar esse trade off e saber lidar com ele quando acontece e daí agir rápido. 

R: Tem que aceitar, volta e meia nos chats internos a pessoa vai falar: pô, mas não tem nenhuma equipe por trás desse produto… É um custo e é um risco que você toma pra você poder focar no futuro da sua plataforma. 

A: Cara, e beleza, pensando em tudo isso que a gente falou, de como fazer produto, enfim, de como liderar o time etc., tu enxerga ou tu espera até um desempenho diferente de acordo com o nível de senioridade de um PM? Dado todas essas coisas que a gente comentou aqui, ou não, desde o início da carreira tu já tem algum backbone disso, alguma parte básica desse negócio todo que tu já espere ou conforme o tempo vai passando você vai estendendo e vai dando mais responsabilidade, ou vai diferenciando mais a expectativa que você tem sobre um trabalho de um PM mais sênior e mais júnior. Como é que tu vê isso?

R: Então, a resposta é sim e não. Então, obviamente não, eu não tenho a mesma expectativa sobre um PM júnior que não teve nenhuma experiência de trabalhar com produto antes, pra um PM que tem 10 anos de experiência, não é justo ter as mesmas expectativas e botar eles no mesmo barco, no mesmo tipo de desafio, mas sim no sentido de que eu acho que os eixos, as foundations, realmente os fundamentos do nosso trabalho de produto são instáveis. Então, uma maneira de pensar nisso é a seguinte: tem a maneira como eu penso nesse problema, tem três eixos que qualquer PM independente da fase da carreira dele, da experiência vai tá pensando a todo momento, então uma é a execução, literalmente como é que você pega um projeto e gt things done, constrói o produto, leva ele pro ar, trabalha com a sua equipe e tudo mais, o segundo eixo é um eixo de estratégia, como é que se pega um problema que muitas vezes pode ser muito ambíguo, muito complexo e quebra ele e entende as nuances por trás desse problema e propõe uma estratégia, propõe umas soluções e por último o eixo de liderança de pessoas, como você trabalha junto com a sua equipe, como você influencia as pessoas, como você cria parcerias e relacionamentos, não só com a sua equipe, mas com outras equipes, como você inspira todo mundo que trabalha com você ou em volta de você. Então eu acho que independente da sua fase na sua carreira, você vai ter que tá trabalhando esses três eixos, mas obviamente o que que muda é qual peso que você dá pra cada um deles, então, quando você é um PM que acabou de começar e se tô coaching esse PM eu vou falar pra ele dar um peso 90% a execução, e 5% a estratégia, 5% a pessoas, e isso vai mudar com o tempo, se eu tô falando de um PM que tem 10 anos de experiência, ele vai tá dando, sei lá, 30%  do tempo dele pra execução, grande parte do tempo dele pra estratégia e também uma boa parte do tempo dele pra gerenciar pessoas e liderar as equipes. Tem essa questão do tempo e tem a própria escala de ser um impacto, então, quando você pensa em execução de um PM júnior que acabou de começar a trabalhar, o que eu vou pensar pra esse PM é um nível de uma mudança de uma feature, uma coisa bem localizada pra ele poder construir os músculos que ele precisa pra fazer o processo funcionar. Obviamente, se eu tô pensando num… E aí a isso vai evoluir pra um segundo nível que é talvez um conjunto de features, talvez uma área como um todo e dali pra frente é literalmente um aplicativo inteiro ou uma business unit completa da empresa, às vezes até uma empresa como um todo se você pegar alguém que tem 10, 15 anos de experiência, diretor de produto e tudo mais. E a mesma coisa na estratégia, você começa talvez com um estratégia muito básica que é uma decisão mínima de: será que eu tenho que fazer… Como é que vai ser o design dessa micro feature aqui que eu tô fazendo… E isso vai evoluindo pra grandes decisões de… Mas decisões maiores de estratégias, posso ir pela direção A ou direção B e mais pra frente é tipo assim: como é que eu mudo… Qual vai ser o futuro dessa indústria, como é que eu vou desenhar isso, como é que eu vou imaginar isso? Então são… A escala da sua estratégia também muda muito, e obviamente pessoas, acho que tem uma evolução parecida, você começa colaborando com 3, 4 engenheiros, 1 designer, etc. daqui a pouco você tá trabalhando com múltiplas equipes, equipes muito maiores, fazendo parcerias e tudo mais e por último você tá efetivamente liderando uma organização e às vezes não só de PM, você tá tendo realmente muita gente abaixo de você. Então em resumo, os eixos são estáveis, mas eu acho que o que muda a atenção que você dá a cada um desses três eixos que eu mencionei, e em que escala você tá operando cada um deles.

A: Além de evidentemente da complexidade de cada um desses eixos, então, a complexidade do produto que tá sendo desenvolvido ou o escopo, o tamanho desse produto, o time que tem ali embaixo, a dificuldade estratégica pra fazer isso e etc. eu imagino que naturalmente a expectativa é obviamente, pelo que tu descreveu, é ir aumentando essa complexidade com o tempo, isso é um indicativo de que esse PM tá amadurecendo na carreira, digamos assim, mas tem alguma coisa que além disso que tu consegue ver mais claramente que esse PM tá evoluindo na carreira e de repente ajuda a dar mais desafios pra esse PM, ou é um negócio muito puxado pelo PM em si?

R: Eu acho que pra PMs, mas agora eu tô pensando, talvez pra quase todas as funções, uma maneira de pensar nisso é o quanto a pessoa tá já apta a lidar com mais ambiguidade no que ela tem que fazer, então, uma pessoa júnior que acabou de entrar, normalmente não é um problema muito ambíguo, ele não tá preparado pra trabalhar numa coisa que não tem nenhum direcionamento, então você normalmente vai falar alguma coisa do tipo assim: constrói isso aqui. Você já vai dar muito guidance, quase descritivo e botar ele na frente do gol basicamente e ajudar ele a… E deixar ele chutar a bola. À medida que ele vai evoluindo você vai deixar de ser preditivo e você vai… Você ou a empresa vai passar pra ele problemas um pouco mais complexos: cara, a gente tem um problema e eu não sei a solução, toma aí, você e sua equipe vão tentar resolver esse problema. E indo mais além, você às vezes nem sabe o problema, você só tem um tema na sua cabeça e você vai querer que esse PM ou essa equipe desenvolva, então, basicamente… E os problemas vão ser muito complexos, então é basicamente o futuro do X, o futuro do Y, o futuro do Z, então, esse é um nível talvez mais pra frente que você quer de independência de um PM na sua equipe é, eu posso… Pensando aqui no Instagram, por exemplo, vou falar de uma coisa que é recente e tá acontecendo, se eu tô falando de um PM que já tá mais avançado na carreira dele e já tá podendo lidar com bastante ambiguidade, eu posso falar pra esse PM pensar no futuro da indústria de entretenimento com soluções remotas? Então não sei exatamente qual vai ser a solução, mas eu tô dando pra ele um tema basicamente, não sei nem qual é o problema, e aí vai mostrar se o PM consegue já operar nesse espaço, mostra que ele já tá bem avançado na carreira dele, e você vai fazendo esses testes à medida que você trabalha com pessoas na sua equipe, essas mudanças são graduais, não é tão discreta, você não vai de zero ambiguidade pra 50% de ambiguidade, você vai trabalhando e você vai descobrindo os momentos pra inserir um pouco de questões, ou pra não dar tanto feedback tão direcional, e você vai vendo como aquele PM vai recebendo isso, se ele vai conseguir performar bem, ou se ele vai voltar pra você e falar: cara, eu não tô entendendo muito o que tem que ser feito, eu não tô conseguindo desenvolver e aí você vai conseguindo meio que posicionar eles e nivelar eles da maneira certa. 

A: Bacana! E pensando nisso tudo também, entendendo pelo menos… De repente tu não vai concordar com isso, mas eu acho que tem obviamente o nível de senioridade desse PM, que nem tu falou, um PM que tem 1 ano de experiência, ou um PM que tem 10 anos de experiência tem expectativas diferentes também em cima disso, mas sempre transição de um empresa pra outra também é sempre um negócio que requer um certo nível de atenção, porque tem essa diferença normalmente de como é que funciona o contexto do produto, como é que aquele produto funciona, como é que aquele time funciona, a cultura da empresa, uma série de coisas, então sempre tem um periodozinho de adaptação ali de entender como é que se faz o product management dentro daquela empresa que invariavelmente sempre tem as suas diferenças. Pensando nisso, como é que tu vê esse onboarding de novos PMs dentro de uma organização, como é que tu pensa nisso e que dicas tu tem nesse sentido?

R: Boa pergunta até porque você colocou um caso prático que eu acho que muitas vezes leva a erros que as empresas cometem a medida que eles vão recebendo PMs nas equipes deles, que é independente de quanta experiência a pessoa tem, ela é nova na equipe, ela é nova na empresa, então, ela precisa de um onboarding, mesmo com uma pessoa com muita experiência não pode jogar ele no fire que eu acho que assim… Jogar e ter uma expectativa muito alta do que vai acontecer no primeiro mês porque você não tá sendo justo com aquela pessoa de dar todo o contexto que ela precisa. Tem um processo nos primeiros 90 dias e o que que fazem em cada mês que eu acho que aplica na verdade, independente da sua experiência, eu acho que é um processo bem genérico que se poderia usar… Que é o seguinte: primeiro mês, alinha a expectativa com aquela nova pessoa que tá entrando que você só precisa ouvir, você só precisa aprender, eu tenho zero expectativas que você vai fazer alguma coisa útil, eu quero que você realmente dedique tempo a entender como as coisas funcionam, entender o que tá acontecendo e etc. E isso é muito importante porque depois você não vai ter essa permissão, o que eu chamo de new card, você não vai poder usar esse cartão falando: pô, eu sou novo na empresa, deixa eu fazer as perguntas idiotas aqui. Você pode usar isso nos primeiros três meses, depois é quase que esperado que você já tenha esse contexto, então eu falo assim literalmente pros nossos PMs até nas equipes: usa essa new card principalmente no primeiro mês, não se compromete a nada, se compromete a literalmente sentar e aprender, e isso independente do seu nível. Recentemente até tinha um… A gente trabalhou com um senior director que tinha acabado de entrar na minha área e o primeiro mês a gente não ouvia a voz dele, ela tava indo só pra fazer perguntas, ele entrava nas reuniões e ficava na shadowing só observando, só aprendendo, só tomando nota, até a equipe que tava ali, você tem que alinhar as expectativas com o resto da equipe, ficou meio ansiosa: pô, mas o cara entrou e não tá fazendo nada? Mas você tem que falar: não, o primeiro mês é só pra aprender. O segundo mês é quando você começa a pensar em como eu posso agregar valor aqui, você já entendeu o contexto, mas você tem que entender quase que onde você vai trabalhar, where should I play, e aí talvez já teve o que a gente chama de o primeiro win, a primeira vitória, baseado naquilo que você aprendeu no primeiro mês, identifica uma coisa que você pode contribuir e idealmente faça o que você pode resolver em alguns dias, algumas semanas, mas que mostra a sua empatia que você tem pelo contexto da equipe, da empresa naquele momento, sua habilidade de identificar uma área que tá precisando de atenção e começar a fazer certas conexões e mostrar que você consegue agregar valor pra aquela equipe vai criar bastante confiança também. E aí no terceiro mês quando você começa a tomar um pouco as rédeas da sua equipe e começar a executar propriamente dito, ainda assim, muitas vezes você vai tá executando um plano de uma outra pessoa, o que acontece e é bom pra seguir uma certa estabilidade, mas acho que no terceiro mês ainda não precisa necessariamente ser a sua cara a equipe, mas você vai começar a pilotar essa equipe, e aí dali pra frente, no terceiro mês, se você dedicou o tempo suficiente pra ter esse onboarding gradual, a vantagem é que você não vai precisar ficar nessa fase de: oi, eu sou novo na empresa durante muito tempo, porque você realmente fez uma coisa um pouco mais intensiva no primeiros três meses. E aí depois do terceiro mês você literalmente a equipe é a sua cara, você tá colocando a sua marca na estratégia, a sua marca na execução, mas com a vantagem que você criou os relacionamentos, você criou a confiança, você entendeu exatamente o que tava acontecendo antes de começar a implementar qualquer tipo de mudança mais drástica. Então eu acho muito importante ter um onboarding um pouco mais cadenciado e alinhar a expectativa e gerenciar a ansiedade, tanto da pessoa que tá entrando, muitas vezes quando não é experiente então, e tipo, tava, sei lá… Às vezes era diretor de produto em uma outra empresa e quer entrar e no dia seguinte já tá literalmente dirigindo o produto, mas tem que apreciar esses momentos que você não vai ter depois, você não quer chegar numa reunião e não conhecer as pessoas, você não dedicou tempo pra isso no começo, você não quer chegar numa certa estratégia de produto e basicamente não ter o contexto de continuar fazendo perguntas que vão parecer que: pô, você deveria ter feito essas perguntas nos seus primeiros meses, então é melhor dedicar tempo pra isso logo no começo.

A: cara, super concordo com isso, eu acho que product manager de uma forma geral, você não consegue ser um PM sem ter contexto, então, é super fundamental que a gente tenha esse contexto o quanto antes, e adorei a expressão do new card, de realmente, enfim, poder fazer essas perguntas sem medo de parecer que é uma pergunta estúpida, e talvez seja, mas ela é necessária nesse momento, questão de relacionamento, porque também a gente não faz nada sozinho, então, como é que você constrói essa rede. Eu ano passado fiz transição de sair da RD pra ir pro Nubank e até experiência pessoal minha nisso, eu fiquei 4 anos e meio na RD, e uma das coisas mais difíceis pra mim quando foi Nubank foi construir esse networking interno, que em uma empresa 4 anos e meio depois tu já conhece todo mundo, todo mundo te conhece, e de repente você tá em um lugar que você não conhece ninguém mais, ninguém te conhece, ninguém sabe que precisa falar contigo e como é que você trabalha pra construir esse relacionamento também o quanto antes, e por fim, acho que essa questão de confiança, que é super importante pra gente como PM também, como que você de fato constrói isso de uma forma proposital, não deixa o negócio acontecer sozinho, mas entendo que também independe do nível, claro que um PM júnior vai precisar de mais atenção, um PM mais sênior vai precisar de menos, mas como que você constrói esse negócio de ter autoconfiança pra depois conseguir tomar as decisões que precisa e etc. Então, super concordo com a tua resposta. 

R: Eu acho que tem duas coisas bem práticas que você pode fazer, além de obviamente criar esse plano, uma é ser bem crítico em relação a qual o primeiro projeto que esse PM vai ter e quando ele vai executar, um erro muito comum é dar um projeto muito grande porque o PM já é experiente e… Só que o que que acontece, o cara ainda não construiu a fundação, tudo que ele precisa pra executar um projeto muito grande logo de cara, e demora pra mostrar resultado, então assim, o que normalmente eu tento pensar é qual seria um bom first win, como é que eu posso botar, independente da experiência dessa pessoa, como é que eu posso botar ele na cara do gol? Porque se ele logo no segundo mês ele já pega uma bola dessa, já chuta e já faz o gol, a equipe vai tá animada, as pessoas vão começar a ver o nome desse PM ao redor da empresa, ele vai ter a experiência de também ter um projeto do zero sendo levado até o final e  vai rapidamente conseguir entender isso tudo. Então tem um pouco também dessa ideia de você escolher bem esse primeiro projeto, que eu acho isso super importante. E uma outra coisa que você pode… Do lado do PM que tá entrando uma outra coisa que é interessante se pensar nessa mudança de entender o que tá acontecendo e o que eu posso ajudar é perguntar e fazer uma survey que você acaba já agregando valor, isso é uma tática que eu uso toda vez que eu entro numa equipe nova, ou começo a trabalhar com uma galera nova é: eu faço as reuniões, tomo as minhas notas, mando uma survey, faço um monte de perguntas e depois eu torno isso tudo aberto, eu mando pra equipe toda: olha, vocês tão curiosos aqui de saber qual é o pulso da equipe hoje em dia? O que que a equipe tá achando? O que que a gente deveria investir mais e investir menos? Tá aqui os resultados! Então não só eu aprendi nesse momento que eu tô running things up e entendendo melhor como isso tudo funciona, mas também já tô devolvendo valor e agregando valor à minha equipe, e eles tão tendo um entendimento melhor sobre o status deles, porque muitas vezes eles podem não tá parando pra pensar. Então acho que é uma coisa super fácil de fazer, basicamente escreve suas notas de uma maneira que você pode compartilhar depois, estrutura suas perguntas de uma maneira que você pode colocar em alguns gráficos depois e compartilhar com a sua equipe.

A: Animal! Cara, Rafael, pra gente começar a fechar aqui esse papo, e ele tá ótimo, mas a gente precisa começar a fechar ele, eu queria começar… Eu vou te perguntar, é uma pergunta que eu sei que é um pouco mais abrangente, mas depois desses anos todos aí com experiência com product manager e trabalhando aí nas melhores empresas do mundo com relação a isso, quais são os teus principais aprendizados sobre como criar e evoluir produtos de sucesso na tua visão?

R: Acho que tem duas coisas, uma no começo e uma no final. Primeiro é muito entendimento do problema que você tá tentando resolver, acho que a maior parte das coisas não dão certo porque as pessoas… Os produtos não dão certo porque acho que a equipe que tá montando esse produto não se dedicou tanto a entender o core do problema que ela tá tentando resolver e, passar tempo com os usuários e realmente se sentir como se internalizar tudo que tá passando na cabeça dos seus usuários ou potenciais usuários. Então acho que um problema muito bem definido vai ser resolvido, porque você sabe exatamente… Você pensa muito parecido com o seu usuário que você tá tentando ajudar e você vai encontrar alguma solução pra isso. Talvez no meio do processo, acho que… Vai ser resolvido, mas você não sabe inicialmente como isso vai ser resolvido, então abraçar a falha, abraçar a possibilidade de alguma coisa não dar certo é essencial. Ou seja, você tem as suas opiniões, a sua equipe vai criar os seus próprios pontos de vista, mas vai ter que experimentar, algumas vezes as minhas equipes perguntam assim: cara, como é que vocês tão atingindo esse tipo de resultado? Aí eu falei: cara, olha aqui o nosso backlog, olha… A gente lançou 50, 60 testes nos últimos 6 meses. Então assim, a gente errou pra cacete, mas a gente abraça isso, a gente adora errar, a gente faz, na minha equipe por exemplo, quando a gente tem um experimento que não dá certo, a gente escreve um post ainda maior do que quando a gente tem um experimento que dá certo, explicando assim: porque que não deu certo e o que a gente aprendeu com isso. Eu acho isso também super importante, mas pra constatar um pouco, no final do processo é resultado, acho que principalmente pra PMs que tem mais accountability sobre os resultados, é muito importante talvez nesses 6 meses em 6 meses, um ano em um ano, você pensar: não só tô fazendo um processo legal, mas eu tô trazendo resultado, eu tô realmente resolvendo o problema que eu me propus a resolver? Porque na minha opinião a gente não é… O nosso trabalho não é pesquisar e aprender, acho que aprender é parte do processo, mas o nosso trabalho é resolver o problema que a gente tá tentando resolver e trazer resultados pra empresa, então, isso é muito importante, acho as vezes a gente esquece um pouco de… Nessa ideia de lean startup,e validação e aprendizado, a gente esquece que no final das contas o resultado é o que importa, a gente aprende, a gente erra porque a gente quer um dia ter sucesso, então não perder o ponto de vista  nisso como north sign. O north sign é resolver o problema que você tava tentando resolver de uma maneira que é mensurável, de uma maneira que agrega valor pra empresa.

A: E especificamente falando de quem… Pra quem tá começando agora na carreira de PM, tu tem alguma dica pra um pessoa nessa condição?

R: Acho que pro PM que tá começando agora, ele tem que entender o processo como um todo. Como é que é o ciclo completo de entender o problema que você tá tentando resolver, identificar soluções e botar um produto no ar. Acho que a escala não é tão importante, acho que muitas vezes um PM no começo pode tá um pouco ansioso: mas eu queria mudar o mundo, mas eu queria criar um negócio grande, eu quero criar um novo app, mas acho que a escala é muito menos importante do que acompanhar as fases da criação desse produto, então, muitas vezes vai valer muito mais a pena pra um novo PM pegar um projeto em que esse ciclo pode ser comprimido e  feito muito mais rápido, do que um projeto que ele vai abraçar agora, mas talvez ele só consiga mover pra uma fase de execução, pra uma fase de resultados daqui a meses, entendeu? Então eu acho que vale a pena gerenciar um pouco das expectativas e botar um pouco mais de valor nessa ideia de acompanhar uma coisa do momento zero até o momento de lançar o produto e tentar fazer isso tudo numa timeline comprimida, se você consegue ter como um novo PM, ter essa experiência nos primeiros 6 meses de carreira, ou 6 meses naquela empresa, eu acho que você tá realmente criando uma boa fundação pra fazer isso numa escala maior no futuro e pra continuar evoluindo na sua carreira.

A: Animal! Vamos pro bate-bola?

R: Vamos sim!

A: O que é uma ferramenta de trabalho indispensável pra ti?

R: Bom, eu sou chamado o cara dos docs lá no Instagram, mas é a realidade dos PMs, a gente precisa estruturar nosso pensamento e comunicar ele de maneira eficiente, então acho que não tem como você fugir de um bloco de notas, um google docs, qualquer que seja a solução de texto, vamos dizer assim, que você tem. 

A: Legal! Qual que é o teu principal hack de gestão de tempo?

R: Tem uma prática que a gente faz no Facebook que eu adorei e eu adotei e vou continuar adotando até quando eu puder, que é quartas-feiras não ter reunião nenhuma, pra um PM isso é essencial porque a gente tem muita reunião, tá sempre conectando com outras pessoas, e na quarta é um dia que você pode realmente dedicar a pensar um pouco mais profundamente, ter aqueles momentos que você tem um pouco mais de foco em uma atividade só. 

A: O que que tu tá lendo agora? 

R: Eu leio alguns livros ao mesmo tempo. O último livro que eu acabei, o último livro que eu acabei efetivamente chama Bird by Bird, que é… Não tem nada a ver com PM, mas é um livro sobre writing, é um livro sobre escrever, e de certa forma até é uma coisa que eu tô inspirado recentemente, acho que tem… Na prática a gente usa muito no dia a dia como PM, esse livro é um livro excelente sobre isso.

A: E quais seriam os três livros que tu indicaria pra qualquer PM?

R: Bom, essa é mais fácil! Primeiro, sem dúvida nenhuma o que mais me influenciou foi High Output Management, do Andrew Grove, se você ler esse livro você vai lembrar dessa entrevista porque é tudo o que eu falei, basicamente, tem muita inspiração ali naqueles conceitos. Segundo, tem um livro Plan to win, que é um livro sobre estratégia, mas eu… Eu não gosto de nenhum livro sobre estratégia mas esse é muito bom e é sobre quais são as decisões que você tem que tomar pra construir uma estratégia, e o terceiro que é um livro que o Instagram em particular realmente abraça que é Competing Against Luck, que é o livro que criou esse conceito de job to be done e fez as empresas repensarem como é que você define um problema. É um livro excelente também.

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

R: Na prática acho que é no dia a dia do trabalho tentando, experimentando e fazendo… Vendo que dá certo. Isso eu acho que é uma das coisas que eu falei que mudou muito depois de que eu me mudei pra cá, antigamente eu tentava ler blogs, ouvir podcasts e ler livros etc., acho que depois que eu me mudei pra cá eu falei: cara, quer saber? Eu vou aprender um pouco no dia a dia mesmo.

A: Quem te inspirou?

R: Não consigo pensar em uma pessoa só, mas eu tinha… Engraçado eu tinha… Quando eu tava no Twitter, até porque eu tava trabalhando remoto eu tinha uma nota que depois eu deveria até ressuscitar, uma nota que tinha o nome de uma pessoa e uma coisa que essa pessoa fazia muito bem. Então sempre quando tinha um problema que tava stuck eu voltava pra essa nota. Então eu acho que a resposta é, não tenho uma pessoa, mas eu tenho uma clara inspiração pra cada tipo de skill que eu deveria desenvolver.

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

R: Eu acho que é um PM que inspira e entrega ao mesmo tempo, eu acho que ele realmente abraça essa ideia de que ele lidera por influência, e é uma pessoa que as pessoas gostam de trabalhar e gostam de se envolver, mas ao mesmo tempo…Quando chega a hora de botar a mão na massa e fazer a coisa acontecerem é um PM que eu tenho total confiança de que vai entregar, entendeu?

A: O que que é um bom produto?

R: Eu acho que é alguma coisa que combina, se forma, função e forma, acho que sem dúvida função em primeiro lugar, é um produto que me ajuda a completar o que eu queria completar com aquele produto, ele faz o trabalho que eu gostaria que aquele produto fizesse, mas a maneira que ele faz é uma maneira bem prazerosa, é uma maneira remarkable, uma maneira que ativa os meus sentimentos e emoções de… Unicamente, assim, como outros produtos não fariam.

A: Cara, nesses anos todos de experiência certamente tu adquiriu um aprendizado que te guia sempre, que sempre quando tu tem a oportunidade tu passa ele pra frente, que aprendizado foi esse?

R: Além da história do bring the donuts, que com certeza é uma coisa que eu vou continuar contando, eu acho que é essa ideia de ser fascinado, apaixonado pelo problema que você tá tentando resolver, e você ser, de certa forma, um pouco desligado das soluções, as soluções vem e vão, vão funcionar, não vão funcionar, mas o que importa é realmente resolver aquele problema. E por exemplo, no meu caso eu realmente acredito que o Instagram é uma plataforma universal pra  todos as pessoas que usam a internet hoje em dia, e sou apaixonado por esse fato e a gente tá, não só eu, mas a minha equipe, a gente tá muito curioso e muito interessado em resolver esse problema, e eu acho que isso é fundamental pra qualquer PM. É realmente se… Encontre produtos que você vai ter esse tipo de conexão e desenvolva essa paixão, esse fascínio, essa curiosidade ao longo do tempo pelo problema por si só, entendeu?

A: Animal! Rafael, cara, muito obrigado de novo pelo teu tempo, aprendi demais hoje contigo, foi um papo super bacana, e de novo, só te agradecer pela oportunidade de tá falando aqui contigo por todo esse aprendizado que tu compartilhou.

R: Muito obrigado por ter convidado! Só o papo, o nível da nossa conversa super excited, eu poderia continuar falando durante 3 horas e ouvindo as suas histórias também, e não só, obviamente… Compartilha algumas ideias, como que as pessoas podem realmente colocar em prática amanhã, mas eu também, à medida que eu vou falando, eu vou falando: ih cara, isso aqui me lembra alguma coisa interessante que eu poderia colocar em prática, que é um ótimo exercício também, e muito enriquecedor. Então, obrigado realmente pelo convite e vamos se falando, vamos nos encontrar nas próximas.

A: Com certeza. Bom, esse e todos os episódios do product backstage está disponível em productbackstage.com.br e em todas as principais plataformas de podcast, Spotify, Apple, Google podcast etc. e todo as recomendações e descrições do que o Rafael falou aqui no episódio vão tá disponíveis também na descrição do episódio dele em productbackstage.com.br. Muito obrigado pela audiência e nos vemos no próximo episódio. Um grande abraço!

Escute esse podcast no Spotify clicando aqui!