#13: Do pedido à estratégia: como conectar funcionalidades a resultados de negócio

é que o outcome, o resultado, o impacto que a gente vai gerar, ele deriva de outra coisa que a gente precisa ter clareza. Às vezes a gente não tem essa clareza. A gente gera impacto porque a gente resolve um problema ou atende uma necessidade da nossa cliente.

E aí, pessoal, tudo bem? Estamos aqui em mais um produto em pauta na série Mentorias. A ideia aqui dessa série é a gente conseguir conversar com algumas pessoas, as pessoas trazerem suas dúvidas, suas questões, numa sessão de mentoria mesmo, porque muitas vezes a dúvida de uma pessoa acaba sendo a dúvida de várias pessoas. E hoje eu estou aqui com o Yuri. Yuri Jupa.

Obrigado por ter topado, Yuri. Conta para a gente um pouco da tua história, como é que você foi parar em produto. E se você quiser já emendar no tema que você quer conversar aqui, bora lá. Beleza. Primeiramente, obrigado, Jaco, pela oportunidade. É um prazer falar contigo.

sobre como eu vim parar em produtos. A minha formação é em engenharia eletrônica e na faculdade sempre fiz iniciação científica, então sempre muito focado dentro da universidade, em Santa Catarina, em Florianópolis. E aí no último ano de faculdade eu resolvi estagiar fora, essa curiosidade de saber como é o mundo lá fora, do outro lado da academia.

Eu acabei entrando numa empresa, numa startup na mesma cidade ali como engenheiro eletrônico, trabalhando com sistemas embarcados. E na minha formação eu emendei, então eu segui trabalhando nessa empresa depois de formado, ainda trabalhando na engenharia eletrônica e sistemas embarcados, até que no momento essa empresa...

Dos vários projetos que ela tinha, um desses projetos começou a ganhar mais tração com os primeiros clientes, interesse, teve um timing muito interessante do mercado. Essa é uma empresa que ela trabalha. Veio então a desenvolver um sistema...

em várias stacks, desde o sensor físico, da criação do sensor físico, então a eletrônica ela entrava muito forte ali, sistemas de coleta de dados, então ela está dentro do IoT voltado para grandes indústrias e coleta de dados de forma remota, dados de monitoramento de equipamentos, então monitoramento de vibração, monitoramento de temperatura de equipamentos de indústria.

E aí todo um sistema SaaS foi criado em cloud, com back-end, com front-end, com aplicativos mobile também nativo naquele momento. E todo o esforço da empresa foi direcionando para esse produto. Os outros projetos foram...

sendo encerrados, e nessa transição surgiu uma oportunidade para gerenciar projetos, que foi a minha transição. O projeto que eu estava trabalhando até então, ele era um dos projetos que ia ser encerrado, e por conta de algumas habilidades, eu acho que eu demonstrava em relação à organização, interesse em conectar um pouco...

essas diferentes camadas do negócio com o que a gente estava fazendo em termos de tecnologia. Surgiu essa oportunidade e eu não pensei muito. Eu fiz essa transição sem saber ainda, sem ter nenhuma formação de gestão de projeto. Naquela ocasião, isso foi em 2016, 2017.

E de lá para frente foi uma jornada de muito aprendizado enquanto eu estava na função. Então, primeiro eu ganhei a função e depois fui atrás de como é que faz isso, qual é o papel dessa pessoa. Enfim, ao longo de toda a jornada, a empresa tinha colegas mais experientes de software, que já tinham trabalhado em empresas de software, que me ajudaram nesse processo, me deram alguns caminhos.

E teve, então, uma dedicação muito forte de buscar a informação. Fiquei vários anos nessa empresa e depois a empresa cresceu muito, teve uma criação de uma área de produto nessa empresa, eu ajudei a...

a desconectar a área de produto, deixar ela um pouco mais independente da área de P&D, que essa área de produto existia como um braço dentro de P&D, mas nesse meu último ano na empresa, ela passou a ser uma área independente, com mais autonomia, e claro, conectando também com a área de desenvolvimento de software, com a área de desenvolvimento de hardware.

E eu tive algumas experiências depois, atualmente eu não estou nessa empresa, eu estou trabalhando em uma consultoria brasileira que atua globalmente, também na indústria, também com grandes clientes. Então, é uma empresa que desenvolve projetos de engenharia, de automação, mas também projetos de software.

para grandes clientes, petroleiras, empresas químicas, de produtos químicos globais, com plantas espalhadas no globo inteiro. Eu estou nessa empresa há mais ou menos dois anos, e um desafio, já conectando com a minha questão da mentoria, um desafio que para mim...

ele existe, é super presente. Eu sempre procurei muita instrução sobre isso e outras visões sobre isso. Que tanto eu percebia na empresa de produto, que era essa empresa que eu estava antes, quanto essa empresa de consultoria que eu estou hoje.

E é interessante porque eu quero ouvir de ti também essa visão, porque são dois universos bastante diferentes. A relação com o cliente, a relação com o contratante, o que se entrega também, tem um trato bastante diferente nos dois cenários. Mas, em última instância, na empresa de consultoria que eu estou hoje, eu trabalho desenvolvendo produtos. Só que são produtos encomendados, são produtos encomendados para a operação desse cliente que é uma empresa no setor de energia.

uma empresa gigantesca, uma das maiores petroleiras, uma das cinco, seis maiores petroleiras do mundo, e eles têm uma camada de... toda uma camada gerencial das refinarias, de tomada de decisão, de monitoramento das operações das refinarias que eles têm em países diferentes. E a questão que eu percebo, que é uma questão muito de produto e muita gente já...

tocou nesse ponto, e é uma questão que eu acho que é um pouco polêmica, é como lidar, basicamente, tentando resumir de uma forma muito curta a pergunta, como lidar com a demonstração de resultado, do ponto de vista de produto, uma demonstração de resultado, de impacto de produto em organizações que têm uma cultura muito voltada à entrega, que têm uma cultura muito voltada a falar, a conversa, o diálogo.

com o cliente ou internamente no negócio, entre comercial, entre marketing, entre direcionamento, o diálogo passa muito pelo domínio da funcionalidade, daquilo que é concreto, que se vê, que se toca. E eu vejo que nessas duas empresas, tanto na de produto quanto na empresa de consultoria, existe uma...

uma questão talvez cultural, mas uma dificuldade em sair de um... Não deixar de falar da funcionalidade completamente, mas também falar sobre esse outro domínio que é o impacto que aquilo causa, que é o impacto lá na ponta financeira que se espera de um determinado investimento. Então, essa para mim é uma grande questão, sabe? Como...

como incorporar mais esses elementos e, por exemplo, diante de uma nova iniciativa, um projeto que está se iniciando ou que seja uma feature, então, numa empresa de produto que está sendo concebida, sabe, como conectar com estratégias para conseguir extrair por trás do que se espera como entregável o impacto. Então, eu acho que esse é um bom ponto de partida para...

para a nossa conversa. É um ótimo ponto de partida, até porque, Yuri, o que acontece? A gente fala muito, a gente quer sair de feature para entregar resultado. Esse é o foco da área de produto, a história do output versus outcome, enfim, todo mundo fala muito disso. Mas uma coisa que, às vezes, a gente acaba deixando um pouco de lado é que o outcome...

o resultado, o impacto que a gente vai gerar, ele deriva de outra coisa que a gente precisa ter clareza. Às vezes a gente não tem essa clareza. A gente gera impacto porque a gente resolve um problema ou atende uma necessidade da nossa cliente. E às vezes a gente desconecta essas duas coisas. A gente fala, não, impacto é uma coisa e resolver o problema da cliente é outra. Não, mas as duas coisas estão intimamente ligadas, na verdade.

Então, muitas vezes a gente fala, como é que eu mostro o impacto? Como é que eu mostro o resultado? Quando, na verdade, o que a gente tinha que estar se perguntando, até antes de falar de como é que eu mostro o resultado, é qual é o resultado que eu preciso gerar? E para a gente responder, qual é o resultado que eu preciso gerar? Qual é o problema que eu estou resolvendo? Porque o problema que eu estou resolvendo me diz qual é o resultado que eu estou querendo gerar.

para, enfim, tangibilizar isso um pouco mais, tem uma história que eu acho que eu já contei aqui outras vezes, mas a mesma história serve para diferentes ângulos, isso é uma coisa legal que eu tenho aprendido ao longo dos anos. A mesma história, ela te ajuda

a enxergar problemas de forma diferente, então essa história é a história que aconteceu, enfim, na época que a gente estava ali no Jim Pass e aí a gente tinha o que a gente chamava de wishlist, que eram as academias que a gente queria muito colocar para dentro e naquela época o Jim Pass ele era bem fábrica de feature mesmo, o time funcionava mesmo como fábrica de feature, eu estava querendo mudar isso aí para ser uma ungefähr 50 minutos

um time mais orientado a resultado, a resolver o problema da cliente e tal. E aí o que aconteceu? Tinha uma empresa ali do Westlist que a gerente de conta fechou com essa cliente e assim que fechou com a cliente, falou, ó, e a cliente, para entrar, ela botou só uma única condição. Para ela poder entrar como uma academia parceira aqui do JimPass,

vocês precisam mudar o fluxo de check-in, porque a empresa precisa que dê o aceite no termo de isenção de responsabilidade dela. E aí ela já mandou, inclusive, até um mock-up aqui de como implementar. Caramba, isso é muito fábrica de feature.

Imagina que você deve ter clientes que chegam assim, que chegam com o mockup pronto ali do que implementar. Aí a gente falou, pô, legal, só que isso aqui que ela pediu vai levar, sei lá, duas semanas, três semanas e vai deixar a experiência muito ruim para os outros clientes que a gente tem ali. Será que a gente vai chamar uma reunião com ela só para a gente entender melhor qual é o problema que a gente está querendo resolver?

Enfim, a gerente de contas se disponibilizou, chegou à reunião, aí a pessoa veio, a pessoa dessa academia, junto com a advogada da academia, porque era uma questão de isenção de termos de responsabilidade ali, aí vieram as duas pessoas ali.

E aí a gente começou a reunião perguntando, entendi aqui o que você está querendo obter com esse teu pedido de funcionalidade, de fluxo aqui, mas me diz uma coisa, precisa ser desse jeito mesmo? É obrigatório? É uma política interna? É uma questão regulatória? Como é que funciona isso?

E aí eles falaram, não, não, na verdade isso aí era só uma sugestão. A gente estava querendo facilitar o trabalho de vocês. O que a gente precisa mesmo é que o cliente dê o aceite no termo de isenção de responsabilidades. Ah, então esse é o problema que a gente precisa resolver. Sim, esse é o problema que a gente precisa resolver.

Legal, e me diz uma coisa, se ao invés de implementar isso aqui que você sugeriu para a gente, a gente implementasse algo assim no fluxo de check-in de academia, colocasse uma frase do tipo, ao dar o check-in nessa academia, você está automaticamente aceitando os termos de isenção de responsabilidade que estão disponíveis nessa URL. Aí a pessoa, se quiser ver, ela clica. Isso funcionaria para vocês?

Aí eles falaram, não, isso está ótimo, isso também seria uma excelente solução. E aí, o que aconteceu? A gente virou o computador ali, mostrou o gráfico, então está implementado, porque esse é um campo de setup de academia dentro do nosso sistema de cadastro de academias. Aí a cliente ficou super feliz, o negócio que ia demorar três semanas foi implementado em alguns minutos, e a gerente de conta também ficou muito impressionada. Poxa...

E se em vez de eu trazer a coisa pronta que eu trouxer o problema para resolver, o time tem capacidade de encontrar outras soluções que talvez funcionem para a cliente. Então, essa é uma mudança cultural. E aí, o que acontece? Como que isso conecta com o resultado? Poxa, academia e o wishlist, três semanas mais rápido dentro do app do JimPass.

mais rápido essa cliente está tendo visitas de chin-pass, que é um resultado que a gente quer medir, mais rápido a gente está oferecendo essa academia para os nossos clientes, então aumenta o engajamento dos clientes. Então, a partir daí, a gente começa a falar dos out-cams gerados. Mas a gente tem que conectar o out-cams com um problema que a gente quer resolver. O problema que a gente queria resolver é como colocar aquela academia para dentro o mais rápido possível. Então, quando a gente fala muito de... É uma conversa que é assim,

ela pode parecer meio estranha, mas às vezes ela desata os nós que ajuda você a mostrar esse mindset de produto. Muitas vezes eu recomendava para as pessoas PMs que estavam trabalhando comigo usar a seguinte frase. Cara, legal que você trouxe esse protótipo, esse mock-up e tal, mas me conta, qual o problema que a gente está querendo resolver?

Por que eu estou te perguntando isso? Porque, olha, olhando o teu mockup aqui, da experiência que eu tenho com o time, isso vai levar X semanas. Agora, se você me contar o problema que isso aí está resolvendo, eu levo também o problema para o time e o time pode encontrar uma solução mais rápida e mais barata de implementar.

e aí obviamente todo mundo quer uma solução mais rápida e mais barata então esse é o caminho que eu costumo recomendar é legal que esse exemplo que você trouxe do DINPASS ele conecta com um outro aspecto que faz parte da nossa função que é fazer perguntas, investigar o problema

Aí tem uma questão que ela toca um pouco isso, que eu não sei se é comum ou quanto pode ser comum essa questão em outros cenários, mas diante de uma negociação com o cliente ou um projeto recém-vendido, que seja assim...

e a empresa que a gente atua como fornecedor, eu sinto, já tive algumas experiências na prática que elas colocaram, que eu percebi uma certa barreira do tipo, até que nível? Ou até onde a gente consegue perguntar alguma coisa com o intuito de uma investigação sem estar...

transmitindo uma mensagem uma mensagem que ela está implícita mas que pode passar pode dar a entender para esse cliente que contratou o serviço como essa empresa ela não sabe o que está fazendo ela não entende do negócio isso é uma linha que eu já tive algumas experiências inclusive recentes que mostraram o quanto uma pergunta num contexto e aí

Às vezes, uma pessoa do cliente que ela não entende muito bem como funciona, talvez, o desenvolvimento de produto. Às vezes, pode ser isso. Mas o quanto uma pergunta pode causar essa impressão. Eu queria ouvir de ti, porque eu acho que essa questão de investigar o problema, tanto internamente numa empresa de produtos, seja com o CEO, seja com alguém que trouxe, um CEO trazendo uma...

um desejo dos clientes, alguém, um diretor comercial trazendo uma demanda que ele ouviu de algum cliente.

pode existir uma tensão interna da gente investigar internamente, mas também quando numa consultoria a gente vai investigar isso com o cliente final então eu acho que esse é um aspecto interessante que nesse sentido eu nunca ouvi muito sendo falado sobre esse trato, esse soft skill eu não sei, Jago, se tu tem alguma experiência para compartilhar alguma visão nesse sentido também

É, Yuri, é muito o soft skill de discovery mesmo, de como é que a gente faz a pessoa abrir o seu coração com a gente, contar ali do problema. Muitas vezes acontece isso, que a gente está muito acostumado a ver, de um modelo mais tradicional, um modelo mais projetão mesmo, que alguém da área de negócios define o que fazer e chama o pessoal lá da TI e, TI, implemente isso aqui.

esse é um modelo de projeto é um modelo bem conhecido e que o modelo de produto tenta ir um pouco além legal que você quer isso aqui, mas pra que? falando de soft skills é o que eu comentei agora há pouco o que eu realmente recomendo é

É ir bem, poxa, elogia a pessoa, fala, pô, legal essa tua ideia, curti muito, né? Ela é muito bacana, faz todo sentido e tal. Mas me conta um pouco mais, né? O que você está querendo resolver com isso exatamente? Onde você quer chegar? Tem algum ponteiro que você está querendo mexer do negócio e tal? E se a pessoa se sentir um pouco incomodada de você? Porque às vezes a pessoa, não, só implementa aí e, né?

faz o que eu estou mandando em última instância vai nesse exagero faz o que eu estou mandando e toca o pau aí você pode ir exatamente nessa linha que eu cheguei a comentar ali ela é super eficiente cara, muito legal isso aqui que você trouxe me conta mais o problema eu conheço a turma além de desenvolvimento mesmo com essas ferramentas de AI nova isso aqui que você está pedindo vai levar um tempão para fazer

A gente tem código legado, tem débito técnico, enfim, tem algumas questões aqui que deixam a questão um pouco mais difícil. Então, se você me contar um pouquinho mais do problema, e aí as palavras mágicas que a gente tem que falar, se você me contar um pouquinho mais do problema, a gente pode, junto com o time, sentar e encontrar uma solução mais barata e mais rápida. Essas duas palavras, uma solução mais rápida e mais barata...

destrava qualquer qualquer pessoa com esse anseio de comandante ali, não, faz isso porque eu mandei, faz isso porque eu mandei, porque mesmo a pessoa que está nessa vibe de faz isso porque eu mandei, se você fala olha, podemos achar uma solução mais rápida e mais barata, a pessoa não vai querer deixar essa oportunidade passar.

Então essa é a estratégia que eu venho usando ao longo dos anos, venho ensinando as pessoas PM que estão comigo em situações similares a usar e tem funcionado assim de forma geral. Às vezes, mesmo assim, você fala não, não se preocupa, implementa aí que é isso que eu quero.

Aí não tem jeito, né, cara? Aí, enfim, faz parte do jogo ali da cadeia de comando. Se for uma coisa que te incomoda demais da conta, eventualmente é pensar em procurar alguma outra oportunidade, algum outro lugar que seja um pouco mais alinhado com o modelo de produto. É isso. Não é solução para todos os problemas. Eu sei que é a empresa que não vai mudar de jeito nenhum, pessoas que não vão mudar de jeito nenhum.

É, às vezes eu tenho a impressão de que é a diferença entre algumas empresas que têm, de fato, uma cultura forte de produto, essas que a gente vê exemplos em livros ou essas que estão na ponta, na ponta no Brasil, por exemplo.

É a diferença entre isso e a vida real, que é uma grande quantidade de empresas que ainda operam de uma forma muito mais tradicional, consagrada e tal. Então, tem essa diferença cultural.

Mas isso é um outro ponto interessante que você trouxe. Realmente, existe uma diferença cultural. Agora, isso não impede a gente de ser agentes de mudança cultural. Esse exemplo que eu te dei do Jim Pass, o que aconteceu? A gerente de conta ficou tão maravilhada com a rapidez com que foi implementado.

que ela começou a espalhar para os outros gerentes de conta do Jim Pérez, falando assim, quando você for levar alguma coisa para o time de desenvolvimento, ou time de TI, leva também o problema que está querendo resolver, porque às vezes eles podem encontrar uma solução bem mais rápida de implementar. E aí, a partir daí, vários gerentes de conta começaram a ver, olha, o cliente pediu isso aqui, mandou esse mockup, mas sei não.

Vai lá bater um papo com o cliente para ver se ele, de repente, tem uma outra solução melhor. Então, essa mudança cultural...

É o que a gente tem que ir lá. É água mole em pedra dura, aquela velha história. Até uma hora que vai furar, até uma hora que o pessoal começa...

para deixar claro, não é uma questão da gente insistir num comportamento, mas a questão é a gente mostrar que aquele comportamento gera resultado. Por quê? Qual que é a língua franca de todas as empresas? Resultado. Ninguém quer falar produtês, teste AB, MVP, hipótese, product marketing. Não, o que eles querem saber é resultado. Está gerando resultados. Então, para a gente...

ganhar essa capacidade de falar de MVPs, de testes a Bs, etc, etc, a gente tem que mostrar resultado com essas técnicas. Se a gente chegar e ficar insistindo, não, não dá, tem que me trazer o problema, sem o problema, eu não vou implementar, acabou, você não vai conseguir ir para frente. Agora, se você fizesse de uma forma bem suave conseguir escavar ali...

da situação, o problema que está acontecendo e de fato conseguir resolver esse problema de maneira que fala, cara, olha que solução legal. Aí você fala, então, essa solução a gente conseguiu mudando a nossa cultura, mudando a forma como a gente resolve problemas. A gente fazia daquele jeito, mas agora usando essa forma a gente conseguiu essa solução super bacana. Talvez faça sentido a gente usar essa forma de resolver problemas daqui pra frente. Então, é um trabalho também que cabe a nós como pessoas de produto.

sermos agentes de mudança cultural. Não é um trabalho fácil. Aviso de antemão. É um trabalho muito... É mudar a forma de operar de uma empresa. É um trabalho de formiguinha. Isso, é um trabalho de formiguinha, é um trabalho pesado. É um trabalho bem pesado. Mas ele é gratificante. Quando você começa a ver as mudanças, ele é gratificante. Você começa a ver as pessoas entendendo essa forma diferente de trabalhar.

que é o caso ali do conteúdo de império quando a gerente de conta viu algo que ia levar o time de TI estava falando em 3 semanas aí sentou com o cliente e resolveu em 15 minutos caramba essa forma de trabalhar é muito melhor e aí ele acabou virando um evangelizador ele vira um outro agente de mudança que te ajuda a propagar sim, é muito legal esse exemplo é muito bom mesmo

Ainda nesse aspecto de investigar um problema, tem algo que na minha experiência recente com consultoria aconteceu e talvez não seja também muito raro aqui. Trabalhando com uma empresa, um cliente que é muito grande, que tem muitas camadas de comando, de hierarquia.

é comum, ou foi comum, chegar na ponta, na venda do projeto, no escopo do projeto, chegar a uma coisa bem orientada à funcionalidade. Qual o problema, em linhas muito gerais, é que a empresa gostaria de resolver. Eu vou dar um exemplo, um problema, por exemplo, relacionado a...

a falta de uma fonte única.

uma fonte, uma single source of truth, uma fonte única da verdade para alguns dados gerenciais, alguns dados de performance. Então, se a gente pensa numa empresa que tem 100 mil funcionários e ela tem vários setores, é muito comum cada setor ali começa a criar as suas próprias formas de medir alguns KPIs e tudo mais. Isso gera um espalhamento e uma confiabilidade muito baixa nos dados. Então, assim, esse é um baita problema de transformação digital. É um problema gigantesco para uma empresa desse tamanho. E...

diante de um contexto, assim, num projeto que ele nasce com essa... esse como um pilar...

central de um problema ser resolvido. Com certeza não é um problema que se resolve em um projeto de seis meses, com uma equipe pequena de 30 pessoas e tudo mais. Então, é necessário fazer, decupar esse problema, ou do ponto de vista de produto até entender por onde começamos.

diante desse problema, desse cenário todo, por onde a gente começa a resolver essa questão. E uma coisa que eu senti nesse caso, que foi bastante desafiador, era conseguir conectar...

Ou, de alguma forma, como medir esse resultado de um problema que, às vezes, é muito abstrato, muito difícil de quantificar. Porque dados espalhados atrasam, talvez, uma tomada de decisão gerencial, mas quanto que esse atraso na tomada de decisão representou financeiramente para a empresa? Isso é uma coisa extremamente difícil de calcular. Então, uma coisa que eu senti...

E fiquei muito em volta desse assunto, tentando pensar como conectar o que estamos fazendo com o produto com possíveis resultados diante desse contexto de problema. Foi algo que eu, enfim...

Passei muito tempo pensando sobre isso e considerando que o cliente tem essas várias camadas, às vezes a gente não tem acesso à pessoa que consegue articular esse problema, que consegue entender qual é o impacto financeiro que essas decisões poderiam ter se elas fossem tomadas de uma forma mais rápida, se a empresa conseguisse monitorar os indicadores de uma forma mais rápida, mais real-time, que seja.

Então, é o contexto que está por trás dessas minhas questões mais recentes. Em relação a isso, Jaca, tu terias alguma...

alguma, algo a compartilhar, assim, né, e tentando resumir a questão, é diante de problemas bastante abstratos, assim, né, que às vezes é difícil da gente conectar ele com o resultado, assim, ou o impacto que esse problema está causando no negócio, né, como, sabe, como investigar, como cavar nesse, como capinar esse terreno, assim, né, formas de...

A gente explorar isso. É, questões com muitos níveis, elas realmente dão um trabalho extra, principalmente essa questão que você falou, de chegar na pessoa que, de fato, poderia saber ou poderia te dar um indicativo claro de onde seria esse impacto, de onde aconteceria esse impacto.

A minha recomendação numa situação como essa é tentar chegar nessa pessoa de alguma forma, conseguir articular com alguém para entender melhor qual o impacto disso, não ter isso hoje causa o que para vocês. Se eventualmente...

você não está conseguindo ter acesso, talvez alguém mais sênior na consultoria falando com alguém mais sênior dentro da organização. Eu já vi, enfim, já acompanhei empresas de consultoria, tem as pessoas que estão ali mais próximas do dia a dia, fazendo a consultoria, provavelmente dito, fazendo todo o desenvolvimento, fazendo trabalho de produto, design, engenharia e tal, mas tem uma pessoa gerente de conta, até chegar no nível do...

das pessoas que são sócias ali, donas da consultoria. Às vezes, pode ser necessário engajar até a pessoa sócia ali para ajudar a destravar e conversar com a pessoa mais sênior da tua cliente para conseguir extrair essa informação. Mas o ideal seria conseguir encontrar essa...

essa informação. Se o nível da pessoa está meio inacessível para vocês, aí é escalando dentro da consultoria para que o nível da consultoria equivalente possa acionar essas pessoas. É o que eu vi acontecendo. Eu nunca trabalhei em consultoria.

mas eu trabalhei do outro lado, eventualmente, contratando consultoria. E eu via que algumas coisas eram do dia a dia, mas quando algumas coisas travavam no dia a dia, eu estava ali mais no Cilevo, então eu não acompanhava os detalhes do dia a dia, mas quando travava alguma coisa no dia a dia, o pessoal da consultoria escalando internamente para que alguém viesse conversar diretamente ali comigo e me trazer essa questão para a gente ver como a gente podia endereçar.

Esse é o caminho que eu recomendaria. É, legal. Imagino que sim tem essas camadas. Sim, tem essas camadas. Esse caminho de escalação dentro da consultoria é bem claro, sim. E o que é muito bom, muito bom para quem está na linha de frente ter camadas às quais recorrer para resolver problemas mais abrangentes. Então, com certeza, é um caminho interessante a ser considerado mesmo. Obrigado.

Imagina, imagina. E mais algum ponto que você queira trazer? Eu acho que a gente conseguiu cobrir as minhas questões principais recentes, assim, Joaquim. Obrigado demais. Legal, legal. Poxa, Yuri, super obrigado aí por ter topado participar. E é isso, vamos fechar o episódio aqui. Pessoal, espero que vocês tenham gostado. Yuri trouxe pontos bem interessantes, né? Essa questão do mundo de projeto e produto, né?

stakeholder definindo o que fazer, não dando muito espaço para a gente entender o problema, muito menos saber qual é a métrica que a gente vai impactar. Espero que tenha sido útil aí para vocês. E é isso. Enfim, se fizer sentido esse episódio, compartilha com alguém, compartilha com quem fizer sentido. E se você quiser participar dessa mentoria, eu sempre deixo o link, quando eu anuncio cada episódio, eu sempre deixo o link na minha agenda. É só marcar.

E aí a gente faz essa conversa. É isso aí. Valeu, pessoal.