Marcelo Szuster: Bom dia, boa tarde, boa noite, vamos começar mais um episódio de Os Agilistas. Hoje nós estamos aqui com um time que tem uma experiência muito grande de gestão de produtos, que é um assunto extremamente relevante, como nós já mencionamos várias vezes aí em vários episódios do podcast. E o nosso objetivo hoje aqui é fazer um episódio bastante prático, onde a gente possa falar sobre os principais problemas que existem na gestão de produtos e, obviamente, como a gente pode fazer para evitar esses problemas, para identificar esses problemas. Para isso então eu estou aqui com o Vinição, beleza Vinição?Vinicius Paiva: E aí (inint) [00:00:41], tudo bem?Marcelo Szuster: Estou aqui também com o Vitor Rangel, que já participou de um episódio que fez bastante sucesso. E aí Vitor, beleza?Vitor Rangel: Fala Szuster, fala pessoal. Vim aqui mais uma vez falar dessa grande paixão que é a gestão de produto.Marcelo Szuster: Estou aqui também com o Marcos Leão, conhecido aqui como Marcola, a partir de agora só o chamarei de Marcola. E aí Marcola, beleza?Marcos Leão: E aí Szuster, beleza? E aí pessoal?Marcelo Szuster: Brevemente, Vitor e Marcola, fazer uma apresentação de vocês para quem não os conhece, o Vinição já é figurinha carimbada aqui.Vitor Rangel: Beleza, então meu nome é Vitor, eu sou PO aqui na DTI já tem mais de um ano, estou trabalhando dentro de um squad como PO, mas também liderando a guilda de produto que a gente tem aqui dentro e ajudando quem precisar aí nessa gestão de produto.Marcelo Szuster: Ótimo. E você, Marcola?Marcos Leão: Também como o Vitor eu trabalho de PO aqui na DTI, tem pouco mais de dois anos e isso me ajuda a puxar a guilda, ajuda todos os produteiros da DTI quando têm dificuldades, implementar coisa nova, testar coisa nova.Marcelo Szuster: Eu posso falar para quem está nos ouvindo que são dois apaixonados por produto mesmo. Igual eu fico brincando que não podem nos acusar de não gostar de agilismo, não podem acusar vocês de não gostarem de produtos. Então já começo perguntando hoje, se é vocês conseguem priorizar e falar qual que seria o principal problema que vem na cabeça de vocês, o principal problema associado à gestão de produtos.Vitor Rangel: Um dos principais que a gente vê, o que acontece? A gente já tem um texto que fala, eu não lembro de quem é: “apaixone-se pelo problema e não pelo pela solução”, eu não lembro se é o (inint) [00:02:34] ou se foi o Eric Ries, mas esse é um dos principais problemas, quando quem está gerindo o produto, seja o PO, o PM, desenvolvedor, começa a se apaixonar pela solução e não pelo problema, porque quando você testa aquela hipótese e vê que ela está errada, você apaixonou pela solução e não consegue abandonar aquilo ali. O Eric Ries fala muito isso nos testes de hipótese no Startup Enxuta. E quando você apaixona pelo problema, independente da solução você vai apaixonar pelo problema e quer resolver esse problema.Marcelo Szuster: Interessante, porque o cara distorce o mundo para poder ver se a solução dele dá certo, não é?Vitor Rangel: Exatamente.Marcelo Szuster: Não é isso, Marcola?Marcos Leão: Sim. E até pensando no que vocês falaram no último podcast, diferente do projeto e produto, o problema não acaba. Você precisa se locomover, então sei lá, Uber, o Uber sempre vai ter um problema para resolver, você precisa escutar música no seu celular, então o Spotify sempre vai ter um problema para resolver. O problema não acaba, por isso que o produto não acaba. E gestão de produto é sobre endereçar o problema certo para as pessoas certas, por isso que eu acho que um dos erros principais, porque ele ramifica em vários outros erros, sei lá, até mesmo de propósito, é muito legal quando você está resolvendo o problema de alguém, desenvolvendo o seu produto ali e quando alguém tem esse problema resolvido, te vira e fala assim: “sensacional, vocês me ajudaram demais aqui no dia a dia”. Então até para propósito mesmo, acho que é muito papel mesmo do (PO) [00:04:05] passar esse propósito para o time, que esse problema não é do PM e do PO, é do time. Até para isso também o foco no problema ajuda muito, a nossa proposta de valor no final das contas é como que a gente vai estar resolvendo esse problema que aflige um grupo de pessoas, que a gente chama de mercado.Marcelo Szuster: Eu acho curioso porque assim, até tem uma dinâmica que a gente faz aqui, que é o problem framing e é interessante por quê? Alguém ouve e fala assim: “isso é meio óbvio”, as pessoas (inint) [00:04:32] que elas concordam qual é o problema, de alguma forma e aí ficam correndo atrás da solução, pensando que eventualmente o recompensador ou o desafiador é dar uma solução. Sei lá, pode ser que seja desde o colégio isso, você fica lá resolvendo os problemas e tentado tirar o máximo da prova. Mas aqui é como se estivesse em um passo anterior, reconhecendo que você não sabe bem nem qual é o problema, já que você está em um ambiente meio ambíguo, porque a gente faz dinâmicas e na hora que você coloca diversos personagens, atores diferentes, você vê que não é tão claro qual é o problema e que a construção da visão do problema vai acontecendo ali em conjunto. E se você não tem essa visão compartilhada, como é que você vai correr atrás de algum tipo de solução?Vinicius Paiva: Esse ponto que você colocou, Szuster, é interessante porque o problema pode até ser anterior, mas uma vez isso endereçado, se a gente faz um bom problem framing junto com o cliente, mesmo assim, um jeito de ilustrar essa situação de isso ser um grande problema, é a própria existência ainda, a gente vê por exemplo a FP. A FP na verdade o que é? Já vem pré-escrito pelo cliente uma hipótese de solução para aquele problema, já mais ou menos descrita e isso na largada. E mesmo assim ele não enxerga como hipótese, isso é um problema mais sério ainda, ele encara como sendo que ele já sentou ali e já pensou estaticamente na solução e eles vão chamar a DTI para resolver aquele problema daquele jeito, com aquela solução. Então acho que Vitor estava falando no aspecto até de ego, as vezes assim: “eu gostei tanto desse jeito que parece que a gente vai conseguir resolver”, mas tem uma outra questão que é, independente de gostar ou não é já achar e já utilizar um mecanismo de condução que parte desse pressuposto que nós vamos tentar uma solução e muito provavelmente o cara, a pessoa ou o cliente, já sabe que é uma coisa que a gente vai tentar ao longo de seis meses, um ano. É um negócio muito doido.Vitor Rangel: Falando até para os pragmáticos, o Szuster sempre gosta de falar para os pragmáticos, que é um grande público, que mais do que dinheiro, economia de dinheiro para convencer disso, não é? Do que adianta você ter uma solução, as vezes você até já encontrou o problema, ou seja, já passou daquela etapa de encontrar o problema, que já era difícil, mas você encontrou a primeira solução e ela deu errado, do que adianta você ter uma solução que você vai botar em produção, você vai gastar dinheiro com aquilo ali e não vai te trazer solução nenhuma? Então se apaixone pelo problema e seja pragmático, não desperdice dinheiro botando em produção uma solução que não vai resolver nada.Marcelo Szuster: Muito bacana o que você disse, acho interessantes essas conversas. Imagina: se você se apaixona pelo problema, você está ficando muito mais customer center, porque você está realmente tentando resolver o problema do cliente e não tentando dar uma solução que você acha genial. E isso que você falou de economia, tem um conceito aí de economia que são os famosos sunk costs, ou seja, tem hora que o que você gastou, você gastou e tchau, parte para outra. E existem estudos que mostram a dificuldade que o ser humano tem com isso, ele continua insistindo, não consegue chegar um momento e falar: “não vale afundar mais dinheiro naquela solução”.Vinicius Paiva: Eu lembrei aqui que eu até cito muito, as vezes quando eu vou fazer uma palestra ou alguma coisa, você vê que até os mestres erram, eu acho que sempre foi considerado talvez uma das empresas, corporações que mais utilizam e tem essa mentalidade adequada, a Amazon. Acho que todo mundo concordaria com isso, que já está fazendo um modelo nesse estilo de experimentação há décadas, mas tem um caso muito interessante que é esse dado daquele livro Sense and Respond, que é um bom livro de produtos, de (inint) [00:08:24], ele fala de quando o Jeff Bezos meio que apaixonou pela solução do problema para concorrer bem com a Apple, ele apostou totalmente no Fire, Kindle Fire, inclusive eu fui uma das vítimas do Kindle Fire e eles ficaram praticamente um ano desenvolvendo essa solução porque o Jeff Bezos apaixonou por essa solução, entendeu? Ao invés de apaixonar pelo problema. E ele não tinha nenhuma evidência, nenhuma (realimentação) [00:08:51], nada do que eles mesmos já estavam totalmente acostumados a fazer e talvez tenha sido o fracasso icônico da Amazon, pelo menos talvez na última década. E ele investiu muita, muita grana e quando eles iam ver o fundamento daquela hipótese, já não era nem uma hipótese, é uma coisa que meio que veio na cabeça dele, meio que de orgulho, de ego e ele queria fazer aquele negócio de qualquer jeito, sem utilizar uma técnica de realimentação, sem considerar aquela hipótese. Acho legal citar isso que até mesmo os mestres, as grandes referências de mercado também de vez em quando se apaixonam pela solução e não pelo problema.Marcos Leão: Sim, no final das contas foi uma cascata, que talvez um (inint) [00:09:38] ali podia ter, o framework ágil que for, mas se não tiver um método de sense respond, de interação, de melhorar, de ver se o problema está sendo resolvido, de validar o problema e não só a hipótese de solução, hipótese de problema porque até o problema também é hipótese, isso é problema de verdade? Vira uma cascata, é uma cascata (fancy) [00:09:59].Marcelo Szuster: Tudo tem que ser alimentado, é engraçado e dá até uma piada isso, você fala que o ágil virou uma cascata, tanto uma cascata de waterfall quando cascata de uma mentira. É engraçado porque se você quiser chocar um time que se diz ágil, você pergunta para ele assim: “o que você aprendeu no último expediente?”, “quando é que você pivotou?”, você quase que cria um problema existencial na pessoa que está ali achando que está ágil para caramba. Aí nós voltamos naquele episódio do (inint) [00:10:30], você vê que existem umas amarras. Mas beleza, para fechar esse tema então, achei interessantíssimo essa pergunta, então o primeiro grande problema, digamos assim e como o Marcola falou, vai ter vários desdobramentos, por isso que é importante pensar nisso e como a nossa natureza faz com que a gente se apaixone pela solução, talvez pelo jeito que a gente é criado, talvez por uma certa arrogância, seja lá o que for, talvez por não ter humildade de reconhecer: “talvez a minha hipótese estava errada”, a gente tem que se lembrar disso o tempo todo porque senão o processo já nasce fadado ao fracasso, porque você vai ficar insistindo ali, você pode dar uma (inint) [00:11:07] danada em um determinado momento, de estar no caminho certo, mas uma parte do tempo você vai estar errado ou vai estar gastando muito mais do que precisava, mesmo naquele caminho, como o Vitor disse. E aí uma coisa que vem logo na sequência mesmo, naturalmente, “beleza, eu estou apaixonado pelo problema, mas como eu começo a explorar esse problema?” e começar a explorar o problema sempre remete ao famoso MVP. E aí a gente sabe que fazer MVP é outra cascata, aí no sentido da cascata mentira. O que vocês me dizem? MVP entra nessa categoria de principais problemas?Vitor Rangel: Vou começar a contar uma história aqui, que eu já errei criando MVP, então um caso meu mesmo, um caso de insucesso mesmo, o caso de insucesso é muito importante quando você aprende com aquilo. Em um produto que eu trabalhava um tempo atrás a gente estava atualizando o player, era uma empresa de vídeo e a gente estava atualizando o player de vídeo da empresa. A gente tinha um player muito antigo e estava atualizando para um novo. E aí a gente começou ali e falou: “cara, para começar a gente precisa criar um novo player que tenha tudo que o player atual tem, nós vamos fazer uma migração, então tudo que o player atual tem eu vou ter que colocar nesse novo” e aí a gente pensou: “nós vamos gastar mais ou menos dois, três meses para fazer isso e começamos a botar a produção, depois a gente começa a pensar, depois a gente começa a melhorar esse player, a gente precisa pelo menos ter um player igual”. Só que assim, a gente sabe que isso na teoria parece que funciona muito bem, mas na prática não é assim. A gente começou a colocar o player em produção, começou a dar muito problema, se eu não me engano, viraram cinco ou seis meses e quando a gente foi botar em produção a gente descobriu um monte de problema que a gente não tinha pensado quando a gente estava desenvolvendo e aí depois que eu fui pensar: “isso não era o MVP”. O que é o mínimo viável para um player de vídeo? É um player em que eu possa assistir e dar pause, aumentar e abaixar o volume, são essas três coisas, é o mínimo. Então por que eu não achei um cliente que era da empresa, só precisava dessas três coisas, não usava todas as outras funcionalidades e falava: “olha, eu tenho um player novo para você, ele só atende essas três coisas e isso vai te atender perfeitamente”. Isso que é MVP, não há MVP que atende tudo que você tem para depois você começar a experimentar, esse foi caso muito marcante para mim, na época eu achava que eu estava fazendo as coisas certas, aí até esse caso que o Vinição comentou tenho certeza que o Bezos achou que estava fazendo tudo certo quando estava com aquela certeza. Mas depois de uns três, quatro meses que eu passei pelo processo e fiquei olhando para trás: “nossa, mas eu errei feio lá atrás”. Não só eu como o time todo, a gente errou feio nisso. E assim, o MVP não é fácil saber definir, a gente tem um case muito legal, que é o que vocês já contaram no podcast passado, que é o MVP do açaí. Esse é um ótimo exemplo, mas é bom a gente sempre lembrar também que parece fácil quando a gente olha o MVP do açaí, mas é um negócio difícil para caramba.Marcos Leão: MVP virou chamar a primeira versão entregada de MVP e é o que o Szuster falou, cascata perdeu o conceito. Que assim, o (inint) [00:14:12] colocou no (inint) [00:14:13] Startup, que trouxe o MVP e até critica um pouquinho a ideia de MVP, a gente quer validar algo. E esse (inint) [00:14:21] normalmente tem um problema muito grande de MVP, que acho que é o seu caso Vitor, eu tive uma experiência também, que acho que é algo envolvendo migração. É algo que já existe e a gente está substituindo por outra solução, se a gente está substituindo algo que já existe, ou seja, é um produto que já existe, já está sendo viável porque, afinal, as pessoas estão usando. O caminho talvez não é outro. Teve uma vez, acho que a primeira que eu trabalhei de PO e era uma migração de tecnologia, do mobile e eu inocente, que nem você falou, tudo que tinha e era um produto que as pessoas já usavam, já tinha analytics, era pegar e ver que claramente existe um (inint) [00:15:01] ali, sabe? As pessoas não usam tudo, a maioria das funcionalidades, sei lá, 5% usava. É um produto que já está no mercado e já está sendo validado pelo próprio mercado. E eu só fui perceber isso no final, claro e aí no final a gente tentou correr atrás do prejuízo, era um (inint) [00:15:23] fechado, a data foi batendo na porta, mas acho que é isso, uma deturpação de conceito porque as vezes é bonito falar: “não, é MVP”. Eu falo assim: “V1 cara, não é MVP”.F1: O que você falou é interessante porque primeiro tem isso que você disse, a primeira versão, seja lá quando for, ganha o nome de MVP, pode ser um ano depois, mas é MVP. Outra coisa que eu acho engraçada é que você começa a ter vários MVP, MVP um, MVP dois, MVP três e é um negócio estranho, no fundo o que você está falando é: se eu preciso lançar uma coisa minimamente viável rápida, é ver se minha hipótese de valor está correta. Agora, eu quero fazer o papel de advogado do Diabo porque isso é muito bonito na teoria, mas é difícil para caramba mesmo na prática, porque é difícil definir MVP, as empresas, principalmente as grandes e que não são nativas digitais, sempre naquela coleção: “poxa, eu tenho uma imagem a preservar, eu não posso lançar alguma coisa que possa afetar a minha imagem”, o que vocês entendem? Como que lida com isso, sabe?Marcos Leão: Um caso, também era uma migração e é sempre isso, é um produto que já existe e para lançar isso aqui eu preciso de algo pelo menos igual, ou melhor. Uma coisa que eu acho, que já me ajudou muito e eu acho que é uma ferramenta que a gente poderia usar mais nesses casos, é estressar ao máximo o teste de usabilidade, porque pensando no risco de valor, no risco de usabilidade, o teste de usabilidade vai mostrar entrevista, contato com usuário, ir a campo mesmo nesses casos, fazer um teste de usabilidade e pensar: “isso que a gente está desenvolvendo, as pessoas vão conseguir usar?”. Às vezes não precisa em produção, mas eu consigo rodar testes, eu consigo rodar log, eu consigo reduzir esse risco. E no final das contas é isso, eu consigo fazer uma pesquisa de mercado, pesquisa com os próprios usuários, no caso pensando no B2C, como as pessoas enxergam valor nisso daqui. Eu consigo mudar isso, fazer um discovery bem feito, mesmo sem um MVP, no caso desses cenários talvez muito estritos, para conseguir formatar e lançar um MVP.Vitor Rangel: É um ponto que até o Vinição comentou no último episódio em que a gente fala de produto, que o (inint) [00:17:36] fala que o MVP, mínimo produto viável, não é um produto, ele sugere, tinha que chamar de protótipo. Um protótipo não precisa ser um produto que vai para a produção manchar a imagem da empresa, pode ser igual o Marcola comentou, pode ser um teste de usabilidade, então você chama um grupo menor de pessoas e faz um teste com o protótipo daquilo ali. E aí isso é um MVP, porque é igual o Szuster comentou, o MVP é diferente da versão um e aí eu já vi chamar a versão um de MVP um, chamar a versão dois de MVP dois, que são duas coisas separadas. A versão um é algo que você colocar lá a introdução, mas já tem que passar por vários MVP. E o MVP tem que ser chamado de protótipo, e não um produto.Vinicius Paiva: Uma reflexão que eu faço sobre isso aí, cabendo o que você fez que eu acho que é muito legítimo, é fácil falar e a execução é difícil, que quase tudo é assim, a execução é sempre mais difícil. Mas fazendo até um paralelo com DevOps, que habilita ou agiliza, vamos falar assim, que te instrumenta. Eu gosto de brincar assim: não dá para você ir para a guerra com uma faquinha de mesa, tem que ir no mínimo com uma espada. O pessoal vai para a guerra com uma faquinha de mesa para produto, entendeu? Por isso que é difícil, é claro que é difícil se você não cria um arcabouço de técnica e ferramenta para isso, então para você fazer o P ser um protótipo, igual o Vitor falou, tem um tanto de técnica para isso, a gente usa outra expressão no dia a dia só que no mercado em geral o mato é muito alto, vamos falar assim, o pessoal já parte direto para o delivery. Tipo assim, eu já encho de desenvolvedor no time, por exemplo, sendo que eu posso provar a hipótese, eu já vi isso aí várias vezes acontecendo, muitas vezes você fica ali e tem vários casos que a gente vê na DTI de clientes nossos, que demoram seis meses para ter um (auxílio alimentação) [00:19:34] que poderia ser feito em minutos. Como assim em minutos? Se eu pegar um protótipo ali, botar na mão de um usuário que realmente vá utilizar aquilo ali, eu já posso ter uma realimentação, então tipo as técnicas de (fake dó) [00:19:47], Mágico de Oz, uma série de técnicas que habilitariam isso. Hoje em dia eu tenho ferramentas, ou diria que eu consigo fazer protótipos muito rápido, inclusive as vezes navegáveis. Isso não é uma versão de delivery, é uma versão discovery ainda, entendeu? Então eu consigo fazer isso com o time reduzido, gastando pouco, na casa de minutos e se não são minutos, são dias, se não são dias, no máximo semanas e eu consigo ter retroalimentações incríveis e que eu não preciso começar a gastar. E aí eu consigo restringir a quantidade de usuários que eu vou expor, aquilo ali é um protótipo, eu consigo utilizar uma marca fake, vamos falar assim, para testar algumas hipóteses. É claro que nem todos os problemas você vai conseguir escapar da exposição à marca, mas é igual a gente brinca, Szuster, as vezes você está trabalhando com o banco, o cliente utiliza os mesmos critérios de segurança que são antigos para permitir a transação, que é óbvio que tem que ter uma segurança máxima, para trocar um leigo de uma tela, entendeu? Então assim, não dá para a gente utilizar essa questão de exposição de marca para qualquer tipo de problema, talvez 90% dos problemas você consegue fazer algum tipo de exposição. Só concluindo, eu acho que falta a espada para ir para a guerra, a gente fica indo para a guerra com a faquinha de pão.Marcelo Szuster: E sabe o que eu acho curioso, pelo que vocês falaram? Isso me vem à cabeça porque eu sempre fico pensando assim: por que é tão difícil isso, todo mundo fala que o ágil é mais uma questão de mindset e etc. Você vê o seguinte, essas duas questões que vocês colocaram desafiam muito, eu fiquei até pensando naquele episódio do Mariotti sobre a natureza humana, não diria nem que é a natureza humana, mas a forma talvez mecanicista que a gente aprendeu, na qual a gente foi criado até então, que é tipo assim, a gente é muito permeado por dar soluções, é o que prova a nossa inteligência e talvez isso esteja na raiz de se apaixonar pela solução, porque no final você é inteligente porque deu a solução. E aí em segundo lugar você imagina, você chega para um cara e fala: “primeiro apaixona pelo problema”, ele fala: “está bom” e segundo é o seguinte: “mesmo você tendo várias convicções aí, vai fazendo devagar até (inint) [00:21:58] mínimo aí”. Entende o que eu quero dizer? É como se desafiasse a inteligência, sabe? Desafiasse a pessoa ali. Eu lembro que eu fiz um Enzima uma vez que eu chamei de arrogância analítica, sabe? Querendo dizer um pouco isso, que no fundo é como se a gente não acreditasse no mundo complexo, no fundo a gente acha que sabe. Um tanto de gente fala esse troço todo, mas pensa: “cara, eu sei o que precisa, é isso aqui, vamos fazer logo. Para que eu vou ficar aqui, dando um passo para trás para saber o problema? Depois eu vou ficar testando MVP, para que? Eu sei”, vocês concordam? Eu acho interessante explorar isso, porque todo mundo já leu, já viu isso, mas na hora H você vai lá e cai nessa cilada.Marcos Leão: Eu vou linkar isso já com o próximo erro que a gente comentou, que a gente vai puxar aqui, que é de a gente considerar nós mesmos iguais aos nossos usuários. Então assim, eu aqui como PO, ou até como um diretor de empresa, eu considero que estou com dificuldade para achar a página de cadastro, aí eu vou lá e chego para o meu time e falo: “time, eu preciso melhorar esse fluxo aqui” e aí eu considero que, se eu estou tendo essa dificuldade, todo mundo tem essa dificuldade. E quando você considera você igual ao seu usuário, aí você já deixa de ver a necessidade de ter um MVP, você deixa de ver a necessidade de testar uma hipótese porque você já conhece, você está partindo do princípio que você está dando a solução para o time. E aí é exatamente isso que você falou, Szuster, a gente tem uma dificuldade grande de ter a humildade de falar: “eu não sei nada, eu preciso testar esse negócio aqui”. E não saber nada é uma boa coisa, é tão bom quando você tem até a liberdade de falar: “cara, eu não sei, vamos testar isso aqui”. A partir do momento em que a gente começa a ter a liberdade para fazer isso, dá até um alívio no trabalho do dia a dia, porque você passa a não ser mais responsável por todas as respostas.Vinicius Paiva: Tinha um designer aqui da DTI que, sei lá, teve um (take shot) [00:23:50], alguma coisa, que ele abriu assim: “é muito chato ter certeza”, então não ter é muito mais lega.Marcelo Szuster: A gente não é criança não, Marcola, isso que é curioso.Marcos Leão: Sim.Marcelo Szuster: A maior parte das estruturas hierárquicas e etc., essa semana até por coincidência eu acabei fazendo um Enzima sobre isso, a importância de o líder fazer perguntas, mas mostrando quando um líder fica fazendo perguntas, ele mostra que ele não sabe, ele está fazendo pergunta, entende? Porque no nosso ambiente isso é muito claro, mas em certos em ambientes uma mera questão já dá um medinho, entendeu? Porque você tem medo de estar perguntando uma coisa que alguém vai achar que foi bobeira ou que você não sabe, entende?Marcos Leão: Eu fico na dúvida se é uma questão cultural ou se é uma questão igual ao Vinição falou, de ir para a guerra com uma faquinha de pão. Porque assim, acho que um erro que tem muito a ver com isso é que gestão de produto é ir a campo, é se botar à prova e principalmente se botar à prova com ferramenta. E será que as pessoas têm essas ferramentas? Beleza, as vezes tem essa questão cultural, de ego, mas ninguém quer perder dinheiro, todo mundo quer estar certo, nem que seja através de descobrir através de outra pessoa a solução. E será que é falta de ferramenta de descobrir isso? Sei lá, e quando falo ferramentas e análise de dados, processo de prototipação que a gente estava falando, pesquisa, entrevista. Eu fico matutando, será que talvez não é falta de ter uma caixinha de ferramenta mais robusta?Vitor Rangel: Eu tendo a concordar com o Szuster que tem um problema muito sério ali, é uma hipótese também, é óbvio, mas tem alguma questão quase de educação mesmo, em termos de modelo mental, porque querendo ou não, Szuster por exemplo, que já passou por empresas grandes, não todas, mas é muito comum que seja muito feio você ficar indo numa linha de tentativa e erro, sabe? Tem a parte de ego, por isso que eu acho que a gente se apaixona tanto pela solução, como se fosse um certo fracasso você falar que aquela solução não deu certo, sendo que na verdade isso aí é parte do modelo de execução para um modelo ágil de produtos. Então realmente, isso gera um ciclo meio complicado de quebrar.Marcelo Szuster: E sabe o que eu acho? Eu acho que tudo é motivo variável, então as vezes a pessoa tenta até mudar o mindset, aí usa o ferramental errado e fracassa. E aí desiste por exemplo, chega à conclusão de que não funciona, mas tem um livro que eu citei a pouco tempo, sobre aquele (Roger Martin) [00:26:39] que é interessante, que ele fala sobre complexidade para mudar a sociedade em geral, no âmbito político, educacional, de empresa. E ele fica tentando mostrar muito isso, por exemplo isso que o Marcola disse, que você tem que ir em campo. Eu até conversei com o André aqui, que a gente tem que marcar um podcast sobre isso, que o pessoal chama de etnografia, que é assim: a gente substitui a realidade por um modelo extremamente simplificado e isso é importante, a gente trabalha significando o mundo, mas ao mesmo tempo a gente vive também isolado. Eu diria assim, estendendo o que vocês falaram, “o problema é você se confundir com o usuário”, ter uma visão meio egocêntrica, outro problema é você criar um modelo e ficar olhando para ele de dentro do escritório, achando que aquilo ali substitui completamente a realidade. E a gente percebe isso na pele, que é difícil convencer as pessoas de que a realidade está ali, a gente modela, mas a realidade está ali e não está muito preocupada com o modelo não. E o segundo problema besta que tem nisso, eu já falei disso em Enzima também, é que muitos clientes, e quando a gente fala assim “muitos clientes”, não é criticando, é para mostrar a cultura que a gente imagina que com o tempo vai mudar, mas o modelo tradicional de eficiência, como a gestão tradicional tende a achar que é desperdício um time em campo porque o cara devia estar ali gerando ponto naquela solução que alguém já pensou. E por que ele está ali em campo? Para que, não é?Vitor Rangel: Eu vou dar até um exemplo disso daí que você falou, desse primeiro ponto, exemplo besta também. Eu já tive um problema, eu passei por esse problema, que um diretor não queria que eu liberasse o aplicativo Android porque o celular que ele usava era iPhone, sendo que mais de 80% da população brasileira utiliza Android e ali, dentro do escritório, como você comentou, tem muitos iPhones. Então a realidade, o mundo real ignora completamente o modelo que a gente cria dentro do escritório.Marcos Leão: Inclusive tem um autor que fala sobre isso, Clayton Christensen, o livro é “Muito Além da Sorte”, acho que inglês é “Competing Against Luck”, não sei.Marcelo Szuster: Ele que fez jobs to be done, não é?Marcos Leão: Exatamente, que é um negócio muito bacana o jobs to be done. Que é um pouco isso, você gasta rios de dinheiro buscando uma compilação de dados que vai mapear o nosso mercado, o nosso cliente e talvez tentando mapear um problema muito complexo, que na verdade talvez não seja quantitativo e aí ele dá um caso, eu não sei se ele fala esse caso no livro ou se ele fala em uma palestra dele, mas um milkshake. A consultoria dele foi contratada por um fast-food de milkshake, não sei qual é, mas para melhorar as vendas de milkshake e aí o pessoal tinha feito várias análises de cada sabor, feito a quintessência do milkshake saboroso e não teve impacto em nenhum número. E aí ele e a equipe dele foram lá e começaram a entrevistar as pessoas: “por que você vem aqui comprar esse milkshake?”, isso você só pega quando você conversa com as pessoas. E não é à toa que o (Clayton) [00:29:46] fala que produtos são conversas. E aí no final das contas, resumindo muito aqui, entendeu que na verdade as pessoas, quando elas usam um produto, elas sempre estão contratando alguém para realizar uma tarefa, ou seja, um job to be done. Ele entendeu que 50% das pessoas que iam ali comprar milkshake, elas não estavam atrás da quintessência do milkshake, elas queriam um lanche que ocupasse só uma mão, fosse fácil de beber e durasse o trajeto do trânsito inteiro, era isso que elas precisavam. E quando elas não compravam o milkshake, elas não compravam na concorrente do fast-food, elas trocavam por um pão, um bagel, donut, uma banana, eram esses que eram os concorrentes. Então é uma ilusão talvez que a gente consegue prever tudo e as vezes é isso, a gente precisa ir a campo.Marcelo Szuster: Cara, nem as vezes só. Marcola, só para não deixar porque esse livro do Roger Martin o cara cita isso que você falou, essa mania de transformar tudo em quantitativo e analítico. E quando fala de etnografia, por que a etnografia é o que? Você vai estudar uma cultura e se você pudesse, você ficava ali invisível, observando e fazendo anotações e aí depois você tenta tirar alguma conclusão, mas normalmente as equipes já trabalham sobre algum indicador que alguém fez, que já substituiu uma realidade inteira e vira realidade. E aí você vai imaginar que tem alguém ali desenvolvendo um produto que você pretende que seja o melhor produto, todo mundo adora falar isso: “vou fazer o melhor produto de não sei o que” e aí você tem um time ágil e o fato de ser um time ágil pressupõe que está todo mundo no jogo e contribuindo, aqueles caras nunca foram observar os índios, como se você fosse fazer coisas para os índios, mas nunca foi lá ver como os índios vivem, alguém te falou por meio de algum indicador, entende? Por que eu falo isso? Para fazer uma síntese aqui, (inint) [00:31:48] de usuário, a gente está combatendo o próprio egocentrismo inicialmente, de você achar que o que você acha é o que todo mundo está achando, a gente pode estender para além disso, a gente pode falar o seguinte: a gente tem que ter mais contato com a realidade, escrever um pouco mais a realidade e partir dessa inscrição fazer alguma experimentação. E não tentar já trabalhar com uma síntese e ter uma convicção, porque você pode estar errando muito nisso, nessa sua simplificação exacerbada, então ir em campo e ter contato com a realidade é fundamental. Aliás, eu estou vendo que com isso eu já acabei. Só um comentário, quando o Vitor Rangel participa dos episódios nós temos uma coisa organizada, então eu fico até emocionado, já tem até um outro tópico aqui, que a gente acabou e fala exatamente de ir a campo. Mas tem um tópico aqui que eu achei interessante também, que a gente sabe que acontece muito e que é terrível, porque por definição o time ágil não deveria fazer isso, mas como eu estou falando, a gente está falando aqui da realidade, que é essa questão de adicionar funcionalidades, entender que adicionar funcionalidade é melhorar produto. Isso acontece?Vitor Rangel: Isso aí eu vou dar um exemplo aqui, que eu gosto de falar ele, por exemplo: vamos pensar hoje em dois produtos, vamos pensar no Facebook e no Instagram. Facebook tem um monte de funcionalidade, tem muita funcionalidade mesmo, tem coisa lá que eu não tenho nem ideia que exista e o Instagram é um produto com o mesmo intuito, os dois são redes sociais, só que o Instagram tem bem menos funcionalidades, hoje eu vou falar que o Instagram está começando a caminhar por esse caminho do Facebook, mas vamos pensar pelo menos uns seis meses atrás, o Instagram é muito mais utilizado, ele tem muito mais sucesso hoje. O Facebook durante muito tempo foi só agregando funcionalidade e isso começa a ficar mais complicado de usar, as pessoas deixam de querer usar porque é muito complexa, elas não sabem onde encontrar as coisas, então assim, adicionar funcionalidade não significa melhorar o produto. Às vezes melhorar um produto significa você tirar uma funcionalidade, significa você simplificar algo que já existe, ou até um débito técnico. Existe uma guerra muito grande entre POs e product manager para priorizar débitos técnicos que melhoram o uso do seu produto. E débito técnico é sim melhorar o produto, débito técnico não é uma coisa simplesmente que o desenvolvedor precisa, é algo para melhorar o produto.Marcos Leão: Vitor, até nesse exemplo que você deu, da mesma companhia, que é o Facebook, tem um outro produto que é ainda mais simples, que é o WhatsApp. Talvez o WhatsApp seja o maior produto de telefonia do mundo e praticamente ele só envia mensagem e outras coisas.Marcelo Szuster: Você está esquecendo do GoogleVitor Rangel: Que é barra de pesquisa.Marcelo Szuster: Tudo bem que ele é complicado por trás, mas a tela ninguém complicou até hoje. Mas esse negócio é curioso, eu falo que para mim isso tem a ver lá com o comecinho, quando vocês falaram de se apaixonar pela solução, esse é o maior sintoma de paixão pela solução porque você fica cego, garibando as coisas, “vamos fazer esse campo aqui ficar melhor”, se você tivesse realmente se apaixonado pelo problema e ir testando hipóteses, só ia mexer naquilo ali, por isso que eu falei lá no começo que isso faria a gente ser muito mais customer centered. E aí tem um ótimo que eu não queria deixar de falar, que é sobre a falta de visão sistêmica, de muitas vezes enxergar o produto como uma entidade isolada e ele não é uma entidade isolada. Falem sobre isso, por favor.Vinicius Paiva: Eu acho assim, um erro muito comum é achar que produto vai ser aquele produtinho que o time vai ter o UX, vai ter o time de engenharia, vai ter o PO, a pessoa de negócio ali e esquece que tem camada jurídica, tem marketing, tem que passar em growth. Então assim, tem até um caso de um produto que a gente trabalho em cima dele e que a ideia era sensacional, ele realmente resolvia um problema das pessoas, deram a interface de rádio para o celular e fazia muito sentido. Só que era um produto que não tinha growth, não estava bem posicionado no mercado, então não ia adiantar nada. Um produto tem que buscar o market fit, e eu estou falando até um produto B2B, B2I, um produto interno tem que ter tração. Você pode fazer o produto que for, um produto muito bonito, ele pode estar super alinhado com a necessidade dos usuários no mercado, só que se não tiver um plano estratégico e isso encaixado, alinhado com o seu modelo de negócio, não vai dar certo. Então acho que a pessoa, PM ou PO, tem que ser a cola, ele tem que conversar com todo mundo e é um erro muito comum, a gente fica muito restrito ao contexto do (inint) [00:36:38].Marcelo Szuster: Isso aí para mim é mais profundo do que parece, não é? Porque assim, aí parece até uma religião hoje, eu falo tanto disso, que é complexidade. Eu acho que a maior parte dos problemas da humanidade tem a ver com complexidade, de entender que as coisas estão interligadas, que uma coisa afeta a outra.Marcos Leão: Pois é Szuster, o pessoal tem que ler mais de biologia. A gente tem uns exemplos para passar para a galera, que a gente tem lido.Marcelo Szuster: Porque biologia é isso, a gente é de um jeito porque é e pronto, porque evoluiu, todo cheio de camadas e coisas, não sei o que e eu não quero ir contra religião de ninguém, mas não tem uma concepção mecanicista do nosso corpo, é só você estudar qualquer livro de biologia e você vai ver que zona que é, ao mesmo tempo que é bonito para caramba, é uma interação. Mas assim, a questão aqui, aquele livro do Roger Martin fala muito disso, a gente tem abordagens muito reducionistas, então alguém do negócio precisa atender o cliente e resolver um problema do cliente, ele ainda pensa: “vamos contratar um produto para TI”, ele pensa no negócio lá de cá e contrata um produto de alguém, ao invés de integrar isso tudo e pensar: “estamos todos no mesmo barco aqui, testando hipóteses”. É outro paradigma difícil de quebrar, para mim tudo está no tal do modelo mecanicista de a empresa ser compartimentalizada e todo mundo ter um papel muito definido, aí você tem essa abordagem reducionista que impede o trabalho integrado. Para fechar, eu vi que o Vitor escreveu sobre o viés de origem, o que é esse viés de origem, Vitor?Vitor Rangel: Isso aí está até relacionado com o que a gente falou antes, da visão sistêmica. Quem trabalha com produto, era designer, era desenvolvedor ou igual eu, que era engenheiro mecânico, não tinha nada a ver com nada, vem de diversos pontos e a gente viu que no final das contas, trabalhar com gestão de produto é ter uma visão sistêmica, é ver um pouquinho de tudo. Só que as vezes acontece desse viés de origem que é, quando eu sou um desenvolvedor e eu viro um product manager, eu começo a olhar muito para o código, eu esqueço a parte de usabilidade, ou ao contrário, quando eu sou um designer eu começo a olhar muito para a parte de usabilidade e esqueço o código. Então assim, você como gerente de produto, tem até um texto que eu li sobre, o primeiro texto que eu li quando virei gerente de produto, o nome dele é “Product Manager You Are a Janitor”. Gerente de produto, você é um zelador, essencialmente. Que é um texto que eu até passo para a pessoa e falo: não se assustem. Quem trabalha com produto trabalha com tudo, faz de tudo, mas você tem que equilibrar um pouquinho cada cenário, cada ponto, você não pode esquecer a usabilidade, você não pode esquecer o negócio, você não pode esquecer o mercado e você não pode esquecer o código, você não pode esquecer a estrutura. Então esse viés de origem é quando você deixa um dos lados pesar um pouquinho mais que o outro.Marcelo Szuster: Gente, bacana demais. Esse tema é fascinante mesmo. Para fechar aqui, queria agradecê-los e lembrei de uma coisa que eu falava lá no começo do podcast e que me veio à cabeça e que é assim: eu acho que a origem de muitos problemas que fazem com que essas coisas não aconteçam é que isso tudo traz um problema existencial grande, porque é muito fácil você acreditar que você está especializado e pronto, e não ter que equilibrar as coisas. Ou que você já sabe a solução e pronto, ou que seu modelo quantitativo ali já vale por outro, não tem que ir a campo. Isso dá muito mais conforto, porque vocês falaram assim: “não saber nada é bom”, a maior parte das pessoas não consegue viver com isso, mas o que eu acho que é a beleza do ágil, para quem adotar isso na sua plenitude, é assim: você substituir controle pela realimentação contínua, pelo sense respond contínuo, pelo aprendizado contínuo e ter essa jornada onde você vai aprendendo, vai chegando onde você precisa. Esse é o desafio e isso, para a maior parte das pessoas acho que causa um problema existencial, uma insegurança, um desconforto muito grande. Mas é isso aí pessoal, muito obrigado, um abraço Vitor, Marcola e Vinição.Vitor Rangel: Aproveitar a deixa de saída: montar um squad é muito mais difícil do que parece. Eu acho que um pouco do que o Szuster falou ali, no fundo é você realmente ter uma célula complexa, a questão de complexidade e biologia tem influenciado a gente e muito, eu tenho certeza que o Szuster concorda plenamente, inclusive ele tem me indicado alguns livros muito bons. Então realmente, montar um squad é muito mais difícil do que parece, empresas grandes precisam de parceiros igual a DTI, por exemplo, colocar bem o parceiro bem posicionado dentro de um squad mais amplo é crucial para que você realmente tenha os elementos para atacar bem a complexidade. E já que a gente falou de biologia, tem um livro que o Szuster me recomendou esses dias, eu achei muito esquisito, “The Cancer Code”, o código do câncer. Eu falei: “nossa, que coisa estranha, mas vou ler, se o Szuster indicou é porque é bom”. Eu comecei a ler em um dia, não consegui parar de ler e no outro dia já tinha terminado o livro, por mais estranho que pareça, eu nunca aprendi tanto sobre complexidade do que quando eu li esse livro, então eu recomendo aí. É uma recomendação um pouco estranha, mas eu nunca aprendi tanto de complexidade igual lendo esse livro.Marcelo Szuster: Se a Denise Eler estivesse aqui, ela iria falar isso: só nos Agilistas você tem uma recomendação de livro de câncer. É isso pessoal, um abração para todos.Vinicius Paiva: Beleza pessoal, um abraço.Marcos Leão: Um abraço pessoal, até mais.