Ep. 301 - Times de Produto com IA: PODs, aceleração de entregas e um novo jeito de fazer discovery

Então, qual que é a grande opção que a gente tem? E aí são testes, a gente também não tem nenhuma resposta pronta. Então antes eu tinha que discutir muito porque o meu desenvolvimento era caro. Agora que meu desenvolvimento é barato, eu vou desenvolver muita coisa e muitas dessas coisas nem vão pro ar. Então mais do que nunca agora é a orientação a essas métricas, é muito mais importante do que de fato falar, cara, o que eu vou fazer é isso. Porque a velocidade de entrega do que a Érica faz ali, do que os times de pod faz, é muito rápido. Mas AI enquanto ferramenta acelera muito as entregas. E se eu fizer pra testar? Deixa eu testar aqui. E aí, se não funcionar, a gente mata.

Hoje a gente está aqui para falar da conexão que existe entre times de produto e o uso de inteligência artificial. Lá no episódio 294 a gente começou a falar um pouquinho sobre o que a inteligência artificial está mudando no desenvolvimento de software. E agora a gente vai levar essa discussão para dentro da parte de produto. Então como que um time de produto pode se estruturar? Pode se organizar no dia a dia para entregar mais valor fazendo o uso da AI?

A gente tem ouvido muito por aí questões práticas. O que funciona, o que não funciona. Eu acho que falta um pouquinho. Então acho que essa é a nossa oportunidade de a gente poder dialogar e trazer um pouco de exemplos para vocês do que a gente tem encontrado no mercado e de fato no dia a dia dos times de produto.

Érica, eu vou começar perguntando exatamente o que é um pódio. É um nome que a gente deu para poder fazer as coisas de forma diferente, mas com as mesmas pessoas. A gente começou a implementar pódio aqui. A migração de squad para pódio. Até como comunicóloga, eu acredito que o nome que a gente dá para as coisas ajuda a direcionar. Então o squad era o modelo que a gente rodava até então. A gente precisava de um nome novo para a gente poder trabalhar de uma forma nova. Nesse caminho de entender, ler bastante, trocar bastante figurinha de como as pessoas estão usando a AI como ferramenta para produto, para desenvolvimento, para fazer delivery. Pódio foi uma coisa que surgiu basicamente: produtor orientado, livre, colocar de verdade na mão do cliente com mais velocidade. Que não é tão diferente do que foi o conceito do squad no Spotify, de a gente entregar mais rápido, de centralizar as responsabilidades e fazer times multidisciplinares. Mas acho que aqui no nosso contexto a gente precisava fazer alguns ajustes. E é importante dizer que não é uma coisa generalizada no PicPay, porque a gente trabalha em BUs e cada time vai adaptando um pouquinho de como a gente precisa entregar produto dentro de um playbook que a gente tem.

Para a gente foi um caminho possível. O que a gente foi dando de formato para esse negócio, pensando em semântica mesmo, foi dividir um pouco mais as squads. A gente tinha as squads mais robustas, pensando muito em um formato de especialistas. A gente trabalha com mobile, então especialista em Android, especialista em iOS, especialista em back. Só isso faz o nosso time ser muito grande. Então a gente tinha um time mais inflado e que nos obrigava muito a paralelizar coisas para justificar o tamanho do time que a gente tinha. Então a gente trouxe isso muito sobre deficiências do nosso desenvolvimento, que o modelo Spotify de squads não funcionava para a gente. E a gente começou a descer e entender o que isso precisa para ser verdade. Algumas coisas a gente já descobriu que funcionou como esperava e outras não. A gente super estava acreditando nos builders, que o produteiro vai fazer muito trabalho do dev, o dev vai fazer muito trabalho do produto. Essa foi uma coisa que não se concretizou. Mas acho que o que tem de síntese é um time mais enxuto em cima de uma métrica específica. Por isso que eu não acho que vai funcionar para todo e qualquer time.

No PicPay, eu e o meu pai de tecnologia, o Wagner, a gente costuma dizer que é tudo que muda a tua conta. Então hoje eu olho para a Epic, que é nossa conta alta renda, eu olho para PicPay+, que é o nosso produto de assinatura que atende o mercado de varejo, e eu olho para a conta para menores. Então todas as contas acabam tendo características específicas e eu consigo ter métricas muito específicas. Então para a gente ficou um pouco mais fácil separar em métricas. Um pod olha em aquisição, outro olha em engajamento, e a gente tem métricas de ativação, métricas de churn, e trabalhar mais em cima do indicador do que do roadmap.

E a gente começou a falar: quando elas falaram vamos montar um roadmap, eu entendo que a gente precisa montar até para report, visibilidade é importante. Mas eu, há muito tempo, não acredito no formato de roadmap, porque ensina a gente a seguir uma rota fechada, acordada em janeiro, do que a gente vai entregar em dezembro. E no meio do caminho a gente tem métricas estourando. Acreditamos que o forecast ia para esse lugar, a gente descobre que não foi. Então como é que a gente vai estar na rota? Acredito muito nisso até pelo caminho que eu vim de startup, de empreender. A gente vai se adaptando, manifesto ágil todos os dias. Temos acordos, a gente muda de acordo com a necessidade.

Mas pode fazer novas perguntas para a gente ir afunilando no que é a cara de um pod. Respondeu tudo e mais um pouco. Mas eu gostei muito desse ponto do roadmap. Acho que faria bastante sentido a gente explorar um pouquinho isso. Porque a gente acredita muito em que o roadmap não é fixo, não faz sentido a gente se comprometer em janeiro com aquilo que a gente vai entregar até dezembro. Mas com a capacidade de dar visibilidade, de equilibrar a visibilidade com adaptação. Eu acho que vale a pena a gente falar um pouquinho de como fazer isso, como conduzir. Como que eu consigo fazer isso de forma que, se eu precisar mudar amanhã porque a métrica me indicou para outro lugar, eu tenho a capacidade de mudar, não fico engessado nesse roadmap. A gente tem trabalhado bastante isso no PicPay, porque a realidade dos pods faz a gente também repensar a forma com que a gente constrói esses roadmaps. E agora mais do que nunca, se a gente já falava que um roadmap cheio de features focado só em entrega não fazia sentido, agora no conceito de pod faz menos ainda. Então a gente reforça ainda mais a questão de o que eu preciso, do ponto de vista do meu negócio, do meu cliente, do meu produto, atingir e criar. Como se fosse a mínima burocracia viável para a gente dar a visibilidade do que vai ser o próximo passo, se de fato está conectando com as métricas do nosso negócio, do que o produto precisa, sem engessar, sem colocar mais coisas do que necessariamente precisa só para poder dizer que eu tenho roadmap ali de próximas entregas.

Já que então mais do que nunca agora é a orientação a essas métricas que é muito mais importante do que de fato falar, cara, o que eu vou fazer. Ele já entregou. Então assim, já foi. Aí quando a gente vai olhar para aquilo de novo nem faz sentido, já está completamente desatualizado. Então faz a gente pensar numa forma também completamente diferente. Assim já era diferente, só que agora a velocidade faz com que seja ainda mais diferente. Eu acho que justamente daí que acho que um novo ângulo sobre a gente vai precisar do caminho. Vamos precisar do caminho. Mas o que acontecia até então? Eu tinha escassez de desenvolvimento. Desenvolvimento é caro, eu precisava de muitas pessoas. Então tal qual continuamos tendo que discutir o que a gente vai entregar, eu tinha que falar, ó, eu quero entregar esse produto desse tamanho aqui, quantos disso cabe no ano pra eu poder priorizar essas coisas que cabem nesse ano.

E aí, acho que a gente acaba colocando muito em cima da AI e até outros modos operandi. Como eu tô falando de startup, eu tô acostumada a caminhos que o dinheiro acaba. Você trabalha em uma listagem, você precisa sair do ponto A pro ponto B, senão o dinheiro acaba. Você precisa se provar o tempo inteiro pra o investimento de risco que aquilo faz sentido. E cada etapa da startup ela tem um playbook ali do que ela precisa entregar nesse período. Dito isso, ele se desdobra roadmap. Só que essa velocidade que a gente precisa acabar fazendo em uma startup, de mudar de rota, ela tem que ser muito mais rápida, senão eu não chego com o dinheiro no próximo estágio.

No lugar de a gente discutir qual é, e até fazendo a quebra disso, quando a gente desenha roadmap em estruturas com mais escopos bem definidos, com uma maturidade, com empresas como a gente que leva investidores de mercado, não é investidor de risco, você tem uma estrutura mais inflada e que ela precisa de uma burocracia do bem necessária pra você garantir o bem-estar da companhia, a sustentabilidade da companhia. A startup, ela tá prestes a morrer a todos os momentos. Então quando a gente tá numa empresa maior como essa, a gente tem roadmaps mais detalhados, a gente tem muito mais coisa de sustentação, a gente vai ter muito mais coisa que é regulatória, que não dá pra fugir de todos esses aspectos. E aí o que a gente faz é roadmaps que a gente passa um tempo refinando com os desenvolvedores e ele vira, mais do que uma grande missão, ele vira vários pedacinhos pra gente falar por que esse negócio, em vez de uma semana, vai durar três meses. Se gasta muita energia, e até certo ponto necessária, pra conseguir chegar nesses alvos enquanto delivery, porque cada time tá desenhando um pedaço. A startup, pensando em entropia, a startup é o caos. Então eu tenho uma missão, eu preciso chegar no indicador X desse tamanho. Então eu vou fazer um forecast, muito mais do que um roadmap, e a gente imagina que pra atender esse forecast eu preciso fazer ABC nesse prazo. Porque se eu não entregar neste prazo, eu não entrego o forecast, eu não tenho dinheiro suficiente pra chegar no outro ponto.

Então o que a gente fez aqui, até porque nosso time tem bastante que veio de uma startup que foi absorvida pelo PicPay, a gente teve a oportunidade de discutir sobre a ótica de AI como ferramenta nova e novo modelo de trabalho, muito do que a gente trouxe desse universo de empreender. Então, cara, paralelizar não deveria ser uma opção. Deveria ser, eu tenho mais pessoas, eu vou paralelizar sempre. Aí vamos fazer times menores, com missões mais específicas, que na prática o que eu tô fazendo é quebrando a squad de X pods. Em vez de eu ficar priorizando e paralelizando essas coisas entre elas, eu defino muito claramente de ponta a ponta como as pessoas vão fazer. Dado isso, eu tenho meu roadmap com grandes missões, eu preciso levar para o mercado essa grande aposta, que ela simplesmente é parte do meu plano pra chegar nesse forecast que a gente desenhou. Se no meio do caminho eu não conseguir atingir, por exemplo, coisas que sempre são muito difíceis de estimar, otimização de fluxo de aquisição, quando a gente tem checa, layout, landing page, é always on, é teste A, atrás de teste A, até eu falar, ok, estou num ponto ótimo, agora a gente faz uma manutenção disso aqui, deixa eu ir pra outra etapa. Eu consigo colocar um pod com essa missão. Aí o que eu vou fazer dentro do meu roadmap, pra esse caso específico, eu vou ter que fazer uma linha muito mais longa do que o normal, que a gente coloca de projetos menores, de gestões menores, como otimização de landing page, porque importa menos se eu entreguei alguma coisa. Eu vou ter entregado 500 coisas nesse período, só que o que me interessa é aquela premissa da taxa de conversão que eu coloquei, a gente atingiu? Se atingiu, beleza, vamos pra o próximo assunto. Porque é um negócio que no modelo roadmap tradicional, enquanto gestão de projeto, a gente tem mais dificuldade de encaixar, porque como é que eu adiciono uma coisa que eu vou ter 15 versões dela? Não, é sempre uma grande versão, e aí eu vou ter que ser muito assertiva e vou passar muito mais tempo discutindo.

E aí, aproveitando que estamos numa mesa de mulheres, tem uma fala da Fiona, que ela é diretora de desenvolvimento, mas tem uma frase dela que é: quando a discussão ela é mais cara, o meu desenvolvimento tem que ser mais rápido. Então antes eu tinha que discutir muito porque o meu desenvolvimento era caro. Agora que o meu desenvolvimento é barato, eu vou desenvolver muita coisa e muitas dessas coisas nem vão pro ar, porque vão parar em alguma barreira, ou de ser inscrito de uma forma geral, ou alguma questão de design, desenvolvimento das outras áreas que vão ser nossos guardrails ali, nem vai subir. Ou eu vou subir, na segunda vai estar uma versão, na terça, na quarta, na quinta vai estar outra versão já, porque eu tenho essa capacidade de fazer deploy com mais agilidade, já que o desenvolvimento caiu. Então eu posso trabalhar com menos discussão, que eu vou ter mais assertividade e menos risco. Então eu acho que isso muda meu modo de operando e por consequência as ferramentas que eu tinha até então. Roadmap é uma delas, que eu tô assim, qual é o meio do caminho? Porque eu sei que não é abrir mão do roadmap, mas ao mesmo tempo o roadmap até então já não me atende mais. Que bicho é esse que eu vou começar a usar? E aí eu acho que a gente tá numa etapa muito de descobrir junto, o mercado inteiro descobrindo, a gente trocando figurinha, mas menos certezas e mais tentativas.

Pensando um pouco nessa ideia de dado que eu maximizei a minha capacidade de delivery, como que fica então a minha capacidade de discovery? Porque se o delivery é muito mais rápido, o que eu tô fazendo no discovery agora de diferente? E aí a gente tem visto muitas empresas investindo muito em IA, não necessariamente tendo o retorno esperado, exatamente porque a IA pode estar acelerando o meu delivery na direção errada. E o que eu preciso é garantir que eu tô descobrindo pra onde eu tô indo, esse equilíbrio entre eficiência e eficácia. Porque não adianta eu produzir dez vezes mais rápido se eu tô produzindo algo inútil, se eu tô produzindo algo que o cliente não usa, não entende, não atende a necessidade dele.

E como é que vocês veem hoje as mudanças que a gente tá tendo que fazer no discovery, dado que a gente mudou completamente o nosso paradigma de delivery? Cara, eu tenho discussões homéricas sobre esse assunto, principalmente citando com carinho a minha amiga Maria Carolina, que ela trabalha hoje no Potecário, um produteiro também, e a gente tem uma grande discussão sobre até onde o produto vai, esse protótipo e depois vai pra o downstream. Eu tenho muitas dúvidas sobre o modelo que temos até então de upstream, downstream, se ele faz sentido ainda. Porque quando a gente parte da premissa de que se eu tenho mais capacidade de entregar, se eu deveria estar entregando mais mesmo ou não, se eu deveria estar gastando mais tempo no discovery, eu acho que não tem resposta ainda pra isso. O que eu tenho me questionado, refletido, é sobre essa separação de upstream e downstream, de discovery e delivery. Se eu entrego rápido, o protótipo não deveria ser algo que eu possa testar na mão do cliente, seja em ambiente controlado, ou seja no rollout em produção, mas num volume menor de pessoas. A minha grande dúvida é, será que o discovery, enquanto essa parte do escopo mesmo do produto, eu acho que tem o discovery de mercados e oportunidades que continua e acho que ajuda muito, mas enquanto o discovery do produto que eu deveria entregar, o produto certo, eu tenho dúvidas se a gente deveria ter essa linha de separação entre as coisas ou se a gente, e esse é meu sonho, que eu tô achando bem difícil chegar nele, desse time multidisciplinar fora, que não é multidisciplinar, eu tenho um desenvolvedor, um produteiro, um designer e eu tenho pessoas com perfis e aí voltando ao depar de startups e o Vale do Silício, ele tem um perfil sonhado de founding team, que é o hipster, o hacker e o hustler, que é um cara que vende até a mãe, um cara que consegue desenhar, ser criativo pra mostrar como se materializa e o cara que consegue desenvolver. Quem desenha pode desenvolver, quem desenvolve pode vender, todas essas coisas meio que se misturam. Então será que eu consigo ter menos cargos e mais perfis de pessoas pra chegar no outro lado e cada produto vai ter uma composição de perfis talvez um pouco diferente?

Eu tô falando isso porque se eu tenho um time que ele tem esses perfis diferentes, talvez esse mesmo time esteja no upstream e no downstream, esse mesmo time esteja no discovery e no delivery. Em vez de eu estar enchendo o meu backlog de coisas e me aprofundando pra garantir que o desenvolvedor não vai ficar ocioso, eu convido esse desenvolvedor pra pensar junto. Eu acho que isso muda muito o perfil dos profissionais que a gente tem, por isso que eu acho que é extremamente difícil um profissional que, no lugar de ser mais tarefeiro, de o escopo é esse e por mais que tenha uma bagagem não é diminuindo a capacidade técnica, mas seja menos o como eu vou entregar isso e muito mais o porquê que estamos fazendo isso. Um desenvolvedor perguntando isso é um formato muito diferente, inclusive os desenvolvedores que fazem isso acabam virando líderes porque eles trazem um perfil diferente. Então como é que a gente multiplica esses caras no mercado, já que é parte de escrever tal qual uma máquina, a máquina está fazendo. Então como é que eu consigo trazer perfis diferentes? E aí, se eu trago isso, talvez a discussão do discovery enquanto escopo e o delivery ele também se misture mais e seja só um grande bloco.

Aí, acho que antes disso e aí voltando para a conversa enquanto discovery, quais são as oportunidades e como a gente define essas grandes métricas, metas que a gente vai chegar em relação ao que a gente vai entregar. Se a gente tivesse norte, essa missão bem dada e ela assim discutida, aí eu acho que a gente pode usar muito da AI enquanto ferramenta para acelerar tanto a descoberta mesmo, a validação com o usuário, inclusive entrevista com o usuário que a gente faz a persona sintética e faz uma prévia ali, depois valida com pessoas reais, a gente já consegue colocar um protótipo pré-produção na mão dessa pessoa, se ela validar, talvez a gente já consiga colocar para 10 da base para a gente ver se realmente funciona legal e leva para onde a gente quer ir. E, para além disso, que não foi exatamente o que você perguntou, mas é que eu acho que é importantíssimo dizer o quanto a gente mata ideias no começo, que até então a gente não tinha oportunidade de fazer isso. Está muito fácil desenvolver e, assim, está muito fácil, trabalhamos com um produto aqui, e o podcast anterior foi o desenvolvimento. Sabemos que não é tão fácil quanto aparece nas redes sociais, mas de fato está muito mais fácil do que era antes. Se está mais fácil, putz, eu posso me apegar menos, eu posso me apaixonar literalmente menos pelo produto que eu estou entregando e mais pelo problema. Como é que a gente faz a missão muito mais bem definida e smart a gente fazer deliveries, N deliveries em cima disso? Então eu não sei a resposta ainda, descobrir delivery, porque eu acho que e aí voltando no que eu estava conversando no bar com a Maria, a Maria não consegue concordar que o produteiro vai fazer o protótipo e vai para a produção. E o meu questionamento com a Maria é por que eu vou fazer um protótipo não usável sendo que agora ficou muito barato de fazer um protótipo que, se eu quisesse, eu colocaria em produção. Ah, mas tem características específicas de desenvolvimento. Sim, aí ele quebra, sobe de novo, o que a gente precisar fazer. E aí talvez se a minha relação com o desenvolvedor esteja mais fluida, ele estiver participando mais do discovery, ele possa desenvolver o protótipo, porque ele vai demorar muito menos tempo também para desenvolver e ele vai ter essa capacidade com certeza muito mais acentuada que a minha. Mas, cara, dá para fazer, eu falo isso, que é passar o portal, depois que você passa o portal e você descobre o que é possível se fazer, enlouquecemos. Porque antes a gente tinha uma limitação da criatividade que, lógico, continua existindo, porque só trouxe uma ferramenta nova. Mas IA enquanto ferramenta acelera muito as entregas. E se eu fizer para testar? Deixa eu testar aqui. E aí, se não funcionar, a gente mata.

Depois dessa aula de produtos com IA, a gente fez-me refletir sobre muitas coisas aqui, tipo quebras de paradigmas que acabam acontecendo agora que a gente tem uma tecnologia para acelerar a entrega. Então a gente começa a pensar formas que a gente não pensava antes. Então quebrar talvez alguns vieses que a gente tinha, do tipo só tal pessoa faz tal coisa. Antes existia uma delimitação muito clara entre o upstream e o downstream, só que agora de fato isso se fundiu. E tem se fundido cada vez mais, porque realmente a tecnologia está promovendo esse cenário acontecer. E também uma coisa que você falou que chamou bastante minha atenção é como a gente acaba acelerando a quantidade de entregas, a vazão. A gente também acelera outras coisas que talvez antes estavam acontecendo, mas não numa velocidade que a gente precisava. Então por exemplo, isso do profissional ser não só ali olhando para a sua própria expertise, mas também apoiar os outros membros do time, porque ele tem um perfil diferenciado. A gente já falava há muito tempo do profissional T-shaped, do profissional Pi-shaped, que era o formato que ele precisa conhecer. Ele tem uma habilidade primária, mas ele também precisa outras habilidades secundárias. E isso tem a ver também com o perfil, com personalidade, do tipo, eu estou disposto a fazer coisas e ajudar as pessoas do time. Só que isso acelerou também. Então aí acelera comportamentos, acelera mais coisas do que só a gente está imaginando numa camada de entrega. A gente começa a falar de coisas que talvez não estavam na velocidade que a gente precisava, mas agora a gente vai precisar falar porque está acontecendo.

Muito legal essas reflexões. Disso, tem uma frase que eu não sei quem foi que postou no LinkedIn, que quando eu li, eu falei, cara, é isso. Ele não lembra a pessoa para dar o crédito, mas ele falou: estamos tratando como tecnologia um problema que é de pessoas. E eu acredito muito nisso, porque precisamos de perfis diferentes, profissionais diferentes, atitudes diferentes. É uma cultura necessariamente diferente para a gente trabalhar e definitivamente por acaso não. Poderia ser outra coisa, outra coisa com certeza.

Eu estou aqui na minha tentativa de fazer um resumo, porque Érica, eu geralmente gosto de fazer resumos dos episódios. Mas vou dizer que o resumo deste episódio está desafiador, porque a gente já falou de muitos assuntos aqui. Mas eu queria reforçar alguns pontos que eu achei que são cruciais para o que a gente falou aqui, antes da gente dar o próximo passo. Então voltando lá no início, se eu vejo um pod atravessando a rua, o que é um pod? Um pod é um time pequeno e focado em um ou poucos indicadores. E é um time que desmonta um pouco aquela ideia de grandes squads, faz com que a gente consiga reduzir a complexidade de gestão de um time, porque eu passo a ter times menores e não ter times tão inflados. E ao mesmo tempo é uma alternativa para eu conseguir aumentar o paralelismo dentro da organização, sem prejudicar o foco das pessoas. Porque antigamente a solução que a gente tinha era, então pega fulaninho e bota em quatro times. Então pega esse time, fala para ele fazer 200 mil coisas. Mas a partir do momento que eu consigo ter uma gestão um pouco mais descentralizada, de modo que as pessoas tenham times mais autônomos e menores, eu consigo paralelizar a quantidade de coisas que eu estou fazendo numa medida que eu não tiro o foco das pessoas ou coloco elas em um milhão de times. E a gente já sabe toda a história que isso desenrola. Então beleza, já consegui entender aqui o que é um pod. Aí a gente foi para a parte de discovery versus delivery, entendendo que as fronteiras estão mudando. E não somente a definição do que é cada coisa, não tem uma linha tão bem definida mais entre o discovery e o delivery. E aí principalmente o insight que me veio é que, às vezes, é mais barato eu usar o delivery para descobrir e não tentar fazer o discovery antes de tudo. E quando a gente acelera muito a entrega, fazer as melhores escolhas se torna cada vez mais essencial para eu evitar desperdício. E aqui não é só um desperdício de construir, porque se a construção está mais barata e eu posso construir e descartar, tudo bem em certa medida. Mas um desperdício da vida do meu cliente, que vai estar lidando lá com os 400 teste AB que eu estou fazendo, e cada hora muda um negócio diferente para ele. Ele abre o aplicativo dele hoje, tem uma cara, ele abre amanhã, tem outra, ele não se acha. Então a gente tem que ter muito cuidado com o desperdício que a gente coloca na mão do cliente. E aí conecta muito com o que a Érica trouxe, que é descartar o mais cedo possível. Vai ser essencial e muito estratégico para eu conseguir ter o melhor impacto. Porque no final do dia, a burocracia, ela não pode deixar o processo mais caro do que a construção e o aprendizado. Então se é mais barato eu construir, errar e aprender, é melhor eu fazer isso do que eu colocar uma burocracia que tenta evitar todos esses erros no processo. Claro que sempre mantendo ali um equilíbrio. E aí a gente chegou agora por fim nos perfis dessa galera, quem é que vai estar nesses times, nessas novas estruturas. Ando para uma ideia que não são perfis somente baseados nas hard skills e formações, aquela tria famosa, produto, design e TI, que a gente já considera muitas vezes como a base, mas em habilidades que são talvez mais sociais, aproveitando aqui o background da Érica, sociais e de comunicação. E essas habilidades precisam ter um protagonismo maior nessa nova realidade.

E aí fazendo então chegando ao final dessa primeira parte de resumo, eu queria jogar a bola agora para a Ju, para falar assim, Ju, com toda essa mudança aqui, como é que eu boto uma governança nesse negócio, de um jeito que não seja burocrático, porque a burocracia não pode atrapalhar a entrega do time, mas que lide com essa realidade de eu vou ter vários pods, cada um com seu foco específico, tentando gerar valor para o negócio numa velocidade muito maior do que antes. Então, Ju, vou te entregar só esse problema aí, para você contar um pouquinho de o que você acha que a gente pode fazer para resolver.

É uma excelente pergunta, e eu vou te dizer que a gente está aprendendo e fazendo alguns testes exatamente com o time da Érica e com o time do PicPay, porque essa nova estrutura e essa nova dinâmica de pods, para a gente, também é muito novo como consultoria. E aí eu faço uma conexão com o ponto que a Érica mencionou aqui, que é falar sobre grandes objetivos, estratégias e métricas, olhando para isso como um grande destinador, de fato, das priorizações e das estruturas dos times de tecnologia. Então quando a gente olha para essa visibilidade, esse desafio que a gente tem de levar isso para uma visão mais executiva, essa estrutura dos pods, o dinamismo, o teste rápido, ele está dentro do time, ele está no dia a dia. Mas o diretor executivo, o CEO, não, o VP, não vai conseguir ver todo esse dinamismo. Então a gente pergunta, e é o que a gente está pensando, qual é a primeira que esse time está solucionando? Qual é essa frente de priorização? Qual é a grande estratégia? E dentro dessa estratégia você pode ter muitas mudanças, que é o que a Érica está trazendo. Quais são os testes que a gente está fazendo se eu estou querendo, de repente, ampliar o meu posicionamento no mercado em determinado tema? Então essa é a grande ambição. E eu vou fazer várias coisas dentro desse período para entender o que de fato funciona, para ver se eu atingi aquilo, se eu estou mexendo o ponteiro, qual é o indicador que a gente está mexendo. E aí existe essa grande dinâmica entre temos vários indicadores, talvez esses indicadores tenham muitas mudanças rápidas, mas a gente tem essa grande estratégia conectada e como é que a gente traz essa visão para as lideranças também de produtos para falarem assim, beleza, apesar de eu estar fazendo 50 novas entregas, 50 deliveries, talvez eu tenha um grande objetivo maior, uma métrica muito maior. E aí a gente está fazendo um pouco desses testes também ajustando essa rota para responder essa pergunta. Então qual é a grande ambição que a gente tem? E aí são testes, a gente também não tem nenhuma resposta pronta, mas eu acho que esse direcionador de qual é o problema que a gente está resolvendo, qual é a grande ambição que a gente tem, às vezes com a frente de um pod ou com uma área inteira, com um squad que seja, mas qual é o grande problema que a gente está resolvendo é uma forma de levar essa visão de estratégia, de posicionamento dos times e como os times estão conduzindo ali o seu dia a dia. No fim, os múltiplos comos, como a gente conversou no último podcast, eles fazem muita parte do dia a dia do time e isso é uma rotina mutável o tempo inteiro de testes, de hipóteses, de possibilidades e o time precisa ter muito essa liberdade com essa aceleração que a gente tem de desenvolvimento. Mas a gente ainda precisa desse grande direcional para ajudar a falar com toda a cadeia estratégica e os resultados das companhias.

Legal, esse ponto, porque eu acho que tem essa questão, se a gente está ampliando a capacidade de paralelizar as coisas, a gente também precisa garantir a sinergia entre elas, porque se a gente só paraleliza e cada um faz o que quiser, não vai, no final das contas, vamos voltar à disfunção que eu falo muito quando a gente fala de OKRs, que a Fê também já conhece bastante, que é o OKR quinta série, que é aquele que assim, vamos fazer o seguinte, a gente tem que fazer um trabalho em grupo, mas cada um faz a sua parte e quando chegar lá na segunda-feira, a gente só junta e apresenta e vai estar tudo certo. Obviamente essa estratégia não dá muito certo, porque cada um faz uma coisa completamente diferente e desconexa. Mas lá na quinta série a gente achava que isso ia acontecer e mal sabia a gente que a gente só estava sendo preparado para o mundo corporativo, que depois as pessoas iam dividir a empresa em várias áreas e cada área ia fazer a sua parte, chegar na segunda-feira, apresentar um PowerPoint muito bonito, achando que estava tudo lindo, conectado e entregando a estratégia. É, pior que é isso. O que eu costumo falar é a otimização local não leva à otimização global. Então por mais que a gente tenha a necessidade de dar autonomia, independência e aí acelera isso para os times, o mínimo de coordenação, o mínimo dessa burocracia de, ah, estamos todos olhando para as coisas que realmente importam, é necessário. E aí o que a gente está testando nesse modelo é trazer os OKRs, que eles são adaptativos por si só, esse framework já é bastante adaptativo, então permite com que, por exemplo, se surge um objetivo incorporar em tempo de trimestre, rever o que precisa ser feito, olhar para aquilo. Então combina bastante com a dinâmica dos pods, ao mesmo tempo que dá a autonomia para a gente mexer nas iniciativas que conectam com esses ponteiros. Então a Érica tem lá uma série de iniciativas que são feitas a nível dos times e que elas ajudam a mexer esses ponteiros dos OKRs. E se ela precisar trocar, ela vai com certeza, a única certeza que a gente tem é que vai trocar, ela tem a possibilidade e esse dinamismo. A grande questão agora é o nível dessa informação, em que nível que a gente organiza a granularidade dessa informação para ela ser suficientemente boa para a tomada de decisão no nível estratégico e operacional. Porque no fundo todas as organizações elas ainda vão precisar conectar a estratégia com a operação. Então o desafio é encontrar esse meio do caminho agora e é isso que a gente está buscando com bastante teste, bastante paciência e orientação dos times.

Esse vai e volta, acho que é uma coisa bem legal que tem acontecendo, mas que realmente é por causa desse dinamismo que a gente está tendo agora. E, Fê, eu acho que você falou uma coisa que tem sido crucial nessa nova forma de trabalhar que a gente está vendo emergir com o uso de IA, que é paciência. Acho que uma das coisas que reduziu drasticamente uma vez que a gente começou a acelerar as entregas foi a paciência das pessoas em todos os níveis, porque a gente começou a ter uma ansiedade muito forte em relação a entrega, resultado, tem tecnologia nova, tem ferramenta nova. E aí eu queria pegar esse gancho pra perguntar um pouquinho pra você, Érica, sobre a parte da tecnologia em si, esse desafio de usar IA. Quais ferramentas? Gestão de token, o que que a gente vai usar agora ou não? Surgiu uma coisa nova, boto nesse time, não boto nesse time. Como que vocês estão lidando com essas mudanças constantes e como que isso é absorvido dentro do pod?

Cara, essa é uma pergunta que ela sozinha dá uma bela hora de bar. Como é que a gente tá fazendo a gestão que a gente desce ali, pensando nos times, na gestão de tokens, como a gente muda de priorização, já que a gente vai descobrindo muita coisa no caminho. Muito sinceramente, eu acho que eu não tenho resposta específica pra isso, porque eu acho que a gente não tem maturidade suficiente. Um assunto que tem surgido muito é, por exemplo, sobre a gestão de tokens mesmo, se estamos queimando mais ou realmente fazendo coisa que a gente leva pro mercado, ou de uma forma mais macro, as empresas que estão investindo muito dinheiro em AI, elas estão conseguindo chegar já do outro lado, por mais que pensando em AI faz alguns anos que a gente começa a trazer isso de forma mais ativa no mercado, acho que esse último ano o mercado deu um mortal carpado enquanto ferramenta de AI. Então aqui a gente migrou a stack de desenvolvimento, e usando muita desculpa de AI, porque em vez de eu ter mobile, Android, iOS, eu posso migrar pra um React com muito menos barreira, já que eu tenho o desenvolvimento ali. Então leitura de contexto e linguagem, era um sonho que eu tinha pra falar com meus devs, de falar, cara, não dá pra falar só português, tem que falar inglês, francês, alemão, agora dá pra falar isso porque a gente tem um tradutor que é AI pra este time. Então a gente trouxe esse desafio pro time, e aí pensando em tecnologia, tem desenvolvedores, engenheiros e softwares muito mais receptivos à ideia de construir toda a minha carreira até aqui, mas o mercado mudou, eu tô aprendendo negócio novo, e que legal que eu estou aprendendo negócio novo, quero mesmo aprender isso, e tem gente que cara, fiz tudo até aqui dessa forma, não sei lidar de outra forma, medo do invisível, medo do desconhecido. Então acho que tem, um desafio mais uma vez, de pessoas enquanto isso, e acho que na perspectiva de desenvolvimento, se quebrou algumas barreiras que se tinha, acho que é a área que mais facilmente tá conseguindo se aproveitar da AI enquanto ferramenta, até porque é um conhecimento amplo de open source pra aprendizado, que a ferramenta consegue, tal qual medicina, que vai demorar um pouco mais esse regulatório, tem muita documentação pra AI aprender e conseguir realizar as coisas que a gente precisa. Aí dentro desse universo que estamos aprendendo um monte de coisa, a gente tem que tomar aquele cuidado, que não queremos queimar um caminhão de dinheiro, mas ao mesmo tempo aprender custa dinheiro, e assim a gente tá falando de desenvolvimento, mas sempre custou dinheiro, fazer discovery de meses, sempre custou dinheiro, só que agora a gente tá queimando em um outro lugar esse dinheiro, e aí tem uma questão do bom senso, do crítico, do o que eu estou fazendo com meus tokens faz sentido? O custo do tipo de token que eu tô usando tá fazendo sentido pra complexidade do que eu tô fazendo? Acho que tem uma questão ali que não acho que em todos os nossos times aqui a gente já tá pronto pra essa conversa, porque se você coloca o dinheiro na frente você diminui a adesão. As pessoas vão ter medo de, em algum momento, ó, isso aqui tá caro, então não dá pra fazer assim. Eu acredito muito que é necessário um investimento pra adesão, depois que a gente vai fazer o que a gente vai fazer, a gente tá nesse lugar que as pessoas já não podem mais viver, depois que passou por esse portal, não conseguem mais viver com essa droga que é a AI, aí a gente pode discutir sobre como é que a gente ajusta os medicamentos aqui. Aí nesse momento a gente vai precisar falar sobre otimização de investimento em token, quais são as stacks que estão fazendo sentido, quais são as LLMs que a gente tá usando, a gente pode ir discutindo melhor sobre otimização. Mas antes de colocar alguma coisa de pé, e a gente tá sabe disso no dia a dia, antes de colocar de pé não dá pra falar sobre otimização. Primeiro eu preciso colocar de pé. Então acho que enquanto mercado, eu tenho conversado com colegas no Brasil e no exterior, acho que estamos todos num grande surto de passar pelo portal juntos, e estamos aprendendo nesse caminho. Vai chegar um momento que eu acho que a gente vai chegar em maturidade e entender até quais são os tipos de missão que aproveito melhor da queima de tokens, que eu vou realmente queimar mais porque eu vou ter um grande discovery. Quais são as coisas mais regulatórias, mais de sustentação, que aí eu vou ter uma otimização de consumo financeiro ali que vai fazer mais sentido, mas eu não acredito que estamos nesse momento. Eu acho que é um momento de a gente no máximo falar em voz alta pra saber se é muito absurdo o que estamos fazendo. Aí, beleza, putz, falei em voz alta, tô fazendo outra coisa, parece que tudo bem quem matou quem porque eu vou economizar aqui um tempo pra fazer isso. E depois a gente vai aprendendo com esse caminho. Então acho que em geral precisa ainda bater bastante cabeça, queimar bastante token pra gente saber qual vai ser o formato que vai ser sustentável no mercado.

É, uma boa perspectiva. Acho que é só te fazer uma pergunta, Érica, num dos papos você trouxe um pouquinho pra gente, aí falando também não só do consumo, do gasto, mas também de resultado. Acho que teve algumas coisas que você já conseguiu aferir nesse modelo de times. Você contou um pouco sobre vazão, velocidade de entrega, aí eu queria que você contasse também um lado bom, o que você já conseguiu ver de resultados positivos desse formato?

Cara, eu tenho alguns cases. Como é uma coisa muito recente, a gente tá sentando muita coisa. O que eu já consigo perceber na primeira frente que a gente começou a trabalhar, a gente tinha um time que era squad e outro time que era pod. A gente começou a ver esse time pod, ou seja, com muito menos pessoas, menos da metade entregando na mesma velocidade da squad. A gente pode discutir como a gente tava, sobre o que estava entregando, em que formato, que qualidade, mas fato que a gente conseguia ver que com menos pessoas eu conseguia entregar a mesma coisa. E esse foi um fator decisivo pra gente falar, cara, vamos colocar em todos os outros pra ver se performa igual. E aí a gente percebe que a gente assenta esse paralelismo que antes a gente era negociado, sprint a sprint, agora a gente tem com certeza entregas paralelas. Então acho que a gente tem uma questão da velocidade de entrega com o mesmo volume de pessoas. Uma coisa que é super quali, e é eu conversando aqui com nossos TMs pra entender como é que tá funcionando, foi um dos TMs daqui falar: agora os desenvolvedores, eles sabem o que eles estão fazendo de ponta a ponta. Então a gente espera uma efetividade muito maior da linha de código, porque o cara começa sabendo como ele precisa terminar, e ele sabe o que que acontece. Então ele tem mais domínio sobre isso, e a gente pode esperar que, se ele tem mais domínio, a gente vai chegar mais facilmente aonde espera. Que pra mim, desde que eu comecei a trabalhar em produto, eu gosto muito da frase que eu trabalho como produteiro, é entregar o produto certo, certo. Então escopar o produto certo é um grande desafio, e fazer aquele escopo que a gente desenhou lá no começo, não se perder no meio do caminho, que acontece com muita frequência, é um grande desafio. Agora como isso tá mais encurtado, eu acho que talvez ele mude o formato desse desafio, porque acredito que a autonomia desses times vai conseguir chegar do começo ao final da entrega com mais domínio sobre o que tava sendo feito, em vez de a gente fazer pequenos waterfalls passando de mão em mão, e aí o telefone se enviou, a coisa se perde em algum dado momento. Então acho que tem esse ganho da qualidade da execução, que é muito difícil de mensurar.

Coisas que eu não consegui replicar, mas que eu tenho alguns cases, é o produteiro colocando a mão no código logo depois de uma reunião. E eu vou dar um exemplo simples. Estávamos lá numa weekly, discutindo sobre as grandes métricas, e a gente chegou naquelas conclusões que sempre nas weeklys já eram insight. O que acontecia com esse insight? Ele virava um backlog, ele ia ser discutido com o refinamento na próxima sprint, e daqui um mês a gente poderia discutir sobre esse insight. O que a gente tem oportunidade agora de fazer é essas coisas muito pequenas, e no caso nesse case específico era tirar o preço riscado lá na landing page, porque a gente tinha o preço com desconto e o preço riscado. E a gente falou, cara, aqui olhando pra taxa de conversão, isso aqui parece estar mais trabalhando do que ajudando. A gente poderia tanto subir o AB, ou a gente só tirar. Nesse caso a gente só tirou e de fato se validou. Então a gente conseguiu aprender muito rápido. E não foi o desenvolvedor que fez isso. Foi o produteiro que saiu da sala, já estava montado a página, ele tem acesso ao GitHub, fez a alteração que precisava fazer, o desenvolvedor só fez a review e foi pro ar no mesmo dia. Então não tem o passada de bastão de comunicação, de um refinamento, de priorização. Então acho que essa capacidade dos pequenos ganhos, no acumulado, vai ajudar muito. É mais difícil replicar, porque tem essa questão do passar o portal. As pessoas têm medo, tipo, e se eu fizer alguma cagada? Então passar por esse lugar, e aí o guardrail é muito importante, porque realmente pode acontecer grandes imensas. Mas é os guardrails, essa dupla do produteiro com a pessoa de tecnologia, acho que ele vai se aproximar cada vez mais, porque as duas pessoas vão saber o que estão fazendo e vai conseguir prezer essas pequenas coisas pra não, assim, em outros ambientes, sei lá, tô montando um slide, vou tentar fazer um depara. Tô montando um slide, aí você tá discutindo com o seu gestor ali, aí você quer mudar o título do slide que você acha que vai ficar de uma forma melhor. Um slide é muito fácil, eu vou lá, troco o título e tá feito. Só que a gente não conseguia fazer até então isso em tecnologia. Da coisa muito simplória, eu tenho autonomia pra ir lá porque é uma coisa fácil de fazer. Então acho que esse é um ganho dado que a gente precisa potencializar. E eu ainda acredito que em algum nível builder, o produteiro realmente desenvolvendo coisa, seja a nível protótipo ou como for, é uma coisa que eu acredito, mas ela tem sido mais difícil de a gente placar. Por enquanto eu acho que os ganhos são essas pequenas velocidades incrementais, a paralelização e o domínio do assunto. Que no final acredito que isso vai se confirmar em equipéis futuros, mas a gente precisa de tempo pra ver essa maturidade ganhando força ali.

Gente, infelizmente estamos nos encaminhando pro final desse episódio. Eu tô aqui pensando que a gente poderia ter uma série de tantos assuntos que ainda tem, mas fiquei muito feliz com as discussões aqui. Acho que a gente trouxe luz pra vários aspectos e de fato, dentro dessa visão de novas estruturas, de uso de IA dentro dos times, a gente tá abrindo mais perguntas do que respostas. A gente tá nesse momento de mercado mesmo. Então, pra gente fechar, eu queria pedir de vocês três que fechassem dizendo quais seriam as recomendações que vocês têm pra alguém que quer começar a inserir inteligência artificial de forma mais profunda em times de produto. Sejam times que já estão ali na sua estrutura atual ou times que estão passando por mudanças de estrutura. Mas o que vocês diriam pra essas pessoas que ouviram a gente até aqui e falaram poxa, interessante esse negócio, eu acho que dá pra aumentar a minha capacidade de entrega com o uso de IA dentro de um time de produto. Por onde essa pessoa pode começar? Que conselhos vocês dariam?

Começo aqui. Eu tô pensando enquanto eu falo, porque é uma pergunta bem tricky, principalmente porque tá todo mundo aprendendo junto. Então como falar pra quem, como aprender enquanto eu tô aprendendo? Cara, acho que tem uma coisa que é o começo dessa jornada que ela é totalmente ligada com adesão. Pra mim é o negócio do passar o portal. É fazer uma coisa muito pequena, com muita autonomia pra você olhar pra aquilo e falar cara, dá pra fazer isso então? Eu acho que isso é o que acende a chama dentro do time. O time aqui acho que tem um grande desafio das pessoas se sentirem confiantes, que elas se sintam confiantes de que elas podem fazer isso. E aí estamos num ambiente de inovação, a gente vai ter que dar muito espaço pra errar, vamos ter que investir sim. Então pra mim o primeiro passo é pensar em adesão e não como prometer um projeto, que eu acho que esse pode ser um erro. É tipo, vamos fazer um grande projeto de AI baseado em AI, vamos montar um time de AI. Não estou criticando que tenha time de AI, porque algumas coisas são específicas, mas AI tem que estar como ferramenta cross-time. Então eu iria menos pra os grandes batchs pra começar, e mais tentando passar pelo portal e entregar uma pequena coisa pra sentir o gostinho do que é possível se fazer. E aí a gente está falando de produtos, mas tem outros lugares, tem entrevista com usuário, tem análise de dados. Pra análise de dados e pra sintetizar NPS, coisa do tipo, atendimento, é uma fonte de informação surreal. Então é pensar pequeno e começar.

Continuando aqui, eu acho que eu vi inclusive de um parcial aí do PicPay, ela acaba tirando da frente um pouco dos déficits técnicos, dos desafios técnicos. Então saber orientar um time e trazer essas construções, começando realmente do pequeno, e tirando essas limitações técnicas que talvez em outros cenários você teria por conta de processos e uma série de coisas. Então realmente conseguir levar a visão para as equipes, para os times das ambições do que está sendo construído e ajudar nessa função realmente de coisas pequenas do cotidiano, acho que podem fazer bastante sentido aí pra um começo. Começar pequeno.

Ah, eu acho que eu vou só acrescentar, a gente, além de começar pequeno, acho que a gente tem que começar com um problema real, como tudo, que problema real existe que eu posso usar uma ferramenta, que é a IA, pra acelerar essa entrega e validar de fato que esse problema existe. E preferencialmente acho que não começar por algo que é core da empresa. Porque se eu estou começando com alguma coisa que é core da empresa e vou colocar a IA, o meu risco é muito alto. Então será que tem algum desafio que seja específico, que talvez é uma alavanca pro meu negócio, não é algo core, mas que eu consigo acelerar e validar rapidamente esse problema? Então eu começaria por aí. Talvez não indicadores críticos, mas indicadores que são alavancas estratégicas também. Acho que pode ser um caminho.

Muito, muito bom, gente! Muito obrigada. Foi um prazer bater esse papo com vocês. Obrigada a quem nos ouviu até aqui e até a próxima!