Essa é a transcrição do podcast “Episódio 2 – Product Discovery com Sérgio Schüler”. O link para ouvi-lo está no final desse conteúdo.

Sérgio Schüler é o nosso segundo convidado. Em nossa conversa, ele que começou a sua carreira na faculdade de publicidade e propaganda, com a esperança de que o curso lhe ajudaria a ser um bom web designer, fala das suas experiências, do seu lado empreendedor e da sua vivência fora do Brasil.

Ele foi gerente de produto da Resultados Digitais por mais de 3 anos.

Sérgio também falou um pouco de Jobs to be done e dos seus aprendizados na prática, e de como essa técnica é poderosa para entender a necessidade real do usuário.

Nos acompanhe até o final! Sérgião tem boas dicas e histórias inspiradoras para nos contar.

A: Olá! Sejam bem-vindos a mais um product backstage. Hoje eu estou aqui na RD com o prazer de entrevistar um cara que eu trabalhei bastante tempo com ele, e que eu admiro bastante, o “Sergião”, Sérgio Schüler, seja muito bem-vindo cara!

S: Valeu cara!

A: Sérgio, cara… Para a gente começar a nossa conversa, me conta um pouquinho da tua trajetória, cara… Como é que tu chegou até aqui, enfim, o que tu fez, o que tu estudou?

S: Bom, foi… Sinceramente bastante ao acaso, como muitas histórias de gente de produto. Então, lá atrás eu me interessava bastante sobre tecnologia, quando eu digo lá atrás é realmente… Sei lá… Anos 90, né? O meu ensino médio, na época era segundo grau, era técnico, então aprendi a programar em Cobol, clipper etc. Internet estava bem incipiente no Brasil, começando a dar sinais de que aquilo realmente ia mudar o mundo, né? Com modem de 14400, e aí eu pensei: Eu quero trabalhar com isso, né? Mas na época não tinha nenhuma universidade e tal que tinha um curso assim específico para web, era tudo bem desenvolvimento de sistemas clássicos. Então o cara vai lá e faz um software de locadora, esse é o exemplo clássico, que eram milhares de exemplos assim. E daí isso não me atraiu muito, naquela época as linguagens de programação eram bem ruins, em termos de interface e tal, não me atraiu muito. Aí eu acabei vendo que tinha um curso, né, que lidava um pouquinho com design,  esse tipo de coisa, porque eu, obviamente, eu via a web do consumidor, então HTML, CSS, essas coisas. E aí eu fui para a publicidade e propaganda com a esperança de que isso ia me ajudar a ser um web designer. Veja só!

A: Boa ideia.

S: Pois é. Claramente não foi a melhor decisão da minha vida, o curso de publicidade me deu algumas noções interessantes e tudo mais, mas logo eu comecei a trabalhar em agência, já no primeiro semestre, gostei bastante daquilo. Primeiro eu trabalhei com gráfico e depois como redator e tal, bem na parte criativa, achei legal e tudo, mas eventualmente depois de 6, 7 anos disso, me encheu o saco.  Aí eu abri uma agência de publicidade, que eu pensei: Pow, eu manjo do business e tal, talvez isso seja um pouquinho melhor. Essa foi a minha primeira parte de empreendedorismo, meu primeiro negócio. Não estava muito satisfeito anyway, a minha agência também não era lá um grande sucesso, dava basicamente para pagar algumas contas e nada mais. Aí eu descobri, meio que procurando por intercâmbios e reavaliando a vida, aquela coisa do jovem, pensando o que poderia ser, eu descobri a AIESEC, que era uma organização estudantil, e tinha intercâmbios e tal. Eu comecei a me envolver com aquilo, comecei a trabalhar como voluntário enquanto eu tinha minha agência. Daí como voluntário eu trabalhava na AIESEC com recursos humanos, desenvolvimento de talentos e coisas assim, até que surgiu uma oportunidade de eu fazer isso na Noruega. Fui, fiquei 3 anos lá, trabalhei em outras coisas também, mas tudo em volta de gestão de talentos. Daí eu fui para a Índia, de novo com isso aí, fiquei 6 meses lá, trabalhando na Tata Consultancy. Aí quando eu voltei para o Brasil, eu estava perdidaço. Então cara, desenvolvimento de talentos também não era uma coisa muito interessante, na AIESEC era superlegal, mas na maioria das empresas acabava sendo muito burocrático. Então, a maioria das empresas tem uma tradição de RH de burocracia, de carimbador de papel. E cara, imagina o baque, né? Depois de morar na Noruega e na Índia, volto para a casa dos meus pais, derrotado, sem uma profissão. Caraca, o que eu estou fazendo, tá ligado? E aí estava no auge do Lean Startup, né? Então eu li o livro, fiquei encantado e tal… Pow, eu vou fazer essa parada! Minha segunda startup, tinha a ver com gestão de talentos, se chamava teamometer, que era um termômetro do time. Cometi erros clássicos de empreendedor idiota, por exemplo, eu criei um MVP que era um vídeo e tal, a galera se inscreveu e aí eu já achei que a ideia estava validada e saí construindo. Ah, meu amigo! Eu não tinha ideia do que eu estava fazendo. Mas, assim, eu fiquei 2 anos com isso, com outros 3 sócios e tal, e mais um funcionário. Eventualmente, cara… Não deu certo mesmo, não conseguimos ganhar grana nenhuma e tal, foi isso… Aí eu escrevi um post sobre o que eu aprendi, quando rolou isso aí. E esse post ficou em primeiro no hacker news, por um tempo ali, aí crashou meu site e tal, o blog era wordpress, uma coisa assim. Aí crashou e tal, teve 40 mil views na primeira semana, foi massa! Isso aí meio que me acendeu de novo aquele negócio: Pow, na época que eu trabalhava com agência de publicidade, era tudo meio que offline e tal, o online ainda não estava acontecendo, mas isso aí já era… 2011 ou 12, né? E aí pow, a internet já estava superdesenvolvida, tinha online e tal, e aí eu comecei a procurar emprego em marketing digital. Achei, os caras ficaram impressionados com esse negócio do blog, por exemplo, era uma empresa super convencional que queria começar um departamento de digital. Aí eu comecei o departamento, contratei o primeiro funcionário depois e tal, beleza… Foi um sucesso e tudo mais, e aí eu esbarrei com o RD Station marketing, que era o software lá que a gente ia usar para começar a fazer inbound marketing. E aí eu fui a uma conferência da RD lá em Porto Alegre, e pow, me apaixonei pela empresa, né? A cultura e tal… Inclusive um dos founders estava palestrando e ele explicitamente falou sobre a AIESEC, daí eu: Pow, os caras estão procurando gente com o meu perfil, vou ver isso aí. Entrei no site e ao invés de aplicar para o marketing eu olhei outras vagas, e aí eu: Pow, esse negócio de product manager parece interessante! Aí eu apliquei…

A: Isso foi em que ano?

S: Isso foi em 2016. Eu apliquei e dei sorte que na época a RD estava contratando gente com potencial, mas que não era PM formado. Eu tinha minha experiência empreendedora, conhecia um pouco do mercado de digital, conhecia digital, então ajudou pra caramba, e aí o resto é história, assim… Eu acredito que achei a minha profissão, cara, eu amo ser gerente de produto e é isso.

A: Legal, legal! E hoje tu é gerente de produto aqui na Resultados Digitais?

S: Exatamente! Há 3 anos e alguns meses.

A: Muito legal! Muito legal! E, cara, enfim… Tu falou lá no início teu background hoje é de…  Teu background hoje, hoje não né? Sempre! Foi de publicidade e propaganda. Como é que na profissão de product manager isso te ajuda ou te atrapalhou nessa história toda?

S: Bom, primeiro que eu acho que eu só entrei na RD porque eu tinha esse background. Então, como o produto da RD tem a ver com marketing, eu conhecia na prática como era ser esse usuário, isso me ajudou muito. Então, já saí na frente. Mas fora isso assim, PM tem muito de vendedor e comunicador, e tu escrever as coisas claramente e passar as mensagens certas. Então eu acho que tudo isso me ajudou bastante, assim, né? Tanto para formatar o pensamento como para comunicar isso para outras pessoas.

A: É! Eu acho que essa é uma das coisas inclusive que, acho que principalmente quando a gente vai em evento, ou fala com pessoas que estão querendo entrar no mercado de gerenciamento de produto, uma coisa que eu falo com bastante frequência porque às vezes você tem que usar as coisas que você já sabe, né? E às vezes quando você pega isso… Putz, tu já tinha uma história em marketing, tu já tinha um… Enfim… Publicidade e propaganda etc, que não é exatamente a mesma coisa, mas tem um overlap de conhecimento, e daí quando você aplica para ser PM numa empresa como a Resultado Digitais, que trabalha com marketing, obviamente que esse teu background ele favorece e acaba sendo um diferencial até com relação a outras pessoas que estão concorrendo para aquela vaga. Mas ao mesmo tempo, de repente, se fosse para uma empresa que não tivesse nada a ver com esse mercado, possivelmente seria um pouco mais dolorido fazer essa transição.

S: Com certeza! Com certeza! Acho que essa é a primeira dica mesmo, aproveita o que tu sabe e procura empresas que vão aproveitar esse teu conhecimento e experiência prévia. Eu acredito piamente que isso me ajudou muito a entrar aqui, e esse acho que é o primeiro passo para quem… Porque PM é um bagulho que é tão “generalista” que é muito difícil tu ter feito alguma coisa que não vai te ajudar, como PM. É óbvio que existe, mas é muito difícil. Cara, sempre tem alguma coisa, e aí tu tem que achar essas coisas e vender isso, né?

A: Sim, sim! E eu acho que tu tinha duas coisas, né? Que é essa questão do empreendedorismo… Pelo menos duas coisas, né? A questão do empreendedorismo e essa questão de estar próximo do business da Resultado Digitais quando tu entrou.

S: Exatamente!

S: Aí fora, obviamente, das tuas coisas aí de vivência fora do Brasil, etc, etc… Que sempre agregam de alguma forma, mas acho que são coisas super importantes. Legal cara, e trocando um pouco de assunto, mas acho que para quem já te viu em algum lugar certamente teve teu nome associado à jobs to be done em algum momento, né? Então, desde palestra em eventos, treinamentos que tu dá, blog posts e etc., tu é uma pessoa que fala bastante sobre isso. Eu não quero ficar estressando aqui esse conteúdo específico porque, de novo, acho que tem várias outras fontes aí para aprender sobre isso, mas para quem nunca ouviu falar, o que é jobs to be done e onde essa pessoa pode conseguir mais informação sobre isso?

S: Bom, Jobs to be done é uma teoria, né? Uma teoria lá, que vem lá do marketing e tal, mas basicamente como eu enxergo isso, é uma lente, então é uma forma de enxergar o mundo para desvendar as decisões que um consumidor toma. Então com isso tu entende as motivações das pessoas, que problemas elas têm, o que elas avaliam para trocar uma solução por outra e esse tipo de coisa. E sobre onde encontrar, acho que um livro que eu sempre recomendo, para começar assim, é o Muito Além da Sorte, que na verdade é uma tradução meio esquisita, porque o nome em inglês é Compete Against Luck, Competindo Contra a Sorte, mas é do Clayton Christensen, que é um dos caras que fundou a teoria aí e tal, é professor de Harvard e etc. E é muito bom, assim… É o tipo de coisa que te ajuda muito a enxergar a estratégia e esse tipo de coisa.

A: Legal! E como é que tu chegou nesse framework jobs to be done? 

S: Cara, tem muitos artigos, até livros e tudo mais, explicando os benefícios de usar jobs to be done para a inovação. Então, tem tudo a ver com trabalho de PM, só que a maioria, sei lá, 99% desses artigos e livros e tudo mais, ele te explica a teoria, tu fica encantado, mas tu não faz a menor ideia de como usar aquilo, de como começar e de como descobrir os jobs dos clientes. Aí eu comecei a tentar a fazer isso de alguma forma, né? Aí eu meio que descobri um curso que era de outros caras que eram fundadores dessa teoria também, que era o Bob Moesta e o Chris Spiek, e esses caras tinham um curso online específico sobre como fazer entrevistas para extrair jobs to be done. Aí foi um abraço, né? Aí eu aprendi isso e vi: pow, esse negócio é sensacional! Usei aqui na RD já várias vezes, inclusive no ano passado, em um estudo, até meio sem compromisso assim… Foi meio um side job que eu fiz, com outro e o UX designer, que a gente meio que mapeou os jobs do RD Station marketing e isso norteou toda a estratégia do RD Station marketing para esse ano. Pow, foi super legal! Aí eu vi que pow, a maioria dos caras que falam sobre isso são consultores, então por isso que eles não te dizem como fazer, porque eles querem vender a consultoria, é o marketing deles esses posts, né? Então pow, eu criei um workshop justamente para reproduzir isso, né? Como fazer essas entrevistas, como extrair esses jobs de entrevistas com os clientes. 

A: Só para deixar mais palpável, quando a gente está falando de jobs e etc. acho que tem aquela analogia clássica da furadeira com o furo na parede, que é tipo, quando você vai comprar uma furadeira, você não quer uma furadeira, você quer o fura na parede. Mas enfim, só para deixar esse negócio… Que a gente está falando de jobs mais palpáveis, acho que seria isso, e como extrapola, como que você entrevista as pessoas para descobrir o que de fato elas querem.

S: Exato! No meu workshop eu dou até um exemplo, assim, a job é mais ou menos assim: ah, eu quero escutar as músicas que eu gosto enquanto eu estou na rua me deslocando. Aí se tu for pensar, essa job, e a maioria das jobs são assim, ela existe há muito, muito tempo, né? E é por isso que ela é útil para inovação. Então, lá atrás tinha um cara usando aquele boombox, carregando aquele troço gigantesco, aí depois veio o walkman com a fita cassete, aí depois o discman, aí depois o ipod e agora Spotify, Deezer, etc. Mas o job é o mesmo, só a solução que muda, e é isso que torna jobs to be done poderoso, tu entende a necessidade real do usuário e como ele avalia aquilo, né? Então, se tu entende como ele avalia a solução, tu consegue melhorar ela, não só um pouquinho, mas com níveis de magnitude muito maiores. 

A: Uhum! Show! E nesse tempo todo aí que tu está aplicando job to be done e etc, ensinando outras pessoas a fazer e tudo mais, qual que foi o teu maior aprendizado aí aplicando o jobs to be done?

S: Pois é, cara! Acho que tem alguns assim, mas eu acho que o maior assim, ele é até meio óbvio, assim… Mas até tem a ver com aquele negócio lá do Henry Ford, que se perguntasse para as pessoas, elas iriam dizer que queriam cavalos mais rápidos, né? E eu acho que muitas vezes a gente como PM, ou UX, ou researcher, ou whatever… A gente faz o tipo de pergunta e o cliente responde com o cavalo mais rápido, e a gente acredita que aquela é a resposta certa, né? Então eu acho que aí é entender que o que o cliente diz não é o que de fato ele quer. Então tu tem que meio que desvendar isso aí, e jobs to be done é uma framework útil para isso. Tem N maneiras de fazer isso, essa é só uma.

A: Show! E, cara, jobs to be done, no final das contas, tipo, ele é um framework, dentre vários outros que a gente tem para fazer product discovery. Então, acho que não é a única alternativa, tem várias outras. Então assim, independente de product discovery, por tudo que tu já estudou, aprendeu, aplicou etc., com relação a isso, o que que é um bom processo de discovery para ti?

S: Eu acho que assim… Tipo, primeiro ele  te desvenda um caminho, ou o caminho, ou os caminhos, para ti chegar em um objetivo, né? Então tu mitiga riscos e tal, mas basicamente tu descobre oportunidades, alavancas,e chega lá. E eu acho que tem uma coisa assim do que é um bom processo de discovery é a interação rápida, né? Aprender rapidamente. Então, legal, tu pode ficar um ano em discovery, mas será que tu realmente não podia descobrir isso em 1 dia, né? Tem um exemplo muito bom que eu vi no workshop do Marty Cagan, que era um PM lá do Google Glass, não me lembro o nome, era alguma coisa Chu… Era um Chinês, para variar. Eles estão em maioria do mundo, né? Que basicamente eles ainda não… Eles tinham uma hipótese de que eles iam fazer o Google Glass ser manipulado, né? Interação do usuário Google Glass, estilo Minority Report, né? Aquele negócio com o braço esticado e mexendo as mãos e tal, e isso moveria. Aí o que os engenheiros queriam fazer era: pow, vamos fazer um protótipo disso aqui, e tal e não sei o que, para testar. Só que só para fazer o protótipo, que eles mandavam lá para uma loja de protótipos do Google, demorava 3 meses. Aí chegou esse PM e disse: Não cara, como é que a gente pode testar essa hipótese hoje? Aí ele: Não! Isso é impossível e não sei o que… Enfim, aí rolou uma discussão,bonitinha e tal, mas no final eles conseguiram testar com… Botaram um projetor, aí meteram um clicker, desses de passar slides na mão do cara, aí isso passava o slide, enfim…  Era toscão pra caramba, mas no fim eles viram que todo mundo ficava com uma dor nos braços insana, porque tu ficar com os braços esticados não faz sentido nenhum. Daí eles viram que pow, essa hipótese já está furada, né? Imagina, os caras iam levar 3 meses para fazer isso, e conseguiram em um dia, então eu acho que isso é um sinal de um bom processo de Discovery. 

A: Descobrir o quanto antes, mitigar os riscos ali o quanto antes.

S: Exato! 

A: Legal! E como é que tu se organiza antes de começar um processo Discovery? Como que é o teu processo para fazer isso? Ou, enfim, se você tem algum método, ou seja lá o que for…

S: Sinceramente eu acho que eu não tenho um método, tá? Mas eu acho que o que eu tendo a fazer é abrir um documento para começar a escrever alguma lógica daquilo. Então, tipo assim, bom… Qual que é o problema? Onde que eu quero chegar, né? Qual que é o objetivo? Então a partir desse objetivo, o que que eu já sei? E o que que eu não sei? E aí começa aí a interação mesmo, né? A entrevista com o usuário, olhar números, gerar hipóteses na minha cabeça e ver se eu já sei ou não, ou como eu posso saber. Eu acho que é mais ou menos assim, aí vai inteirando nesse documento aí. 

A: É, enfim… É um processo que ele não acaba, né? Ou pelo menos até você dizer que acaba, porque você pode ficar investigando indefinidamente e tu meio que usa esse mesmo documento para ficar inteirando para sempre… Assim, algo muito perene durante o processo de discovery pelo menos?

S: Sim, eu tenho ultimamente feito, usado bastante aquele negócio da árvore de oportunidade, da Teresa Torres, que eu acho uma forma super útil de estruturar o pensamento. Mas eu parto do documento, aí quando eu começo a descobrir as coisas que eu começo a estruturar nessa árvore. Então, o objetivo lá em cima, algumas oportunidades e se vai surgindo ideias também, vou botando essas ideias, mais ou menos assim que eu organizo.

A: Entendi! Aí depois que tu começas a organizar isso, tipo… Tu vai alimentando isso de acordo com que tu vai descobrindo as coisas, ou tu deixa acumular essas coisas e revisa no final? Como é o teu processo  de revisão?

S: Não. Geralmente eu vou atualizando com as minhas descobertas, assim… A única coisa que eu atualizo mais no final são quando eu faço um grupo de entrevistas conjuntas. Então pow, essa semana aqui eu vou entrevistar 10 usuários. Então eu faço um output de cada entrevista, separadamente, num outro doc, isolado daquela entrevista, finalizo cada entrevista com o too long didn’t read, para ser fácil de recapitular o que que era aquilo, e aí no final eu meio que processo tudo, reflito e ponho as conclusões do doc lá. 

A: Legal! E… bom… Acho que nesse documento tem algumas perguntas específicas que tu tenta responder sempre? Ou também é uma coisa que varia de acordo com o problema que tu está tentando resolver? 

S: Varia, mas tem temas, né? Então, pow… Eu já falei por exemplo de oportunidades, né? Quais são as maiores alavancas para gente chegar no objetivo? Então acho que essa é uma pergunta que está sempre em tudo, que a gente faz. Aí é aquele negócio que tu falou, né? De mitigar os riscos. Então tem sempre perguntas em relação ao valor daquilo, se a gente vai conseguir entregar valor, se é possível fazer aquilo, ou tipo qual é o custo daquilo.  Pow, não adianta eu resolver um probleminha micro, mas que vai demorar um ano para eu desenvolver aquilo. Então não é uma boa solução por mais que resolva o problema. Se o usuário consegue usar e se tem alguma coisa que afeta outras áreas além de produtos, que afete o negócio em si, esse é um pouquinho mais raro, mas teve agora… Tem agora uma coisa que a gente está fazendo,  que a gente está olhando para um dos nossos planos e meio que reempacotando ele, né? Então, isso impacta outras áreas de negócio também.

A: Quem vem daqueles riscos do Marty Cagan?

S: Exato!

A: Legal! Eu acho que esse framework é super bacana porque, não vou dizer nem genericamente, mas mesmo eu no começo… A gente, normalmente quando vai fazer discovery, você foca muito na questão de valor ou usabilidade, né? No máximo essas 2 coisas, e você tende a pensar o processo como se fosse igual para tudo, e às vezes, risco de valor é clássico, né? Às vezes cara… Risco de valor aqui é baixíssimo, mesmo que isso aqui não tenha risco de valor, tem que ser uma coisa extremamente no brainer, uma das coisas que quando você vai resolver… E não tem porque ficar investigando se aquilo vai ter valor ou não vai. Acho que no caso da RD,  pode sempre fazer uma ferramenta de teste A/B de email. Cara, em 2019 tu não precisa mais validar se teste A/B de email entrega ou não entrega valor, né?  Vai validar outras coisas.

S: Isso, exatamente.

A: Então eu acho que isso ajuda muito a pensar nisso, e às vezes assumir já algumas coisas de começo que pode te cortar alguns caminhos aí.

S: Eu acho que isso aí que tu falou tem 2 erros clássicos de PM e eles são meio opostos, assim. Um é o cara que não valida, que ele simplesmente está na cabeça dele e ele vai fazendo, que foi o caso da minha startup lá, que foi um pouco assim. Ou valida muito pouco, né? E assume várias coisas como verdadeiras que não necessariamente são. E o contrário, que é o cara que valida tudo, mesmo o óbvio. Inclusive eu tive, semana passada eu acho, uma conversa com o UX designer de um dos meus squads, que ele queria fazer um teste assim, assim, assim e tal, aí eu falei: Cara, mas… Velho tu está há 2 anos nessa feature aí, cuidando dessa feature. Tu não sabe essa resposta? Daí ele pensou um pouco, assim e tal: Pow, eu acho que eu sei, hein. Aí e tal e coisa. Aí eu: É cara, não adianta testar o que tu já sabe, isso é perda de tempo.

A: Sim! Sim! Sim! Daí eu acho que também tem um ponto que você tende a diminuir muito esse… Acho que feeling é exagero, por que é tipo um conhecimento acumulado durante, nesse caso que tu citou, de 2 anos que tu trabalha com aquilo, que tu está absorvendo e falando… Absorvendo conhecimento, falando com pessoas, falando com o cliente, estudando outras coisas que se relacionam com aquilo e você tende a não querer usar isso, né? Acho que para tudo você está buscando uma evidência lá, o que às vezes faz muito sentido, mas acho que o ponto é tipo não menosprezar também esse conhecimento acumulado que tu já tem, esse feeling em última instância de que: Cara, parece que por tudo que eu já estudei sobre os problemas , isso aqui vai funcionar ou não. Acho que tem uma arte também de saber quando questionar essas coisas, mas é o ponto para mim é que acho que não dá para menosprezar isso, né?

S: É! E assim ó… Eu não diria nem que é feeling, sabe? Tipo assim… Mano… Tu está há 2 anos ouvindo, por exemplo, o suporte reclamar de um problema x. Tu acha realmente que esse problema não existe? Que chance que tem de não existir? É baixo porque as pessoas tendem a confundir ser data driven que é inclusive um valor da RD com dados quantitativos. Ah, eu tenho 10 biscoitos aqui, então essa… Não, cara… Uma entrevista é um dado também. Então, considera isso como um data apport também.

A: Perfeito! Bom, acho que uma pessoa que é super importante, um papel que é super importante durante o processo de Discovery é o papel do designer, né? Como que é essa tua relação com o designer durante o processo de Discovery? O que vocês fazem em conjunto e o que que não fazem? Acho que é sempre essa coisa de qual a responsabilidade de cada um, também é uma pergunta eterna aí. Mas eu acredito muito que depende muito de par para par, acho que não tem uma receita de bolo, mas na tua vivência como que é isso? 

S: Primeiro acho que tu falou o que eu já queria falar, né? Primeiro, é um par, né? Segundo, isso varia de par para par. Então, depende do PM, depende do designer… Eu por exemplo, eu tenho 2 squads hoje, e o meu relacionamento com os UX designer de cada time é diferente. Então, dependendo um pouco do perfil, de como a pessoa gosta de trabalhar e tal… Dito isso, eu entendo que se tu precisar fazer um clear cut, tipo assim, tu é responsável por isso e o designer é responsável por aquilo, eu acredito que o PM ele é mais o “dono” do problema. Então ele está, digamos assim, no banco do motorista na hora de fazer o Discovery do problema. Enquanto o designer, ele é mais dono da solução. Então, ele está no banco do motorista para a solução. Mas óbvio que isso é um vai e vem, e os 2 trabalham juntos, né? Eu só não trabalho junto com o designer se por algum acaso, o designer está muito ferrado com alguma outra coisa e eu posso sair um pouquinho na frente. E aí quando ele ficar mais liberado a gente se junta e eu: Ó, cheguei até aqui, descobri isso aqui, e agora vamos lá! Mas em geral é os 2 juntos, assim…

A: E quando que ele, o designer, entra no processo, assim?

S: Depende, mas assim… Tendo a preferir que seja o mais cedo possível, né? Porque por mais… Por melhor que seja o PM, sempre vai ter um pouco de viés, né? Enfim… Pode ter coisas que tu perdeu. Então, tentar trazer o designer mais cedo… Então, a gente tem esse objetivo aqui. Legal! Vamos então começar a explorar nossas oportunidades aqui. Já traz o designer para as entrevistas com o cliente e tal, até porque, geralmente, o designer é muito bom nisso, então uma disciplina bem desenvolvida em designer research… Então, já traz e tal. E aí, cada coisa que a gente vai descobrindo, a gente não só… Não fica só entre o designer e o PM, né? Essa é uma coisa que eu acho que me ajudou muito como PM. Cara, finalizou uma entrevista, descobrimos tal coisa, já vai no canal do slack do time: olha só que legal isso aqui e tal. O cliente disse isso aqui, enfim… Porque daí o time nunca, principalmente engenharia, nunca é pego de surpresa… Pow, mas eu não sabia que você estava pensando sobre isso! Tu começas a construir lá atrás esse conhecimento com o time, daí quando tu vais fazer o produto já é óbvio o porquê, quais são as dores, enfim…

A: O time já tem o contexto, né?

S: Exato!

A: Legal! É, eu acho que a próxima pergunta é justamente com relação a isso, né? Existem outras pessoas, outras funções dentro do time que tu envolve nesse processo discovery? Ou é um negócio mais centrado em PM e designer mesmo?

S: É um pouco mais centrado em PM designer, mas a gente acaba não fazendo muito isso porque muitos engenheiros não estão tão afim de participar de certos discoverys, por exemplo, entrevistar cliente. Então por mais que a gente acabe abrindo: Ó! A gente vai entrevistar o cliente, alguém quer participar? Raramente de fato essa oportunidade é pega, pelo menos nos meus times ali. Mas a gente tenta nunca dizer: Ó, a solução é x, vamos construir. Não, não! A gente conversa com o time para entender que soluções existem, que possibilidades existem, qual é o grau de dificuldade de cada coisa, né? Bem por linhas gerais assim… E se eles têm ideias também. Então várias vezes a gente brainstorm, né? Então, uma vez que a gente começa a montar a árvore de oportunidades ali que eu falei, várias vezes é tipo: A gente vai se focar nessa oportunidade aqui por causa de X,Y,Z. Esse aqui pareceu o maior caminho. Agora vamos fazer um brainstorm de solução: Ah, tem esse approach, tem esse approach, porque muitas vezes engenharia vê alguns atalhos que a gente em produto não vê, né? Então pow, essa solução aqui pode demorar 2 semanas para ser feita, mas dependendo, se tiver uma pequena variação, vai demorar um dia. Pow, parece que é uma grande aposta aí, né?  

A: Sim! Sim! E tu tem experiências também para compartilhar nessa linha de envolvimento de engenharia durante o processo de discovery, de repente coisas que tu fez que: Putz, isso daqui deu… Pelo menos na tua experiência, né? Deu muito errado e eu não recomendo que alguém faça, e do inverso também, né? Putz, testei essas coisas, tu já deu uma dica que é: Vai compartilhando as coisas do discovery, que estão descobrindo com o cliente etc. no canal, para já envolver o pessoal de engenharia, para já ter o contexto. Mas, enfim, nos dois extremos, né? Porque acho que esse é um dos maiores dilemas do processo de discovery é como você envolve adequadamente a engenharia. E o que que tu aprendeu nessas coisas, tanto de positivo quanto de negativo, assim?

S: Bom, os positivos eu acho que é isso aí mesmo. Envolve cedo, tenta fazer o escopo um pouquinho mais variável, né? Mas uma coisa que para mim fez diferença bem grande para conversar com engenharia, foi o conceito de apetite, que eu li lá naquele livro do Basecamp lá… Shape up, que recém lançaram, que é basicamente assim: Olha, eu tenho essa solução aqui, mas eu estou imaginando que ela só vale a pena se a gente gastar, sei lá, no máximo 2 semanas aqui. Se passar muito disso, não vale a pena, a gente faz outra coisa. Quando eu não falava sobre isso com a engenharia, muitas vezes eu acabava frustrado, porque o que para mim parecia um negócio minor demorava, sei lá, um mês. E aí eu começava a entrar em desespero porque aquela solução não valia um mês. Então isso aconteceu algumas vezes na minha carreira até que o meio que comecei a fazer um pouquinho intuitivamente isso de apetite, e aí quando eu li o livro, e fez todo o sentido: Cara, é isso daqui. Aí eu comecei a falar com os engenheiros sobre isso. E agora os próprios engenheiros falam, perguntam para mim: Tá, mas quando eles veem uma solução, mas qual é o apetite tem pra isso, né? Quanto que a gente quer gastar aqui? Então eu acho que esse é um aprendizado bem grande de dizer quanto tu quer investir para ver se faz sentido. E aí quando tu diz quanto tu quer investir, os engenheiros podem retornar com: Não! Essa solução assim não vai rolar nesse teu apetite. Mas se a gente fizer X,Y, Z pode dar. É uma interação um pouquinho melhor. 

A: Legal! Legal! E bom… Depois de fazer esse processo, mesmo durante, né? A gente até falou um pouco de documentação lá, que tu mencionou algumas coisas, mas eu acho que é um desafio constante como é que você documenta o que está sendo descoberto. E a minha curiosidade é justamente saber como que tu faz isso hoje sem ficar criando toneladas de documento, ou até criando coisas que rapidamente elas acabam ficando desatualizadas e já não faz mais sentido, às vezes, no final do discovery o documento que do começo já não faz mais sentido. Então, como é que tu faz isso?

S: Cara, eu não sei se eu sou tão bom nisso, nesse negócio de não estar desatualizado, por exemplo, né? Mas eu tenho um documento mestre que tende a ter as principais descobertas ali, e que vai linkando para outros documentos, se a pessoa que estiver lendo quiser se aprofundar pode ir para lá. Mas eu escrevo meus documentos pensando assim ó: Se alguém sem contexto algum cair nesse documento, essa pessoa precisa entender a lógica, por onde que a gente passou, o que que a gente descobriu e tal. Então ele acaba, às vezes, ficando até meio longo, mas eu garanto que qualquer pessoa do negócio que ler aquilo vai entender a justificativa, e isso acaba tendo um shelf life maior para o documento. Porque não é um troço que é simplesmente uma planilha aleatória que tu não consegue nem entender o que aconteceu ali, é um step by step, um passo a passo ali ó: A gente entrevistou clientes e descobriu isso daqui. Ah, tu quer saber mais sobre as entrevistas? Clica aqui e vai lá que tem os áudios e tudo mais. Daí a gente explorou tais e tais dados,  ó: A descoberta foi essa daqui. Quer mais explorações? Tem aqui. E assim vai… Aí a pessoa vai lendo e é como se fosse uma história sendo contada, o problema é esse, daí eu descobri isso, daí eu quebrei a cara aqui, daí eu fui pra lá… É bem de documentação mesmo.

A: Legal! Legal! E a própria árvore de oportunidade também acaba sendo uma documentação disso de alguma forma, né?

S: Sim, sim sim! Só que essa aí precisa ter um pouquinho mais de disciplina para ler, né? Então, para mim ela funciona, mas eu não sei se uma pessoa aleatória do business, assim, se cair lá, vai entender alguma coisa, sabe? 

A: Uhum, uhum! Não, perfeito! Acho que ela acaba não sendo autoexplicativa, mas ao mesmo tempo… Pelo menos, na experiência que eu tenho, ela acaba me ajudando muito sendo uma forma talvez enxuta de fazer esse processo de documentar isso sem grandes esforços de escrever de fato, mas está sempre ali atualizando o que está acontecendo e… Putz, descobrir tal coisa e etc. Para mim, tem sido uma ferramenta bem versátil nesse sentido.

S: É! E não, e assim… Para organizar a tua própria cabeça no discovery é fantástico, né? Porque às vezes tu está comparando soluções que na verdade são de oportunidades diferentes, né? E esse é um clássico, né? De um sei lá… Vai  discutir com algum desenvolvedor, ou coisa assim, o cara acredita na ideia x e tu acredita na ideia y, mas na verdade são oportunidades diferentes que essas ideias de solução estão resolvendo. Então não faz sentido tu comparar elas. Tem que comparar, nesse caso, as oportunidades. Qual que é a maior oportunidade? X, Y… Ah, legal! Dentro de x, quais são as ideias? Isso ajuda a guiar o próprio brainstorm, em ter coisas menos aleatórios surgindo.

A: Sim, sim! E eu descobri um valor recente com relação a isso também, porque nessa mudança recente que eu fiz agora de entrar no Nubank, né? Isso me ajudou muito também a entender o que de conhecimento que a gente tem. Então você começa a falar com as pessoas e começar a ler documentos, você começa a estruturar aquilo numa árvore de oportunidade e rapidamente você começa a ter uma visão onde: Beleza, é isso aqui que a gente sabe no momento em relação a isso, e é uma forma até de ver progresso também no teu esforço de discovery, porque tu sabe se aquela árvore está estática há muito tempo é provável que tu esteja deixando de fazer, de conversar com o cliente, de procurar input para deixar aquilo mais claro ou repensar a estrutura dessa árvore. Então, acho que é uma forma muito simples também de você conseguir documentar esse conhecimento e expandindo ele baseado no que já existe,  que você consegue fazer isso baseado no que já existe, e a partir dali ir desenhando uma forma… 

S: Perfeito! 

A: Show! E, de novo, né? Daí voltando na questão do documento e etc., Da forma como tu faz hoje, o que que tu vê de principais pontos positivos de fazer desse jeito versus outras coisas que de repente tu já testou no passado? 

S: Cara, eu acho que o principal é isso que eu falei, de uma pessoa sem contexto algum pode cair ali e entender o que que está rolando. Eu acho que isso é o principal valor de, sei lá,  às vezes eu noto que nos meus documentos, eu vou abrir para atualizar ele e tem uma pessoa aleatória lá de customer success lendo aquilo, tá ligado?E aí deixando comentários e tal. Então eu acho que esse é o grande valor, de qualquer um poder contribuir.

A: E tu já testou fazer isso de formas diferentes antes? Tem alguma experiência que tu fazia de tal forma e de repente não deu certo, né? Como é que tu chegou nesse formato?

S: Pow, sinceramente eu não sei. Talvez tenha sido um pouco orgânico, tá? Mas isso eu acho que foi até um cacoete que eu peguei do Diegão, o Diego Pereira. Que quando eu entrei foi o meu primeiro líder ali, né? E ele estava fazendo um discovery lá, nem me lembro exatamente o que que era, e ele começou assim: Ele abriu um doc e saiu escrevendo. E a gente ia atualizando esse doc e tal. E eu meio que a partir daí eu meio que: Pow, esse negócio faz sentido. E comecei a usar. Então, acho que eu nunca tive assim um outro método muito específico, acho que a qualidade dos documentos melhorou bastante, a estrutura de contar a história e tal, porque às vezes tu lê uns documentos que não faz sentido nenhum, é um bando… É uma coleção de informações aleatórias, que tu não sabe exatamente a que conclusão que o PM chegou. Mas acho que sempre foi meio esse o meu modelo. 

A: Legal! Cara, a gente falou de um monte de framework, ferramentas aqui, desde árvore de oportunidade, jobs to be done e por aí vai, o quanto tu realmente segue essas coisas ao pé da letra, assim… Ao pé do que elas são definidas, de como a Teresa Torres definiu a árvore de oportunidade, de como o Clayton Christensen definiu o que é jobs to be done, e por aí vai…. Como é que tu realmente segue isso ao pé da letra? Ou quanto tu tem tua licença poética para variar um pouquinho?

S: Provavelmente ao pé da letra 0%, né? Assim, uma framework ela deve ser adaptada à realidade, ao negócio, ao tipo de Discovery, enfim… Tem uma série de fatores aí que tu precisa adaptar. Às vezes até a tua própria capacidade ali, né? Então, para mim uma framework é uma maneira de explicar como uma ferramenta funciona, ou pode funcionar, mas não deve ser seguida sempre 100% à risca, a não ser que realmente para ti faça sentido isso, mas não pode ser aquela coisa xiita, né? De religiosidade. Não! É assim que funciona, senão tu tá fazendo errado. Não, pow! Se tu chegar no resultado certo, está bom! 

A: Uhum, uhum! É… Eu acho que você tende a começar mais ao pé da letra as coisas, né? Eu acho que… Ali você já faz, obviamente, uma interpretação tua, sobre aquilo que tu tá lendo é uma adaptação natural à realidade que você tem ali, né? Mas, o que eu vejo muito também, de experiências minhas, é muito nessa linha de que você começa, ás vezes, entendendo o que está mais próximo do que você está lendo, tentando replicar, as vezes até usando algum modelo, ou seja lá o que for, mas com o tempo, naturalmente, você tem que adaptar, e eu acho que é justamente esse ponto, né? De não ser xiita porque senão você fica com uma coisa que não faz sentido para a tua realidade, mas você só está seguindo porque… Sei lá quem falou que deveria ser desse jeito.

S: Exatamente! É só o processo, né?

A: Exato! E como é que tu começa a conhecer essas horas de burlar essas regras, né? De não seguir exatamente as coisas como elas foram definidas, ou de até de inventar coisas diferentes, ou de misturar coisas… Como, quando que tu começa a identificar isso? 

S: Eu acho que surge das necessidades, né? Até assim, esse negócio da árvore de oportunidades, por exemplo, eu tinha sentido a necessidade de visualizar o progresso do que eu estava fazendo, né? O que estava validado e o que que não estava. E até recentemente a Teresa Torres escreveu um post sobre isso, que eu estava mais ou menos usando algo parecido, né? Que pow, a árvore ela não pode ficar parada no tempo, né? O que eu quero é olhar para ela e ver: Ó, isso aqui está verde, isso aqui está vermelho, né? E aí eu comecei a fazer. Então, eu acho que surge muito daí, muito da necessidade. Ou então, às vezes, sei lá, esse processo aqui… Um exemplo clássico, aquele o sprint lá do Google, né? Pow esse processo aqui demora uma semana. Ah, legal! Eu tenho 3 dias. Bom, ou tu não faz nada, ou tu adapta para os 3 dias. Melhor tu adaptar para o de 3 dias. Então é isso, né? Surgem necessidades, surgem dores e tu vai adaptando, vai mexendo, vai vendo o que que funciona para ti, o que que não funciona. Meus próprios templates de jobs to be done, eu já tive uns 4 ou 5 diferentes, de entrevista, até que agora eu cheguei no formato que eu estou bem adaptado e gostei de usar e tal. Mas eu sempre falo para  os meus alunos também: Cara, tu tem que usar o que funciona para ti. Testa isso aqui, para mim funciona, talvez para ti não funcione. As pessoas às vezes esperam uma receita de bolo, né? Que funcione sempre para tudo. Mas na verdade na job de PM eu acho que não existe nada assim, né? Não tem nada que seja… Ah, só segue o processo que vai dar certo. Não!

A: É… Eu acho que de novo a gente vai cair aquele negócio, né? Eu acho que quando você está começando, às vezes você precisa de frameworks mais claros, você precisa de uma diretriz porque, de novo, você não tem base nenhuma, você precisa começar de algum lugar, mas em algum momento você vai ter que começar a ter maturidade para começar a olhar essas coisas e: Cara, isso aqui não faz sentido, isso aqui eu vou ter que mudar e etc. Acho que é que nem quando você aprende a dirigir, que eu não como foi para ti, mas pelo menos para mim foi assim, e tipo tinha que começar a dirigir, daí o instrutor falava: Ó, tem uma placa de “pare” ali. Não tinha nenhum carro passando, mas tu tinha que parar na placa de “Pare” porque senão tu ia levar uma multa e tu não ia passar no teste do Detran. Daí com o tempo, na prática, tu não faz isso no dia a dia, né? Não é porque tem uma placa de “Pare” que tu vai lá e para. Antes de chegar na placa tu já está olhando para os lados ali, e pow, não tem nenhum carro, tu passa. Eu acho que framework é exatamente isso assim, né? Existe um framework que é… Tem a placa de “Pare”, eu vou parar, só que com a experiência e com o tempo você vai se sentindo a vontade de ir burlando essas regrinhas. Mas eu acho que é completamente natural… Eu acho até de certa forma é desejado, para quem está começando a seguir as coisas mais ou menos, no mais by the book possível ali… Obviamente que quando você começa com ciclos você: Ah, beleza! Primeira vez que você está aplicando jobs to be done, mas putz, tu já fez entrevista exploratória em algum outro momento da tua vida, tu já sabe como aquilo mais ou menos funciona e etc. e daí você vai agregando esses conhecimentos, né?

S: É… Até sobre esse negócio aí do cara com menos experiência seguir mais by the book, acho que isso é bem o negócio que eu estava falando sobre as dores, sobre as tuas necessidades, né? Então no início… Pow, tu não sabe, então, legal… Tu tem uma framework, tu aplica a framework. Aí tu aplica a by the book, aí tu vê: Pow, mas isso aqui para mim não funcionou tão bem, ou, eu vejo uma oportunidade de melhoria aqui e tal, e aí tu vais fazendo, né? Acho que o que não pode é ficar preso na framework e dizer: Não, se tu não fizer assim não tem jeito. 

A: Sempre lembrar do objetivo, né? A gente está fazendo discovery aqui, a gente tem que aprender alguma coisa, e eu acho que tem que procurar formas de aprender o mais rápido possível e com a melhor qualidade possível, teu objetivo não é aplicar o framework, né? Tipo… Esse é só um meio do negócio.

S: Exato. Inclusive eu ouvi um PM falando: Pow cara… Às vezes eu tenho dificuldade de trabalhar com data science porque parece que o cara, o modelo mental do cara, é aplicar o modelo e não chegar na resposta certa, sabe? Eu disse assim: Cara, não me interessa o cálculo, o que me interessa é o resultado.

A: É exatamente isso. Acho que a gente não pode perder que é “por isso que eu estou fazendo isso”, e não simplesmente aplicar o modelo. Não vou ganhar horas de voo nesse modelo aqui e isso vai me servir de alguma coisa.  

S: Exato!

A: Show cara, muito obrigado! Vamos para o bate-bola? Uma ferramenta de trabalho indispensável pra ti?

S: Cara, o G Suite do Google.

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

S: Pow, é uma coisa muito óbvia que é to do list, eu uso o To Do List, que é um produto fantástico e tal, mas basicamente eu faço dumping mental da minha to do list, eu não preciso mais pensar naquilo e era isso. 

A: Com que frequência tu faz isso?

S: A minha to do list é o que guia o meu trabalho diariamente, todo dia está sempre aberto ali. A ordem das abas abertas é o Gmail, o Calendar e o To Do List. 

A: O que tu está lendo agora? 

S: Estou lendo o Criatividade SA, dos caras da Pixar, lá… E aí pow, eu sinceramente desconhecia assim a história e tal, e tu vê assim as vezes:  Pow os caras conseguiram, né? Virar um super estúdio e tal, por causa de Toy Story, mas tu vê que esse cara, o fundador, ele está há 30 anos tentando fazer um filme digital, é fantástico! A maioria das coisas que a gente fala assim, hoje em dia, até em coisas de videogame e tal, né? Tipo Pixel shadder e não sei o que… Tudo isso foi esse cara que inventou, sabe? E é bizarro assim a história dele.

A: Acho que tem aquele clássico do Malcolm Gladwell do Outliers, que ele fala muito disso, de: Cara, tu precisa de anos… Não sei quantas horas, ele tem um cálculo lá…

S: 10.000 não é?

A: É, uma coisa assim, nessa magnitude, para ter sorte do dia para a noite. Então assim, acho que é bem nessa linha. Quais são os três livros que você recomendaria para qualquer PM?

S: Cara, tem o Inspired, né? Do Marty Cagan, que é meio que o clássico ali, principalmente para PMs menos experientes e tal. Para PMs mais experientes, talvez, não tenha grandes novidades, mas igual acho que é um bom livro, assim. É uma boa teoria básica. Aí tem um livro que eu gostei muito ultimamente, que eu li, sei lá, uns 3, 4 meses atrás, que é o Naked Statistics. Que é muito bom cara! Ele fala de conceitos estatísticos de uma forma muito suave assim, tu entende a lógica por trás das fórmulas, e aí faz todo o sentido, sabe? Ah, tá… É óbvio! Não é simplesmente uma fórmula matemática, muito legal! E e o Muito Além da Sorte, que eu já falei, do Clayton Christensen, que aplique ou não jobs to be done, é um framework mental ali de tu enxergar problemas e oportunidades e tal, que é muito legal. 

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

S: É… Acho que não varia muito, assim. Além dos livros e tal, medium… Bom, um blog que eu gosto muito é o Mind the Product. Tem o teu blog da própria RD, do time de produto, o shipit, mas enfim… É um pouco aleatório, assim né?

A: Tem alguém no medium especificamente que tu segue, ou é aleatório também?

S: Cara, é um pouco… Ah, bom, não é no medium, mas pow, Teresa Torres é  fantástica! Os blog posts dela, sinceramente, para mim são os melhores ultimamente. O próprio blog do Marty Cagan, que o layout é horripilante, mas tem bom conteúdo, o SVPG. E no medium, assim, eu acho que um cara que eu gosto é o John Cutler, acho que ele é bem bacana.

A: Legal! Quem te inspirou? 

S: Na vida, eu acho que bastante a minha mãe. Ela me incentivou muito assim, sempre fez um esforço danado para eu fazer as coisas e tal. Então, acho que isso me deu bastante essa capacidade, essa skill de PM, de quebrar barreiras e fazer acontecer, sabe? Então, eu acho que ela me ajudou muito a acreditar em mim mesmo, e isso continua. 

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

S: Então, acho que esse é uma das coisas, quebrar barreiras. Então, eu acho que o PM, ele não se apega ao job dele, ele simplesmente faz acontecer o que tem que acontecer, né? Se precisar ir lá na esquina comprar pizza e voltar, whatever, o que for necessário para levar aquele grupo do ponto A ao ponto B, que é entregar valor, tanto para o cliente/usuário, quanto para a empresa, né?

A: E o que é um bom produto para ti?

S: Acho que é esse produto aí que resolve muito bem a dor, os jobs do cliente, do usuário, né? E ao mesmo tempo gera valor para a empresa também, né?

A: Cara, nesses anos todos de carreira como PM, e mesmo antes, certamente tudo desenvolveu algum aprendizado que te guia até hoje, que eventualmente tu até ensina para algumas pessoas. Que aprendizado foi esse? 

S: Cara, eu tenho algumas heurísticas, eu acho, que é… Pode até ser um pouco desumano… Mas tipo assim, uma coisa que eu acredito piamente é que é melhor não ter ninguém do que ter a pessoa errada. Isso se provou muitas e muitas vezes na minha carreira, inclusive nessa época aí que eu estava na Noruega, a gente estava passando por um período na AIESEC que pow, cara, ia falir, né? Aí a gente conseguiu reverter isso, quebrar recorde de performance, tudo isso… Óbvio que teve outras soluções, mas a primeira solução foi demitir 50% das pessoas que estavam lá só fazendo volume. Era uma organização voluntária, então, tem um monte de voluntários que só fazem volume. Acho que outra coisa é que é melhor pedir desculpa do que pedir licença. Às vezes, é ok quebrar algumas coisas, né? E eu acho que aí, até um terceiro aprendizado, que é a maioria das nossas decisões que a gente toma, como PM, elas são decisões facilmente reversíveis. Então o risco de tu quebrar alguma coisa, às vezes, é muito baixo, né? Então cara, quebrou, dá a volta, tenta de novo, faz outra coisa, né? E aí, é aquele negócio, das decisões tipo 1 e tipo 2 lá da Amazon. Eu acho que o PM muitas vezes, nessa ânsia de provar as coisas, se estende demais, pesquisa demais, tem certeza demais, para algo que na verdade é facilmente reversível, não precisava gastar tempo, que no fim acaba sendo um desperdício. E eu acho que por fim, é um negócio que eu vi aqui na RD, mas que eu me identifiquei para caramba, que é aquela frase lá do be so good they can’t ignore you. Tipo pow cara, isso aí eu acho que é um mote para a vida de todo mundo, deveria ser, eu acho que inclusive é um bom conselho para quem quer virar PM. Cara, quer virar PM? Então, te esforça muito mais do que os outros, mostra que tu é muito melhor que os outros, e vai dar certo, sabe?

A: Acho que para tudo. Inclusive, mesmo para quem já é PM, eu acho que para continuar evoluindo carreira, eu acho que é isso… Realmente acho que é um negócio super legal, assim. Show cara! Muito obrigado, foi um prazer te ter aqui e obrigado pelas palavras aí. Acho que é sempre um conhecimento super bacana que tu passa, e prazer estar de volta na RD também, estava com saudades já.

S: Nós também.

A: E a gente vai continuando se falando

S: Valeu Spengler! 

A: Obrigado cara! 

S: Brigadão!

A: E só lembrando que o podcast está disponível no Spotify, está disponível no iTunes também, além do soundcloud. Então, se quiser ouvir o podcast diretamente pode entrar em productbackstage.com.br, mas nas principais plataformas de podcast já está disponível.

Escute esse podcast pelo Spotfy clicando aqui!