Mesa de Produto #105 - Design feito por humanos vs. Design feito por IA

Falando com algumas lideranças de outras áreas, é que a gente conseguia ver essa dificuldade, de fato, de entender, como você disse, as nuances e tangibilizar aquilo em uma solução. Acho que essa transição e treinar esse tipo de pensamento é que, no final das contas, acaba sendo o mais importante. Obviamente, o ferramental é extremamente importante e ele capacita, ele habilita, na verdade, ele é habilitador. Mas a mudança de mentalidade de enxergar aquilo dali como um produto, né, uma solução no final das contas, é que eu vejo sendo a virada de chave assim.

Olá, seja muito bem-vindo, muito bem-vinda a mais um episódio do Mesa de Produto. Hoje vamos fazer um episódio remoto porque a gente vai falar com um convidado especial que está em Pernambuco e ele é o Murilo Ventura. Ele é Head de Produto da Beyond Company. Murilo, seja muito bem-vindo ao Mesa de Produto.

Muito obrigado, Farina. Muito feliz de estar com vocês aqui. Espero contribuir aí para esse debate.

Maravilha! E hoje a gente vai falar um pouco sobre design, um pouco sobre produto, Principalmente por causa do background do Murilo, né, Murilo? Conta para a gente, você veio de design? Qual que é a sua formação? Como é que você veio parar em produto?

Pois é, Farinó, acho que não tem como diferenciar muito a minha carreira, apesar de ter tido ali uma, entre aspas, migração em um determinado momento, né? Mas desde o ensino médio, fiz um ensino médio integrado com técnico em informática, eu já comecei em um laboratório de pesquisa lá dentro mesmo do Instituto Federal. Não, Instituto Federal de Alagoas que eu fiz, no caso, já tinha ali algumas atuações voltadas para design de aplicativos.

Isso mais de 10 anos atrás. E foi uma experiência bem legal. A gente fez um aplicativo, só assim a título de curiosidade, a gente fez um aplicativo para automatizar o refeitório na época, né, o refeitório que os alunos comiam. E aí eu fiquei muito nessa parte de design. Nas experiências posteriores, a gente, eu acabei também trabalhando muito com design, até que alguns anos atrás eu decidi que valia a pena fazer essa migração para a área de produto, gestão de produto mesmo.

E aí passei por laboratório de pesquisa, depois startups, e hoje tô como head de produto de fato.

Bem legal. Eu conheço bastante produtor que veio de design, assim, acho que depois de as 3 principais ali, né, o código, design ou marketing são geralmente as 3 fontes mais comuns de produto. É legal porque isso acaba te dando uma visão super aprofundada tanto de produto quanto de design e o quanto dessas duas áreas estão juntas. E nessa era de IA que a gente tá vivendo aí, de IA generativa, já tem seus 3, 4 anos, mas IA fazendo código um ano, um ano e meio, muita coisa mudou, né, Murilo?

Tanto de produto quanto de design. Por exemplo, muitos produteiros hoje acreditam que não precisam de um designer porque vai lá no Cloud Code, pede um protótipo e vem um protótipo, né? Se ele é bom ou não depende do prompt, depende de muita coisa. Mas enfim, vem um protótipo lá e aí fica aquela impressão tanto do produteiro às vezes até quanto da pessoa de engenharia também de que não precisa de designer. O que que você tem visto?

Qual que é a grande diferença? Ou mais ainda, né, o que que o designer ainda traz para mesa agora que interface, né, virou— eu vou até dar um pouco de opinião aqui antes, não da tua resposta, mas assim, a gente fala muito assim, ah, o que que o dev traz para mesa agora que o código é feito pela IA? Acho que é o paralelo da mesma pergunta, né? O que que o designer ainda traz para mesa agora que um protótipo, uma interface de usuário pode ser feita pela IA?

Legal. Não, esse é um debate que ele é contínuo, né? Eu sinto que lá no meu time a gente meio que já entendeu que o designer ele tem um papel extremamente importante. A gente tá falando de carreiras de especialistas, né? A gente fala ainda dentro de produto, você especialista em alguma coisa assim, o designer, né, o product designer vai ser mais especialista em alguma coisa. Pender ali para pesquisa, ou então pender ali para interface.

Até mesmo anteriormente estava muito aquecida a área de design systems, né? Sendo que a gente esquece que a própria área já é uma especialidade por si só, né? A disciplina de design de produto em específico assim já é uma super especialidade. Se a gente for subindo os níveis, né, os níveis, trazendo ali para cada vez uma camada mais macro, a gente percebe que para chegar em design de produto eu tenho que descer várias tomadas.

Isso já é por si só uma análise interessante, porque se a gente diz que a gente não precisa, partindo do pressuposto contrário, tá? Se a gente parte do pressuposto que não precisa de design, a gente tá querendo dizer que quem vai absorver o que essa disciplina faria é um super generalista. Então a gente não tem como esperar desse super generalista um refino na qualidade dos artefatos ali gerados. E eu não tô falando só de interface, né, falo desde a pesquisa feita, independente se é uma pesquisa feita com Claude, com ChatGPT, enfim, independente daí é que vai utilizar.

O olhar do designer, o olhar humano do designer, ainda é muito importante. Só que aí tem um ponto importante que é Eu não acredito mais no designer tendo a exata mesma atuação dele que ele já, que ele teve nos últimos anos, né? Já ocorreu uma certa transformação com o passar do tempo, né? Sobretudo nessa questão das próprias especialidades. Então a gente ter ali, se a gente for pensar no Double Diamond, né, em que um primeiro, um primeiro diamante ali do fluxo de design vai estar muito voltado para definição do que vai ser construído e a segunda para construção de fato, a gente começa a achatar muito isso, né, fazer isso de uma forma muito mais rápida pelo próprio designer, por causa da eficiência operacional que as ferramentas estão dando para gente hoje, né.

E se a gente for olhar para código também é um pouco parecido. A diferença do designer é que existe muito mais contato com outras pessoas durante o processo que exige que alguém intermedie isso, né, que tenham os pontos de contato, eles sejam muito mais de uma análise humana, né. Obviamente essa análise ela acaba sendo muito mais rápida, e aí é o ponto da eficiência operacional, né, que eu toco mais uma vez, por causa dessas ferramentas.

Mas a tomada de decisão muitas vezes ainda permanece no próprio designer, inclusive Aí a gente, se a gente for parar de área por área, né, desde pesquisa tem as suas limitações com o uso da inteligência artificial, até a própria interface, que a gente vê onde realmente hoje tá sendo mais, o impacto tá sendo maior, né, mais direto, digamos assim, não necessariamente maior, mas muito mais direto. E aí tem vários impactos negativos também, né, a gente vê produtos com a mesma cara, enfim, pontos nesse sentido também.

Pois é, eu, minha opinião assim, a gente erroneamente direcionou tantas vezes o designer para tela, né, e a disciplina design falando não, a gente não faz só tela, e as empresas, executivos, muitas vezes falando faz uma tela, faz uma interface, que agora gerou esse problema, porque a interface é a primeira coisa que a IA conseguiu fazer mais barato, vamos dizer, não vou nem equipar a qualidade, porque acho que não equipara, mas é a primeira coisa que a IA conseguiu fazer mais barato.

Mas ainda existe, como você falou, né, toda a parte de UX, toda a parte de arquitetura da informação, toda a parte de pesquisa, né. E por mais que a gente tenha usuários sintéticos, por exemplo, né, tem várias empresas usando ali usuários sintéticos com IA, e aí você entrevista a IA como se fosse um usuário. Como é que você monta um usuário sintético? Você monta com pesquisa feita por humano, certo, com atas e registros de pesquisas feitas por humanos.

E tem uma coisa que eu acho que é super importante assim, que Tem insights que a gente pega quando tá entrevistando cliente, seja pelo não verbal, seja pela escolha de palavras, seja pela entonação da voz, que aí ainda tá muito longe de ser capaz de pegar, né? E às vezes são insights que podem render ali, fala, pô, na hora que a gente fez aquela pergunta, repara que a pessoa demorou uns segundinhos, pareceu incomodada com a pergunta, parecia que tinha alguma coisa ali.

Você vai e faz uma outra pergunta porque você percebeu algo. Você percebeu que tinha uma história ali que não tava sendo contada? Esse tipo de coisa na pesquisa a IA não consegue, né, pegar, não consegue pegar essas nuances. Mas por outro lado, esse tipo de coisa vem de designers muito experientes. E aí já conecta com a minha próxima pergunta que eu queria te fazer: qual que é o lugar hoje do designer júnior, né? E até vou fazer duas perguntas em uma: qual que é o lugar do designer júnior e do PM júnior também?

Né, porque muitas vezes o PM júnior tá fazendo coisas ali que são priorizações, gestão de backlog, que aí consegue automatizar. O caminho para virar, para migrar para carreira, para ser júnior, para começar, tá mais difícil ou tá diferente? Tá mais fácil? Qual que é a tua opinião?

Eu vejo que hoje ainda, e aí compartilhando não só do nicho específico que eu atuo, né, a gente, eu trabalho numa startup especificamente, no produto que eu trabalho é um produto para o jurídico, Mas de outras empresas também com as quais eu conversei, eu acho que o mercado ainda não entendeu muito bem onde encaixar o Júnior e como fazer com que ele agregue cada vez mais valor, né? E aí fica uma zona cinzenta de a diretoria, né, em algumas situações quer muito uso da inteligência artificial porque vê o potencial de ganhar eficiência operacional, e que é um fato, Sendo que o júnior muitas vezes ele é vinculado, né, ele é relacionado o seu ganho de valor a esse tipo de ganho de eficiência operacional.

Então você tem um profissional um pouco mais sênior, delega ali algumas atividades para esse júnior que vão fazer com que esse sênior no final das contas ganhe um pouco de eficiência operacional. Então no caso do design, a parte de recrutamento, a gente vai fazer uma, vai rodar uma sessão de pesquisa, a gente precisa ali contatar alguns dos nossos clientes e delega para o júnior fazer esse contato, né, marcar as sessões, sendo que isso hoje é muito mais facilitado com algumas ferramentas.

Então eu vejo que ainda não foi encontrado, né, ou pelo menos não tem sido disseminado epidemicamente, digamos assim, né, um consenso do papel do júnior. Mas eu já vejo que um dos principais papéis do júnior hoje É, na verdade, a gente trabalhar dentro do time para que o júnior consiga de fato analisar muito bem coisas que a IA consegue fazer. E obviamente existe um olhar que deve ser muito treinado, mas se a gente não consegue também fazer com que esse júnior tenha esse olhar treinado, né, vá aos poucos conseguindo adaptar e ter um olhar mais crítico ver o que, o que a IA consegue fazer, fica mais difícil de ter esse ganho de valor do profissional júnior.

Um outro ponto também é: a gente consegue partir de um ponto A para um ponto B muito mais rápido com as ferramentas, né, que a gente tem hoje disponíveis, ou até com ferramentas próprias. Não necessariamente o ponto B já vai ser um ponto B de produção, um ponto B para usuário final, né? E muitas vezes o que a gente passa para um júnior não necessariamente já vai chegar nesse ponto final de ir para um usuário, ir para produção.

E a capacidade de um júnior iterar hoje, ela tá muito mais alta. A capacidade de qualquer profissional iterar sobre uma solução tá muito mais alta. Então eu vejo também que o júnior é a pessoa que vai ajudar nessas interações, nessas iterações. Então a gente tem uma nova funcionalidade para rodar, a gente já tem uma ideia bem definida, já tem um público bem definido, uma proposta de solução não tão bem definida e agora a gente precisa começar a materializá-la.

Então o júnior consegue fazer esse tipo de— eu vejo, na verdade, né, isso aqui é uma opinião, acho que não é uma prática tão disseminada ainda, mas eu vejo que o júnior ele consegue fazer esse tipo de interação com um custo muito menor, sobretudo de tempo, do que o que a gente tinha anteriormente. Se a gente delegava para um designer júnior antes fazer uma determinada alteração em uma proposta que vai ser passada ainda para o time de desenvolvimento, ou até uma POC que tá sendo feita, eu iria esperar semanas.

Hoje eu espero alguns dias e eu já consigo ter esse resultado. Então a gente consegue treinar também muito mais rápido esse olhar, né? Eu vejo que é a capacidade de a gente ter uma possibilidade agora de errar muito mais rápido. E a gente sabe que para aprender a gente precisa errar muito. Então a capacidade de um júnior aprender eu vejo que também foi potencializada, o que é bem bacana, que é muito legal. Assim, a gente consegue formar pessoas um pouco mais rápido também.

Obviamente tem coisas que o tempo, só o tempo vai formar, né, as experiências ali com os clientes, botando o produto em produção, mas o processo de desenvolvimento e de design, ele mudou muito, né? O que ajuda bastante também nessa formação.

Com certeza. E você como, como head, né, como liderança, você muda um pouco o papel do líder também, né? Não só da expectativa que você vai ter do júnior, mas de como que você vai capacitar esse júnior. Você sente isso? Já sentiu isso na prática assim de 2, 3 anos para cá, o teu papel como líder mudando?

Totalmente assim. Existe, é engraçado porque eu falei inicialmente desse processo de design mudando, e especificamente lá na configuração do time que eu tô tocando hoje, a área de design tá dentro da minha alçada, né, área de design de produto. Então eu olho tanto para produto quanto para design de produto de fato, e eu vejo que essa função de design de produto tá se aproximando muito de produto como a gente entende, da disciplina de produto como um todo, de gestão de produto, né?

E isso mudou a essência do que eu cobro. Então ter um design muito mais estratégico virou muito mais importante do que ter um design essencialmente prático, focado nos artefatos que vão ser entregues para outro time, né? Então falando ali com a minha liderança de design de produto Que acaba sendo um braço direito muito importante para a área de produto, de fato, né? Já era anteriormente, eu vejo que agora tá sendo ainda mais pela velocidade com que as coisas conseguem gerar resultado.

Então, trazendo um pouquinho ali para nossa, para nossa, para o nosso contexto, tá? A gente tem um time de design de produto, todo o time é bem enxuto, e o time de design de produto em específico é um time bem sênior. E a gente consegue fazer com que eles, devido à capacidade deles também e a toda a arquitetura que a gente colocou, eles conseguem fazer diversas modificações que vão para produção diretamente, né? Então passa ali por um aval rápido do time de desenvolvimento, mas no geral, e é um time de design todo feminino inclusive, as designers lá do time elas trabalham diretamente com a aplicação em produção, obviamente com os devidos ambientes, né, para a gente ter um controle, governança.

Mas a gente deu muito mais poder mesmo. Exatamente. Mas é exatamente isso. Legal. E é impressionante, Farina, o quanto a gente conseguiu aproximar a aplicação dos usuários. Que que eu quero dizer? Muitas vezes a gente tinha um fluxo ali de que o usuário reclamava alguma coisa para o time de CS, para o time de suporte, Essa reclamação, essa melhoria, né, ela chegava para o time de produto, para o time de produto priorizar. O time de produto priorizava e jogava muitas dessas coisas que tinham impacto em interface ou em fluxo de usuário, então iam direto para o time de design.

O time de design passava um tempo ali desenhando, estudando, entendendo, concretizando para passar para desenvolvimento, para quando o desenvolvimento tivesse um tempo colocar em produção, né, fechar ali o ciclo e colocar em produção.

E às vezes esse tempo nunca chegava.

E às vezes esse tempo nunca chegava. Hoje ainda existem melhorias, obviamente, que ficam mais tempo do que o que a gente gostaria devido ao próprio capacity do time, né. Mas a quantidade de coisas que a gente consegue colocar para rodar sem precisar passar e onerar o time de desenvolvimento, que a gente sabe que geralmente é o capacity que é mais onerado, né, devido sustentação, as próprias melhorias mais robustas que envolvem uma mudança de arquitetura.

Então outras melhorias menores, ah, eu queria que pudesse filtrar nessa tela por um determinado outro campo. Beleza, isso aí eu vou precisar parar parte da sprint para que o meu desenvolvedor faça. Ou até mesmo, ah, seria muito legal que nesse fluxo aqui, ao invés das ações A e B, eu conseguisse fazer também a ação C. E a gente vê que é uma ação totalmente de fluxo de usuário ali, não vai tocar a mudança de banco de dados, né, a forma como foi arquitetado o sistema.

Então por que não potencializar ali a ação dos product designers, né? E aí a gente fez um, se a gente fosse olhar, uma, não é linear, né, mas vamos colocar aqui como linear, uma esteira em que de um lado tem produto no meio tem design, no final tem desenvolvimento. Eu sinto que design ele começou a se esticar um pouquinho para os dois lados, tanto ele tá atuando um pouco mais em desenvolvimento quanto também tá atuando um pouco mais em produto, porque a parte do meio, que é o concretizar a eficiência operacional, o ganho de eficiência operacional foi tão grande que possibilitou que esse tempo ganho, né, esses recursos que foram ganhos, né, que foram obtidos ali conseguissem ser distribuídos para outras atividades.

E aí, no meu caso, eu tento sempre estimular o time de design de produto para esses dois pontos. Um, que é a parte de atuar em realmente coisas de produção que vão afetar a satisfação do cliente, e outra que é a estratégia, né, o quanto o time de design consegue ser mais estratégico, né. Então, seja em coisas que já estão em produção analisando, em contato direto com o nosso Product Manager, o nosso time de produto como um todo, quanto no olhar para o mercado. Então percebe como as coisas começam a se misturar com produto, né?

Maravilhoso. Você falou que você vê o designer se esticando. Você vê as outras funções também, produto, engenharia, se esticando mais, ou foi mais o designer que tava no meio que começou a abrir os braços assim?

Então eu sinto assim, pode ser que eu seja um pouco enviesado por todo o meu background em design, e eu vejo o potencial, né, que pode ter ali.

Tá liberado ser enviesado, é um podcast, é uma entrevista individual, tá super liberado.

E aí eu tendo esse viés, eu acho que eu consigo apertar um pouco mais do time de design de produto em específico, né, para que ele consiga ter essas outras atuações mais transversais. É uma atuação até que a gente consegue ver o Product Designer como um builder também, tá? Então ele não se restringe só a ser a parte de conceito, a parte de pesquisa, enfim, o protótipo ali como Figma. No final das contas, não. Eu quero que ele, que no final das contas a experiência do usuário seja afetada, né?

Na verdade, não é nem a experiência do usuário seja afetada, é que os cenários para que uma ótima experiência do usuário sejam os melhores possíveis. E isso daí é responsabilidade do meu time de design de produto. Então, se eles não estão conseguindo entregar por ônus do time de desenvolvimento, no sentido de a gente tem um capacity que não aguenta toda demanda que o time de design de produto precisa, o que a aplicação, o produto precisa de fato, então por que não capacitar o time de design de produto para superar esse ônus, né?

E aí o time de desenvolvimento vai estar focado no que realmente só o time de desenvolvimento conseguiria atacar. E eu vejo que isso é um ponto muito importante nos times de desenvolvimento. Eu não vou conseguir falar por todos os times de desenvolvimento, mas pensando em equipes enxutas, que é o nosso caso, eu vejo que existe uma parte muito importante relacionada à governança. Então, tudo que o time de design de produtos faz precisa ter um olhar um pouco mais cauteloso do que um que o desenvolvedor sênior que trabalha há 12 anos com desenvolvimento vai fazer.

Então algumas decisões que a gente delega para IA, que podem conter algum risco ali naquela decisão especificamente, elas precisam ter um olhar mais crítico do lado do time de desenvolvimento. Então a parte de governança acaba sendo absorvida de uma forma ainda mais forte pelo time técnico, né? Time técnico, quando eu falo, é time de desenvolvimento em específico. O que antes, como tava tudo sempre ali dentro, né, do próprio time, acabava sendo de uma outra maneira.

Então existem outros artifícios que precisam ser adaptados, né, para que o time de desenvolvimento consiga de fato exercer essa essa governança. Já para parte de produto, eu vejo que o produto cada vez mais se aproxima de estratégia, né? Acho que muito mais também de design, tá? Também acaba se aproximando de design, também até mesmo do próprio, do próprio, da parte de desenvolvimento, né? O nosso time de produto também coloca algumas coisas em produção, não necessariamente muito voltadas para novas para novas funcionalidades.

Geralmente isso vai mais para o time de design de produto e para o time de desenvolvimento diretamente. Mas quando tem uma coisa ou outra que o próprio time de produto identificou que poderia ser ajustado, né, e isso é um bônus muito grande de ter uma equipe enxuta, tá. Então, como a gente consegue ter uma comunicação muito mais rápida, a gente tem uma noção também do produto muito mais generalizada assim, todo mundo tem uma uma ideia muito forte de todas as funcionalidades.

E quando não tem, quando tem algo ali que precisa de uma, de um segundo olhar, é repassado para essa pessoa naturalmente. Mas em determinados pontos a gente consegue cortar caminhos. E aí eu vejo que o time de produto puxa algumas coisas de desenvolvimento, mas o ganho principal no final das contas é com estratégia. Como é que a gente entende melhor o que priorizar, o que testar Com essas ferramentas, o teste virou um outro nível, assim, né?

A gente consegue testar muito mais coisas, né, fazer muito mais explorações do que a gente faria anteriormente. Então a gente até rodou agora, nesse primeiro semestre, a gente parou um certo momento e disse, olha, a gente tá vendo que as coisas estão caminhando tão rápido, a gente tá conseguindo fazer as coisas de uma certa velocidade, assim. E aí perceba que eu tô trazendo aqui sempre eficiência operacional, né, como foco. A gente tá conseguindo andar em um ritmo tão saudável, né, no geral, que faz sentido a gente fazer um teste de um novo produto aqui.

Então vamos parar um momento aqui para fazer esse teste de um novo produto e ver quais são os resultados que a gente tem. E que se a gente fosse fazer esse mesmo teste em outro momento, né, um ano e meio atrás, 2 anos atrás, A gente parou parte do time ali por cerca de um mês. Se a gente tivesse feito isso antes, a gente teria que parar por uns 4 meses, alguma coisa do gênero, para obter os mesmos resultados, né? Então, e para você ter ideia, só tinha um desenvolvedor nesse time, né?

O restante eram 3 outras pessoas de produto e design. Então, e a gente teve uma aplicação bem robusta assim, né? Obviamente era uma POC, né? Então várias coisas ali a gente abriu mão, mas é algo que o próprio time de produto ficou muito voltado para estratégia, para entender ali um novo caminho que o produto poderia tomar. Enfim, então eu vejo que sim, resumindo, né, a resposta, eu vejo que sim, houve uma dilatação de todos os lados aí, né.

Desenvolvimento, eu vejo que teve menos a dilatação, mas muito por essa questão da governança. Já design e a parte de produto, eles conseguiram pegar um pouquinho dos dois lados, né? Muito voltado para estratégia, sobretudo.

Eu acho que isso acende até uma conversa, né, um ponto super individual, tá, desses profissionais, que é do que que você gosta de fazer, né? Porque para algumas pessoas, eu já conversei com desenvolvedores, por exemplo, falava, cara, eu gostava de escrever código, assim, era uma das partes que eu mais gostava do meu trabalho, e aí atirou isso de mim. Então aí eu lembro esse desenvolvedor, ele falou, meu trabalho tá menos divertido agora.

E eu conversei com várias pessoas de produto e falaram, meu trabalho tá mais divertido agora, porque antes tinha um monte de coisa que eu não conseguia fazer e agora tem coisas que eu consigo fazer. Designer, a mesma coisa. Conversei com designers, falaram, ah, meu trabalho tá mais chato, tão me cobrando um monte de coisa que eu não gosto, que não faz muito sentido. Conversei com designers que estão por outro lado, cara, é o novo mundo, que maravilhoso!

Isso muda um pouco o perfil né, do profissional. Assim, a gente, eu sempre digo que autoconhecimento nunca é demais, né? Quanto mais a gente se conhece, mais a gente melhora, é o nosso trabalho, né? E melhora a nossa atuação. Acho que esse nível de autoconhecimento agora acaba trazendo para gente também essa noção de assim, pouquinho, ao trabalhar com produto, com design, com engenharia em 2019, não é a mesma coisa que trabalhar hoje.

E talvez o que atraía muitas pessoas para essa área em 2019 Hoje talvez essas pessoas vão olhar essas carreiras e falar, cara, não é exatamente a carreira que eu quero, né? Só um episódio engraçado, né? Eu trabalhei com um tech lead, ele era muito bom, mas ele falava assim, ah, se eu quisesse falar com gente, eu não tinha virado desenvolvedor, né? É uma brincadeira, lógico, ele falava com as pessoas normalmente, mas ele usava muito essa brincadeira.

E hoje já é quase inconcebível um desenvolvedor não ter um lado pessoal aflorado de empatia com cliente e que venha de conversas com o cliente muitas vezes, né? Você botar o desenvolvedor na reunião para falar, isso muda um pouco o papel, né? Acho que foi, foi não só o papel, mas vamos dizer assim, muda um pouco a pessoa que você precisa ser, ou as características, às vezes até habilidades, soft skills, né, que você precisa ter para gostar do trabalho.

Né, na tua opinião, o teu trabalho, tanto como head, como produto, como designer, ele tá mais legal, ele tá mais chato, ele tá diferente? O que que você tá vendo assim dessa? Mudou o perfil para ti também? Você tem essa visão?

Ou então talvez você esteja enviesado? Mudou bastante. Só deu uma travada, eu vou só recomeçar aqui, mas vamos lá. Então, Farina, eu acho que mudou bastante, tá? Mudou significativamente, mas no meu ponto de vista, é uma opinião totalmente pessoal, mudou para bem melhor. Eu vejo que a gente tem agora uma capacidade de se mover muito mais rápido, o que acaba deixando o trabalho menos monótono. Mas aí foi engraçado porque teve essa própria POC que a gente fez, né, que ali durou um mês, foi um experimento que a gente precisava se mover rápido.

E aí eu parei eu mesmo para desenhar algumas coisas e eu abri o Figma, né, fiz algumas, algumas interações ali, fiz algumas interações no próprio Lovable, algumas no Cloud Design, né, pensando em conceito mesmo, né, de fluxo de usuário, etc. E eu pensei, poxa, senti um pouquinho de falta de pegar um componente, de arrastar ali alguma coisa para tela do Figma e tal. Mas essa falta passou rápido a partir do momento em que eu vi que o protótipo já tinha tomado forma, né, de que eu já tava vendo a coisa funcionar ali, né.

Então, obviamente, quando as coisas mudam, não muda só o que a gente não gosta, mas o que a gente gosta acaba também sendo modificado. E eu percebo que no final das contas o saldo para mim foi bem positivo. Na velocidade que as coisas andam deixou o trabalho todo muito mais dinâmico. É o que para mim ajudou bastante, né? A gente consegue ver o resultado muito mais rápido, mas também algumas das coisas que eu gostava de fazer, além de curtir o processo de pensar em alguma coisa especificamente e tal, a gente perdeu, né?

O que em certos momentos é chato, mas no geral o saldo ainda é muito positivo. Eu tenho curtido bastante essa nova forma de trabalhar, né? Obviamente muitas das coisas agora na área de produto, muito do que eu faço continua sendo uma área de facilitação, de conversar com pessoas, de conversar com as outras áreas, de conversar com cliente, entender ali o contexto que a gente tá inserido, especificamente como head, conversar com os stakeholders do próprio negócio, né?

Então isso daí não acaba não mudando tanto o processo, né? Muda muito mais a velocidade com que a gente consegue fazer análises, como que a gente consegue colocar novas ideias para jogo, né? Enfim, então no geral só dá bem positivo. Eu vejo isso como bem positivo, apesar da essência de fato não ter mudado tanto, sabe?

Pois é, eu tô achando mais divertido também o trabalho, mesmo hoje como CEO aqui da PM3. Eu boto a mão na massa, né? A gente Na PM3, cada um é o seu próprio Product Manager, o seu próprio designer, o seu próprio desenvolvedor. Claro que a gente tem especialistas aqui dentro também, mas muita coisa é feita sem passar por esses especialistas. E o que que eu tenho percebido assim das coisas que a gente tá fazendo aqui dentro, queria a tua opinião também a respeito disso.

Antes da IA, a gente deixava muita ideia ruim, ideia boa, desculpa, muita ideia boa sem fazer. Né, então tinha aquela impressão de que a gente tava deixando de fazer muita coisa legal e muita coisa promissora, vários testes que poderiam ser legais. E agora com a IA a gente consegue fazer. Eu tenho visto algumas pessoas falando assim, ah não, com a IA vai ter menos trabalho para o ser humano. Na verdade, já sobrava tanta coisa para a gente fazer que não dava tempo, que agora a gente consegue fazer mais coisa.

E aí eu tenho, né, tem saído alguns reports ali da galera Tem uma galera se sentindo pressionada. Agora com a IA, meu chefe espera que eu trabalhe 10 vezes mais, entregue 10 vezes mais. E tem outras pessoas falando, agora com a IA eu consigo testar mais, experimentar mais. E assim, ainda a taxa de sucesso dos experimentos ainda não necessariamente aumentou, mas o volume de sucesso aumentou porque o volume de experimentação aumentou também.

E eu tenho essa impressão, todo time que eu tive como PM, depois como head ali, os times que respondiam para mim, tinha um backlog muito maior do que a sua capacidade. Todos, né? Você fala assim, ah, vinha uma coisa ali de CX, uma experiência, queria um filtro, queria uma coisinha aqui. É aquele tipo de coisa que se você não construía na V1, você não voltava depois lá para mudar, porque você já tava fazendo outras coisas e não valia a pena voltar.

E agora a gente consegue mudar. Ganha o usuário, porque o usuário agora tem as suas demandas mais atendidas. Ganha o o profissional que sente que tá impactando mais, tá gerando mais resultado. E a gente sempre fala aqui na PM3 que quem impacta é promovido, quem dá resultado se destaca. E ganha a empresa, que muitas vezes descobre novas linhas de receita ou melhorias de ativação, melhorias de retenção, que mais ideias estão sendo testadas.

Tanto que a gente tem visto aqui na PM3, a gente monitora isso, a gente tem visto mais vagas de produto sendo abertas, né, e não vagas sendo fechadas. Como é que é isso? Como é que tem sido isso para tua experiência? Qual que é a tua visão assim? Tem mais trabalho para fazer? Estamos fazendo mais? Estamos fazendo menos? Você falou que vocês têm um time enxuto aí também, né? O que que mudou? Você falou, ah, testamos um negócio em um mês, ia demorar 4 meses, talvez você nem testasse, né?

Em 4 meses você fala, 4 meses não vale a pena. Isso exige— eu vou até reformular assim, porque acho que eu acabei dando minha opinião demais aqui. Isso exige de ti uma atuação diferente com os executivos, por exemplo? Como que tá essa gestão de expectativa dos executivos? É vamos testar mais, vamos arriscar mais, ou vamos economizar, vamos ser enxuto, vamos usar IA para reduzir, para gerar eficiência?

Não, isso é bem interessante. Esse é um discurso que eu tenho tanto dentro da empresa ali com os meus pares, e especificamente na empresa que eu trabalho, na Beyond, A gente não tem um produto só, então a gente tem alguns heads de produto para cada produto desses, né? E conversando ali com alguns pares, a gente também tentando entender como é que a gente concilia esse relacionamento com os stakeholders. No nosso caso, no contexto que a gente tá, a gente tem uma facilidade, né, assim, até um certo ponto, de que os executivos ali, a diretoria que a gente correlaciona, eles têm um background técnico muito forte.

Então eles conseguem entender até onde ir, né, até onde dá para a gente pressionar e empurrar um pouco os times, né, pressionar assim também no bom sentido os times de que, ó, a gente precisa fazer uma modificação aqui na forma de desenvolvimento. A gente já fez alguns testes aqui com alguns times específicos e dá para a gente ir nesse caminho, né, a gente pegar alguns direcionamentos técnicos muitas, muitas vezes são bem interessantes.

Inclusive, e aí eu adiciono um caso, né? Em agosto, ali agosto para setembro do ano passado, isso vai fazer um ano então que a gente fez essa mudança de mentalidade, né? A gente tomou uma decisão de refazer completamente a plataforma e colocou uma deadline de refazê-la em um mês. Na verdade, um pouco mais de um mês, foram 43 dias que a gente levou para refazer a plataforma. Justamente, e aí contextualizando um pouco, né, nesse relacionamento com os stakeholders, eles começaram a despontar: pessoal, a gente tá fazendo uns experimentos aqui, a gente tá conversando com esse time aqui, e a gente tem visto resultados muito bons nessa nova forma de desenvolvimento.

E o pessoal do meu time, a gente disse, bora fazer, vamos pegar essas 2 semanas aqui e vamos fazer um outro experimento. Aí eu peguei, sei lá, 20% do capacity do time, 15% do capacity do time, e a gente começou a fazer experimento. Viu que o experimento tava dando mais certo do que o que a gente esperava, e a gente disse, beleza, então agora vamos conversar com os stakeholders ali. A gente viu da possibilidade, viu que os resultados são positivos, Vamos propor de fazer, de refazer a plataforma por inteiro.

Obviamente, refazer a plataforma por inteiro não era, não era porque a gente queria. Existiam diversos motivos, né, diversas funcionalidades que a gente sabia que precisavam ser refatoradas, o alto índice de chamados que a gente tava recebendo para determinados fluxos, e que a gente conseguiria corrigir nesse processo de refatoração, né, um processo de replatforming que a gente acabou fazendo no final das contas. E o time comprou muito a ideia, né?

E aí foi um super case de como manter o time junto, né? Que não é fácil você fazer uma mudança completa de cultura de desenvolvimento, né? O time de design de produto vai deixar de olhar diretamente para o Figma para olhar diretamente para uma ferramenta de desenvolvimento, um próprio Lovable, um Replit da vida, para conseguir prototipar mais rápido e dar vazão a esse processo de replatforming que a gente queria fazer em 40 dias.

Então o time de, na verdade, os executivos, eles já estavam super comprados naturalmente, né? Foi uma provocação que veio ali da área deles. E aí foi o processo ali para fazer com o time de desenvolvimento e o time de design e o próprio time de produto de que a gente conseguiria fazer aquilo naquele tempo e que teria muito ganho, né? Então foram conversando ali com as lideranças, depois conversando com cada com cada membro do time até que a gente conseguiu fazer e foi super legal, né?

Como eles que sofriam muitas das vezes para tratar dos bugs ou das melhorias que chegavam e passavam semanas na fila, acabou sendo mais fácil esse processo de convencimento. Agora, um ponto depois era, beleza, a gente fez uma super sprint, digamos assim, né, um processo de replatforming mais rápido, mas a gente também precisa ter responsabilidade de que a gente tá colocando em produção na mão dos usuários finais algo com excelência, né, uma qualidade boa o suficiente que não vá prejudicar os resultados de negócio.

Então a gente meio que mal acostumou, assim, a gente mal acostuma, né, os executivos quando a gente faz uma iniciativa disso. Mas ao mesmo tempo é entender, ó, a gente tem um potencial, só que a gente precisa de um alinhamento muito claro daqui para frente do que que vai ser trabalhado, em quanto tempo vai ser entregue. Então eu vejo que existem os dois lados, um dos executivos apoiarem e pressionarem, que faz parte para roda continuar, continuar a ter momento, ao mesmo tempo que do nosso lado, sobretudo ali das cadeiras de gestão de produto, ter um planejamento muito bem alinhado, diretrizes muito bem definidas de quais são os eixos estratégicos que vão ser atuados naquele período de tempo, seja o quarter, seja o semestre, com as iniciativas que vão estar dentro de cada eixo estratégico desse, né, qual é a visão de produto naturalmente que vai estar sendo perseguida, para que aí não exista uma divergência entre o que os executivos, a diretoria espera do que o time tá atuando no dia a dia.

E aí acaba que, e fazendo o último gancho ali para o que você, para o que você trouxe na na tua fala, acaba que esses testes que a gente consegue incluir, que muitas vezes nem estavam presentes nesse planejamento que a gente colocou com os executivos, a gente consegue fazer algumas entregas a mais, né? Obviamente, o primeiro planejamento que a gente fez desse novo paradigma, ele não foi tão certinho, né? Tiveram várias coisas que a gente julgou mal a estimativa, porque a gente não tinha noção ainda.

Antes a gente demorava 3 semanas para fazer uma funcionalidade, agora em 5 dias a gente tava fechando. Então acabou que a gente não tem muito a mesma régua, mas no final das contas é alinhamento, ter as coisas muito claras, né, com os executivos, para que nem tudo seja toque de caixa, mas também não seja esperado que a gente permaneça naquela morosidade. Eu vou usar essa palavra, mas obviamente era era no processo tradicional, digamos assim, né?

Pois é, eu até escrevi sobre isso esses dias, porque assim, antes da IA escrever código com a qualidade que ela escreve hoje, a gente era mais fácil você chegar para o executivo e falar, olha, isso aqui vai demorar 4 meses, não tem, não tem, não tem conversa assim, né? E dificilmente o executivo, a menos que fosse um CTO, né, mas dificilmente o executivo sabia de código o suficiente Então ficava aquela coisa que tinha que ser na base da confiança, né?

O executivo pensava, ou estão me enrolando, ou realmente leva 4 meses, 6 meses. Tinha que ser na base da confiança. Falou, bom, eu confio na minha liderança intermediária, eu confio no meu time, vai levar 4 a 6 meses mesmo. Agora parece que os executivos ganharam uma carta para trocar, né? Fala assim, não, mas vai levar 6 meses, né? E pô, para mim, para mim, o que tem resolvido muito isso é o executivo botar a mão na massa, cara.

Eu tenho esse incentivado, inclusive os executivos, quando eu converso com algum, algum C-level, principalmente de marketing, de vendas, de customer success, que não é de tech assim, né, tirando CTO, CPO, eu falo assim: constrói um negócio no cloud, constrói um negócio no Lovable, no Replit, vai lá usar, vai lá usar e ver como é que é, né, para você ter essa ideia. Porque acho que é a primeira vez que a gente tem algo dessa magnitude que impacta tanto o trabalho da operação a ponto do time executivo ter que entender daquilo.

Talvez a última vez que isso aconteceu tenha sido com o surgimento da internet, né? O executivo que naquela época não entendia como funcionava a internet não conseguia pedir as coisas, não conseguia criar um negócio, não conseguia nada disso. Agora, o executivo nunca precisou saber de código, tirando o CTO, nunca precisou saber de código, mas agora ele precisa entender de IA, né? Você tem No teu papel, claro, como head, imagino que você tá botando coisa em produção também, você tá metendo a mão na massa.

Você incentiva os seus executivos também a fazer isso? Tem executivo, você tem visto na empresa, por exemplo, ou em outras empresas, executivos botando a mão na massa? Ou ainda é um, ou ainda tô sendo idealista aqui de achar que isso tá acontecendo?

Então, Farina, eu acho que não tá sendo nem um pouco idealista, tá? No meu contexto em específico, os executivos estão totalmente imersos nessa nessa realidade, naturalmente, por eles terem esse background técnico, então existe uma predisposição ali deles estarem antenados, né? E nesse caso, como eles têm uma noção do quanto pode impactar positivamente o negócio, então eles costumam imergir ainda mais, né? Então isso é bem importante.

Mas eu vejo que para outras empresas, né, não só para outras empresas, mas também para outras áreas, né, áreas como pessoas, o próprio marketing, RH, assim, RH, pessoas, né. Mas enfim, com esses outros departamentos existe ainda uma transformação a ser feita. Então os executivos dessas áreas acabam tendo uma certa resistência um pouco maior, e muitas vezes não é nem só uma resistência, mas sim de mudança de mentalidade, né? Como é que eu penso em um problema em específico e na solução para ele, né?

Tecnológica, numa solução tecnológica. E como é que eu consigo transformar aquilo com as ferramentas que estão disponíveis? Então exige também uma mudança de cultura da própria empresa para empoderar essas outras áreas que não estão no dia a dia ali pensando em produto, pensando em soluções em específico tecnologicamente falando. Empoderá-las, treiná-las para que elas consigam fazer esse tipo de atuação. Para empresas em que os executivos não estão comprados devidamente em relação a isso, eu acho que não é tão difícil comprar, tá, dados os resultados que a gente consegue alcançar.

A gente consegue fazer alguns testes ali em relação a isso, mas fazer com que isso se torne rotina para eles, aí eu vejo que é um pouco mais mais difícil, né? Vai depender um pouquinho ali da personalidade, do contexto dos executivos. As lideranças próximas, então a gente que tá numa camada mais próxima desses stakeholders, a gente tem um papel muito importante, né, que é um papel político de facilitação ali para ocasionar essa mudança de cultura de baixo para cima quando necessário, ou às vezes de cima para baixo também, como foi no caso da gente, né.

Em que os executivos já estavam comprados e empurraram, né, assim, é legal, corresponsabilizaram, na verdade, corresponsabilizaram as outras lideranças, digamos assim, todas as lideranças intermediárias para essa mudança de cultura. Então, no final das contas, eu não vejo sendo idealista, mas enxergo que existem contextos que vão ter mais obstáculos, naturalmente.

Faz uma diferença enorme, cara. Esses dias, tem quase um mês na verdade já, tava conversando com uma pessoa que é executiva mais da área de vendas assim, né, de atendimento ao cliente, explicando como é que funcionava o GitHub, por exemplo, né, porque para eles é uma coisa muito distante. Só que repara que assim, essas pessoas estavam acostumadas a pedir demanda para PM, para design, para engenharia, e as pessoas que ouviam a demanda tinham muita capacidade de entender nuance, entender detalhe, tinham muito contexto da estratégia da organização.

Então a demanda vinha totalmente torta e a gente aqui, produto, design, engenharia, falava: tá, beleza, eu entendi, você explicou de um jeito torto, mas eu entendi o que você quer. Aí a IA não tem esse contexto todo, cara. Você vai explicar torto, vai sair torto.

Exatamente.

E no teu caso, pelo que eu entendi, os founders eram, são de engenharia já, já são técnicos.

Então, exato, eles têm esse background mais de engenharia. Facilita em vários aspectos. Falando com algumas lideranças, né, de outras áreas, é que a gente conseguia ver essa dificuldade de fato de entender, como você disse, as nuances e tangibilizar aquilo em uma solução, né? Acho que essa transição e treinar esse tipo de pensamento é que no final das contas acaba sendo mais importante. Obviamente o ferramental é extremamente importante e ele capacita, né, ele habilita, na verdade, ele é habilitador.

Mas a mudança de mentalidade de enxergar aquilo dali como um produto, né, uma solução no final das contas, é que eu vejo sendo a virada de chave assim.

Maravilha. E aí a gente já tá se encerrando aqui, encaminhando para o final. Queria te fazer uma última pergunta, voltar no tema aqui de produto e design, né. A gente falou bastante do que muda, a gente falou das diferenças ali entre um olhar humano e a IA fazendo. Mas vamos tentar fazer um exercício aqui de futuro, não o futuro para o Murilo, tá? Futuro, o que que o Murilo acha que acontece ali nos próximos anos? Como é que a gente se prepara para esse futuro?

A gente vê modelos cada vez mais rápidos, cada vez mais capazes, o Fable, vários outros modelos chineses agora tá mudando cada vez mais rápido. A gente falou aqui, ah, beleza, o trabalho do especialista ainda é humano. Pode ser que chegue num momento em que o trabalho especialista seja feito ali também, pode ser que não. Enfim, queria te deixar essa última pergunta assim para projeção. Vamos até centralizar em carreira assim. Como é que eu preparo minha carreira para ela ser à prova desse futuro, próximos 2, 3 anos assim?

Legal, acho que é a pergunta do ouro, a resposta de ouro na verdade. No final das contas, quem consegue responder e consegue se posicionar melhor do que boa parte das outras pessoas que estão no mercado, né? Eu acho que especificamente falando em design, tá, o Builder eu vejo como sendo uma posição em que o próprio designer vai ter um diferencial muito grande, né, quando ele consegue de fato pensar na parte de não só visual, mas todo o fluxo de usuário de uma forma em que ele consiga escalar isso muito mais rápido, né.

Obviamente o designer que vai ter o diferencial, se eu pego dois builders, o que vai diferenciar para mim um builder que se destaca de fato é aquele que consegue colocar o olho dele e não só o que a IA joga para ele, né, e aceitar o que a IA joga para ele. Então o olho, né, os gostos, a visão que ele consegue ter de mundo, né, de não só estética, mas de usabilidade, né, de intuitividade, enfim, de personalidade, e acima de tudo de identidade.

Então o builder que consegue transmitir a identidade do negócio naquele produto de fato tem um diferencial muito grande. Eu acho que para o futuro a gente tá falando muito, muito de volume, muito de eficiência, mas a eficácia é extremamente importante. E a gente sabe que para eficácia o refinamento também é importante. Então aquele builder que consegue ter esse refinamento, que consegue olhar no detalhe ali, ver conectar a marca à estratégia do negócio de fato, né?

Então é aquilo que eu falei ainda, de esticar um pouquinho a área de atuação, escopo de atuação do designer e da pessoa de produto, vai fazer com certeza com que a pessoa se destaque. Então um grande resumo assim desse futuro, né?

Algo muito, muito humano, né?

Assim, realmente Como é o quanto você consegue, exato, o quanto você consegue traduzir esses aspectos humanos em resultado no final das contas, né? E obviamente o meio do caminho é que agora foi encurtado devido às ferramentas que a gente tem. Então olhar muito para o humano é um fator extremamente importante, né? No caso do designer, o valor, né, que ele consegue, o gosto que ele consegue traduzir, digamos assim, né, que a gente vai construindo ao longo da nossa carreira extremamente importante para trazer esse diferencial também.

Perfeito, Murilo. Cara, muito obrigado pela tua participação, foi muito bom conversar contigo. Espero que você tenha gostado também. Enfim, vou deixar as últimas palavras para você se despedir aí da galera.

Valeu, Farina. Não, foi bem bacana o debate. Eu acho que é um tópico que tá sendo constantemente debatido, né, conversado nos nossos times ou até mesmo no mercado, e Tá tudo mudando tão rápido que pode ser que daqui a 3, 4 meses a gente já comece a ver que o futuro já mudou um pouquinho, né? Essa visão de futuro já mudou um pouquinho. Mas muito obrigado pelo papo, gostei bastante de participar. Valeu, Farina!

Valeu demais! E para você que assistiu até agora, não se esqueça de deixar o seu like ou suas 5 estrelinhas aí, se você assistiu no Spotify. Isso ajuda a gente não só a receber feedback do que que você gostaria de ver mais por aqui no Mesa de Produto, mas também ajuda esse conteúdo a chegar para mais gente e espalhar aí a palavra do produto e do design cada vez mais para as pessoas, que enfim, quanto mais elas souberem da nossa área, mais legal o nosso trabalho vai se tornar. Então muito obrigado, grande abraço e até a próxima!