M1: Bom dia, boa tarde, boa noite. Bem-vindo a mais um episódio dos Agilistas. Hoje, nós estamos aqui com a Yas, que é a nossa líder de design da DTI.Yas: Oi, pessoal, tudo bem?M1: Tudo bom, Yas? Estamos aqui com a Cecília, que é a nossa líder da guilda de (inint) [00:00:18] business (inint) [00:00:18] – o nome é proteus.Cecília: Isso. Olá, pessoal.M1: Aqui na DTI, a gente tem tanta guilda e tribo que eu já não sei os nomes.Cecília: Está se confundindo já.M1: Estamos aqui com o Felipão.Felipe: E aí, pessoal?M1: Tudo bom, Felipão?Felipe: Tudo ótimo. Que bom estar de volta.M1: Os fãs estavam pedindo. Então, o assunto que a gente quer tratar aqui, hoje, tem a ver com a criação de produtos e o que está acontecendo muito no mercado. Na medida em que as empresas se tornam mais digitais, e os negócios delas se apoiam mais nas tecnologias digitais, isso quer dizer que as empresas passam a ver certos sistemas mais como ativos do que, propriamente, como um mero sistema que ela faz uma vez na vida, e depois só vai manter aquele sistema. Agora, aquele sistema vira, na verdade, um produto, que passa a se confundir com o próprio negócio, com a própria oferta da empresa, e aí elas têm que ter toda uma disciplina de cuidados daquele produto durante todo seu ciclo de vida – não somente da qualidade, de manter o produto funcionando, etc., mas talvez, principalmente, conseguir evoluir aquele produto e fazer com que ele continue gerando valor – o que o mercado tem chamado de product discovery. Então, a gente quer discutir um pouquinho sobre product discovery, mas também, inicialmente, começar com uma questão que a gente percebe que é muito importante em todas as empresas, que é o quê? Todas as empresas invejam os startups, e a gente sempre comenta que essa inveja é a inveja dessa incrível capacidade que os startups têm de sentir e responder rapidamente – ou as empresas já digitais, tipo a Amazon, que tem essa capacidade de sentir e responder rapidamente. Então, as empresas tradicionais invejam isso muito, só que elas invejam isso muito e não sabem exatamente o que fazer. E uma das coisas que quem sente e responde faz muito bem é formular hipóteses, conseguir fazer experimento e descobrir rápido se essa hipótese está certa ou errada. Ou seja, a hipótese é o centro de muita coisa que acontece, só que é muito difícil trabalhar com hipótese nas grandes empresas – e talvez não só nas grandes empresas. Então, eu queria começar perguntando para a Yas isso: por que é tão difícil trabalhar com hipótese? Ou a piada óbvia: qual é a sua hipótese sobre isso?Yas: É difícil mesmo. Eu consigo falar um pouco da minha perspectiva como designer, como tendo de trabalhar em produtos durante bastante tempo, e eu acho que o problema é bem lá atrás até – a gente foi educado, até na faculdade de design mesmo, a pensar solução. E até o próprio termo solução implica que eu conheço muito bem o meu problema e eu sei como resolver. Então, a gente é treinado a passar meses e meses pesquisando e gerando milhões de dados para tentar chegar nessa tal da solução perfeita. E aí, quando você cai, às vezes, no mercado de verdade, você está trabalhando com ágil, está trabalhando com produtos para esse mundo tão complexo, você descobre que esse mesmo mindset não funciona mais. E aí você tem aquela crise de: “poxa, então quer dizer que estou fazendo alguma coisa que não tenho certeza que vai dar certo?”, sim, é isso mesmo que você está fazendo.M1: Então, você acha que existe uma cultura no designer, e isso não tem a ver com design de produtos físicos também, não? Porque, no digital, é mais fácil de mudar; no físico, não é. Não sei se o pessoal consegue ficar brincando tanto com… porque a gente sempre adora lembrar do Steve Jobs e imagina que o iPhone foi concebido…Yas: De uma vez, praticamente.M1: É, que ele pensou. Acha que pode ter a ver com isso? O designer fica tentando fazer mil tipos de coisa com um software?Yas: Exatamente. Acho que, com o produto, ele realmente tem um ciclo muito maior para ser lançado. No software, esse ciclo é muito encurtado. Eu vejo isso: todos os designers que começam a trabalhar num contexto ágil, ficam um pouco assustados logo no começo. Porque você fala assim: “poxa, em duas semanas, eu não consigo fazer uma solução perfeita”, lógico que não consegue, não é para fazer. Eu acho que muda muito o paradigma do que você está fazendo. E quando você começa a falar: “não estou fazendo a solução, estou testando a hipótese que tenho no momento”, muda muito esse jogo.M1: Então, você veja, dá um problema até de reputação ali, o cara já fica achando que a reputação dele está em jogo, porque ele vai lançar alguma coisa que, talvez, não vai ser tão legal ou bom.Yas: E claro que – acho que até a Cecília pode falar isso – isso também vem do negócio. Então, não adianta o designer falar: “olha, isso é só uma hipótese, estou testando”, se o negócio também exige dele a solução perfeita. Você cria ali um ambiente que, realmente, não favorece.M1: Isso acontece com o negócio em si.Cecília: Acredita? Bom, esse é o nosso grande desafio hoje: convencer e mostrar esse cenário para o negócio, e catequizar as pessoas de que nós não precisamos, hoje, de um produto no seu estado ótimo, uma solução perfeita, enfim; que a gente consegue, de fato, ir testando hipóteses e incrementando um produto até que ele, de fato, seja aquilo que… é porque eu acho que a gente parou de idealizar um ponto, um estágio a longo prazo, em que a gente atingiria algum resultado e alguma solução, para, de fato, nessas duas semanas – como a Yas colocou – a gente já conseguir gerar algum valor e atender alguma dor, é um ciclo curto. Então, acho que é esse o desafio hoje. A gente já consegue entender isso, mas tangibilizar isso também para o negócio.M1: Então, me colocando no lugar das grandes empresas, o que eu percebo? Elas têm muito mais a perder, na visão delas, do ponto de vista de imagem, do que startups, por exemplo. Eu acho que isso acaba sendo um pouco de muleta, entende? Porque elas ficam sempre pensando assim: “se eu lançar essa versão, eles vão atrelar a minha imagem, já sou uma empresa de 20, 30 anos de mercado”. Então, acho que isso é um problema sério.Felipe: Acho que isso acontece muito mesmo, de você já ter algo estabelecido, já ter algo solidificado, que você tem muito mais apego e medo de que aquilo ali se destrua por uma hipótese que possa pivotar alguma realidade que você já conhece, e isso desconstruir sua imagem. Mas eu queria só fazer um comentário, achei interessante o que a Yas falou: ela trouxe para a ótica do designer, e da formação do designer, que faz com que a gente já tente partir da solução, e não chegar na solução. E aí a Cecília também comentou que isso é uma cultura que também está sendo transformada, na ótica do negócio. Olhando para esses dois paralelos, quem está construindo um produto ponto a mão na massa – o designer, os desenvolvedores – e também olhando na ótica do negócio, que solicita a solução, e essa dificuldade de formular hipóteses, eu lembrei de alguma interação que eu tive, recente, com um cliente, em que eu percebo que tem muito a ver com isso. A startup, o primeiro ponto que eu acho corrobora com o que a Yas falou: eles nem têm tanto, talvez, domínio do negócio; e o fato de não ter tanto domínio do negócio que ele vai se aventurar, facilita também a você ser um pouco mais maluco na formulação de hipóteses.M1: Eles nem têm muita opção, tem que ser desse jeito mesmo.Felipe: Eles estão desbravando aquele mundo ainda. E essa interação que eu tive com um cliente, eu percebi que, para tentar continuar esse caminho sólido que eles já têm naquele business, acaba que vai se formando uma equipe que já tem vivência naquilo. E aí, eu percebo que a equipe tem dificuldade de falar: “mas espera aí, vamos fazer diferente, vamos testar isso, vamos testar aquilo outro”. A gente sempre percebe que é assim: “espera aí, de onde eu vim já era assim”, então é sempre uma tendência de reconstruir o status quo: “já era assim. Você não pode lançar um produto que falta isso, porque de onde eu venho, isso aqui era o mínimo”, mas quem disse que de onde você veio é a referência? Então, eu vejo muito que grandes empresas têm essa mentalidade de trazer a experiência já arraigada nas pessoas, para construir produtos baseados em experiências anteriores – aí você não testa hipótese, não faz nada novo.M1: Sabe uma coisa? Acho que cheguei a comentar isso em algum podcast: parece que as pessoas, verdadeiramente, no fundo, não acreditam que aquele é um problema complexo e que vai ter que resolver ali em sucessivas interações, aprendendo.Yas: Nossa, quantas vezes eu já ouvi: “não, mas eu sei que tem que ser assim mesmo”? Aí eu falo: “ai meu Deus, está bom, então”.M1: Acho que isso é mais profundo do que parece, porque parece que é quase um fracasso – igual você comentou – ainda mais em empresa tradicional que, supostamente, já conhece do negócio dela há anos. Aí ela vai lançar alguma coisa digital para ajudar, aí ela pensa: “cara, mas eu conheço meu negócio, com certeza eu sei o que precisa”. Então, eu acho que falta uma visão tanto de humildade, quanto de entendimento de que o mundo é um mundo complexo, que você tem que, realmente, interagir e fazer experimentação.Felipe: E adiciona aí também um pouco de coragem, porque você tem coragem de experimentar.Yas: Ainda adiciono mais uma: uma vulnerabilidade de você falar: “eu não sei”, porque acho que a maioria não gosta de dizer: “não tenho certeza se essa é a melhor opção”.Cecília: Eu adiciono também uma outra coisa, que acho que é também muito importante, que é a empatia. Eu li num livro – inclusive, chamado de Product Discovery – que fala justamente isso: a burocracia, os processos e as ressalvas desses caras que estão aí já há algum tempo construindo esses domínios sobre o próprio negócio, e eles têm a razão de ser – toda essa burocracia é explica, é natural…M1: Existe por um motivo.Cecília: Exato, ela existe por algum motivo. Então, a gente tem que ter empatia de entender que esse é o negócio, que o cara já está aí há muitos anos construindo, e tentar, de alguma forma, convencê-lo de que a incerteza, agora, é uma certeza, e de que a gente ser humilde suficiente, saber falar que não sei, e, de fato, ir construindo essas pequenas certezas com eles. É um processo difícil, mas que a gente tem que desconstruir e começar a construir novamente.M1: Então, é bacana, que você vê: a gente sempre volta lá para as pessoas, para a estrutura organizacional, para como a liderança se comporta. Resumindo o que vocês disseram: no fundo, a gente está falando de quê? Desde a formação de cada um, onde ele aprende que tem que dar uma solução, até o líder, que aprende que ele é o cara que sabe das respostas todas – então, ele tem que saber o que vai ser feito – até a empresa, que não pode correr risco ou demonstrar fragilidade; só que aí, essa mesma empresa decide ser ágil – isso que é o curioso. Mas aí começa a pergunta de sempre: qual é o primeiro passo para isso? Como começa isso?Yas: Eu acho que a gente consegue, com os nossos clientes, ajudar muito nessa fase de product discovery, porque a gente chega com essa cabeça questionadora de falar: “mas precisa ser assim mesmo?”. Eu entendi, é legal, funciona bem assim, mas e se a gente fizesse desse outro jeito? Às vezes, a gente não consegue mudar coisas muito grandes, mas uma pequena mudança que a gente consegue falar: “vamos testar”, e a gente testa e aprende, e mostra o resultado desse aprendizado o mais rápido possível, eles já despertam e falam: “nossa, realmente, acho que tem coisa aí que, se eu me desse a chance de usar hipóteses e não-certezas, talvez eu consiga chegar em algo mais legal ainda”.Felipe: E essa relação é legal, Yas, porque, muitas das vezes, o nosso time que vai apoiar o cliente cria uma relação legal, porque a gente não tem apego, a gente não tem amor pela realidade atual. Então, a gente se comporta mais como um startup, é mais fácil a gente ficar questionando.M1: Não tem nem vínculo emocional. Você sabe que uma coisa boa de algumas ferramentas de design thinking é isso: quando você iguala todo mundo ali e torna o ambiente mais lúdico… eu sempre falo isso para os clientes. Eu sempre brinco, como eu sou engenheiro, eu sei exatamente como um engenheiro vai olhar para aquilo ali e vai falar: “que palhaçada”.Yas: Colar post-it.M1: Vamos lá fazer logo esse produto. Só que o ambiente mais lúdico faz com que as pessoas colaborem mais e contribuam com conhecimento, não a partir da posição – aí você tem mais chance de desafiar a realidade.Yas: E faz esse ambiente seguro que a gente está falando, onde, nesse ambiente seguro, é ok você estar errado e é ok você não sabe – que eu acho que é o que, realmente, é poderoso e faz as pessoas testarem e experimentarem.M1: Sabe um ponto que eu acho também? Aí talvez tenha a ver até com arquitetura, Felipão, mas é assim: o pessoal também usa muito pouco de lançar versão para uma comunidade menor, testar com algum grupo beta antes, engajar alguém. Pensa bem: se uma empresa tem não sei quantos mil clientes, aí você lança – imagina a gente como consumidor – a primeira versão mais ou menos, a gente já olha para aquilo e fala: “o que é isso? Olha o que os caras lançaram”. Mas o pessoal parece que – é o que eu falo – usa muito a muleta, e aí não usa alternativas assim, vocês não acham?Felipe: Eu vou até, se me permite, fazer uma pequena correção: eu acho que as grandes corporações tradicionais ainda usam muito pouco. E aí você falou sobre a inveja que se tem dos startups e das narrativas digitais; essas, sim, usam muito. Se você pega um Facebook, um Instagram, o tanto de teste AB que fazem, o tanto de teste canário que fazem. Em outros podcasts, a gente já conceituou: o teste AB é quando você põe duas versões para públicos diferentes, e avaliar qual que converte mais; o teste canário, que é pôr uma versão que vai ser muito disruptiva para uma parcela menor daquela sua população de usuários, de forma que, se algo der errado, você perde só uma parcela e não perde toda a sua base. Então, eu acho que Facebook, Instagram, Spotify fazem isso com muita frequência; mas, realmente, as grandes corporações ainda estão engatinhando nessa abordagem.M1: As que nasceram digitais já fazem isso muito; as que tentam ficar digitais ainda têm esse obstáculo.Felipe: Exato. E se você pensar assim: “eu tenho meu site aqui, tenho o meu sistema que eu já sei que funciona, eu vou começar a criar um distúrbio tentando colocar duas versões no ar, isso vai causar confusão”. Eu já ouvi isso dentro de um cliente: “mas se eu colocar duas versões diferentes no ar para fazer esse teste, eu vou causar uma confusão nos meus usuários”, “não, querido, você vai testar uma hipótese de qual das duas soluções atende melhor o seu usuário”.Cecília: Eu li um artigo que falava sobre isso, comparando o teste fora do escritório das grandes corporações e dos startups, que antes existiam as versões alfa e beta, mas que tinham justamente o propósito de detectar bugs. E hoje, a gente muito mais inclui feedbacks e ciclos de correção de rota mesmo, de adaptação…M1: Você não tinha tanta dúvida se era bom ou ruim na sua proposta de valor, você (inint) [00:15:27]…Felipe: Se funcionava ou não.M1: … de queimar o filme com o produto. Era mais isso, de queimar um filme (inint) [00:15:32] qualidade, do que, provavelmente, checar: “isso serve para alguma coisa mesmo?”, não era bem isso.Cecília: Exatamente.M1: Queria perguntar o seguinte. Acho que esse começo já foi interessante, que a gente sentou que existe, como sempre, um aspecto cultural, um aspecto de mindset e de encarar isso como outro tipo de problema. Mas do ponto de vista de técnica, não sendo muito prescritivo – porque a gente nem acredita nisso – mas quando fala em product discovery e técnicas, como é que isso se desenrola, então, ao longo de um ciclo de vida de projeto? Para quem está ouvindo a gente, como essa disciplina passa a existir durante um ciclo de vida de um projeto que não é mais projeto – durante o ciclo de vida do produto.Cecília: Mais uma vez, vou colocar o que não é uma certeza, mas eu acho que é a grande aposta, é a gente começar tirando um pouco do vício da gente pensar em soluções – como a gente já levantou – e ir encarando mais e entender melhor o problema de fato. Então, quando a gente vai desmistificar essa construção de uma solução, é, de fato, para a gente entender qual é a necessidade e a dor por trás daquela demanda. Então, tem algumas formas de a gente questionar mais o cliente, por exemplo, entender qual é a dor e o que ele busca alcançar com aquilo, qual é o propósito que se busca, e implementar aquela solução que vai vir a ser construída.M1: Então, a primeira coisa bem clara é não aceitar já um pedido de uma solução. Na verdade, estar junto e entendendo o problema.Cecília: Exato. A gente pode até ouvir o que o cliente, por exemplo, entende como uma possível solução, dar essa devida atenção ao que ele acredita que seja uma solução, mas com a cabeça entendendo que aquela é só uma hipótese – e talvez já conscientizá-lo de que aquilo é só uma das hipóteses que a gente pode levantar, validar, testar, enfim.Yas: Para entender melhor esse problema, que é o que a Cecília está defendendo antes de partir para a solução, a gente defende muito que se faça pesquisa, que você vá sentir, de fato, o ambiente, e sair fora do escritório. Porque se estou trabalhando com um problema que está acontecendo, sei lá, numa mina, eu tenho que ir lá, tenho que conversar com essas pessoas, tenho que fazer o mínimo ali de pesquisa, de processo de empatia com essas pessoas, para tentar emergir esses outros aspectos do problema que, talvez, a gente não esteja considerando. É o sentir que a gente sempre fala.M1: O sentir é de verdade.Yas: Às vezes, sentir na própria pele mesmo, literalmente.M1: Senão, você não cria empatia.Yas: Mas aí também, eu acho que a gente tem que tomar cuidado nessa hora de falar de pesquisa, para a pesquisa não se desenrolar por muito tempo. Porque é uma coisa que eu vejo: às vezes, os clientes associam mais pesquisa a mais assertividade da minha solução.M1: Confunde. Ao invés de ser: “eu vou sentir mais ou menos o que está acontecendo para elaborar uma hipótese”, a pesquisa vira: “eu tenho que pesquisar tudo o que acontece”. Ou seja, a gente sempre cai no raciocínio… por isso que eu falo que é o modelo mental. A gente sempre cai na cilada de, no fundo, acreditar que aquilo é um problema complicado, e não complexo, e que, então, se eu pensar muito, acabo resolvendo ele. É incrível isso.Yas: Exatamente. Tem um aspecto que eu acho que é legal da gente falar nesse negócio da hipótese, é que ela é muito perecível. Se eu sentir, e levantei essas hipóteses agora, eu tenho que, de alguma forma rápida, testar elas. Se eu esperar muitos ciclos, se eu ficar me delongando em dois meses de pesquisa, aquela hipótese já se invalidou justamente porque eu não consegui testar.M1: E aí tem uma coisa – que acho que vou fazer até um (inint) [00:19:11] sobre isso – eu fico brincando comparando com o mito da caverna do Platão, que os caras ficam dentro da caverna vendo a sombra do mundo, e não o mundo. Tem equipes de software que são assim – a equipe fica dentro da caverna, e o mundo está acontecendo lá fora. A primeira recomendação muito clara nossa, o primeiro princípio é o seguinte: uma equipe que fica dentro de casa o tempo todo, possivelmente, não está sentindo, não está criando empatia, e não vai contribuir tanto para o ciclo de vida para melhorar aquele produto. É isso.Yas: Provavelmente, ela está se embasando no que ela já conhece previamente, das coisas que ela já fez.M1: Não sei se é polêmico, mas eu queria ver, principalmente, da Cecília, que é PO, e papel do PO no estudo? O PO é aquele mágico que sabe tudo? Eu falo que, no mercado hoje, acho tão interessante isso, porque tem gente que acredita quase nisso mesmo. Quem prioriza? É o PO. Quem sabe gerar valor? É o PO. Quem não sei o quê? É o PO. Falei: “cara, o PO faz tudo”. A gente está falando que ninguém sabe direito as coisas: qual é o papel do PO, no final das contas? E ele consegue fazer essa mágica toda? O que você diz sobre o PO?Cecília: É um desafio, claro. Eu acho que a gente pontuou uma coisa bem legal do que o PO não é ou não faz, que é tirar pedidos, como a gente já comentou aqui – a gente não pode ir ao cliente e fazer essa pesquisa já buscando a solução. Ouvir o que ele tem a dizer, de fato, mas tentar entender, como eu já disse, o problema. Então, talvez seja o momento de a gente pensar num cara questionador, de querer entender mesmo e investigar ativos na causa do problema, na demanda que está sendo levantada. É um cara que pensa qual é a função e o trabalho a ser feito por aquele produto que está sendo construído, ou por aquela solução. E talvez, a pessoa que tem mais essa função de catequizar as pessoas ao redor – os clientes, os usuários – em virar esse mindset, virar essa mentalidade, como a gente está comentando aqui, para entender que o valor pode ser gerado em ciclos curtos, que o feedback vai ser importante na construção desse…M1: Mas não é só ele que sabe das coisas.Cecília: Claro que não.M1: Sabe que eu fico ouvindo isso? Hoje em dia, está muito na moda falar dos coachs, e é engraçado…Cecília: Bem polêmico.M1: Eu fico brincando, porque uma vez – eu não resisto – eu estava no congresso, uns dois anos atrás, e todo mundo era (inint) [00:21:45] coach, todo mundo do congresso. E aí quase que eu levantei a mão e falei assim: “mas quem vai fazer as coisas, já que só tem coach aqui?”. Todo mundo se apresentava como (inint) [00:21:56] coach. Mas o que eu acho interessante é que me parece que, se tem alguém em posição de influenciar muito na mudança de mindset, é o PO, nesse sentido de que ele está numa condição ali de falar o seguinte: “vamos simplificar isso aqui, vamos fazer um experimento, vamos botar, primeiro, tal coisa no ar e ver o que acontece?”. Ele está numa condição boa, por causa do papel dele.Cecília: Exatamente. Eu acho que é um papel pivô entre os dois lados da moeda – é o cara que entende os dois lados, que tem empatia pelos dois lados – e consegue, de fato, trazer a mentalidade de uma coisa para outra, trazer uma mudança de visão entre um lado e outro. É, de fato, o que faz o jogo de cintura entre essas duas partes. Então, com certeza, é um papel coringa nessa (inint) [00:22:50].M1: Então, mas aí, uma outra questão, Yas, olha só: a gente sofreu um pouquinho isso na pele na DTI. Existe também o seguinte, muito cliente pode estar pensando assim: “mas e quando eu faço um design sprint, até onde vai o design sprint?”. Porque existe essa descoberta durante o tempo todo, contínua, priorização, você ir em campo; mas existem momentos em que você se reúne e faz umas dinâmicas mais intensas para sair com algum protótipo, que é o que seria, de forma grosseira, um design sprint. Só que a gente já observou muito, aqui – a gente já incorreu nesse pecado no passado – de certos designs prints acabarem tentando avançar tanto, que dão uma impressão quase de que você já sabe a solução. O que você diria sobre isso? Quando que executa, quantas vezes que executa um design sprint? Como o design sprint se encaixa nessa coisa do cara também ter que ir em campo e ter pesquisa?Yas: Acho que a gente aprendeu muito ao longo dos anos aqui, fazendo sei lá quantas dezenas de design sprints. Acho que, de fato, já teve momentos em que a gente abordou problemas grandes demais em designs sprints e deu essa sensação de que a gente estava ali fazendo um discovery para um produto de um ano, dois anos. Mas o que a gente foi aprendendo e aperfeiçoando – e sentiu uma melhora muito grande – é fazer design sprints com problemas bem contidos, problemas que vão ser abordados no próximo trimestre, no máximo. E ao fim desse trimestre, precisa ser feito um novo discovery, e aí um novo design sprint. Acho que o que foi legal do design sprint é que ele tangibilizou como eu faço esse product discovery de forma ágil e encaixado ao desenvolvimento ágil. Que é o que eu disse: às vezes, você pode cair no erro de querer fazer uma parte de discovery de dois meses, para depois entrar em ciclos ágeis de desenvolvimento. E aí, me parecem extremamente incoerentes essas duas coisas. O discovery tem que ser tão ágil quanto se espera desenvolver aquilo.M1: Sim, você pode revisitar toda hora, pode fazer mais ciclos de discovery, não tem uma prescrição obrigatória.Yas: E, de novo: a gente sempre cai nos mesmos vícios. Não acreditar que aquilo que foi definido do design sprint também está numa pedra. Quantas vezes a gente já não questionou coisas duas, três semanas depois, para ouvir: “não, mas no design sprint a gente falou que tinha que ser assim” – falou, mas a gente aprendeu outras coisas até lá, a gente mudou de ideia, e tudo bem.M1: Você teve uma experiência interessante. Lembra, Felipão, de um design sprint que realmente gerou muito valor?Felipe: De qual você está falando? Conduzi alguns.M1: Não, porque eu lembro claramente disso. A gente aqui, na DT, é muito autocrítico, e eu falo assim: é muito fácil sempre cair em certos pecados – ou seja, parece que o mundo puxa a gente para certas coisas. Então, é fácil a gente aqui, também, ficar investindo demais em arquitetura no começo, não gerar débito técnico e não conseguir convencer o cliente disso, e ficar alguns meses investindo em arquitetura – que é um erro que a gente não consegue testar nenhum tipo de hipótese. Então, é fácil avançar num design sprint que, de fato, não vai, em curto prazo, reduzir algum risco ou alguma incerteza grande, entendeu? E eu acho que existe uma disciplina ali, que todo mundo tem que ter, que o próprio discovery, no fundo, é o quê? Eu quero ter evidências reais de que estou no caminho certo – o norte sempre é esse. Ou seja, seja o que for, eu preciso saber que estou num caminho certo para a gente não gastar um tanto de dinheiro à toa.Felipe: Eu fiz um look-up aqui na memória, e me ocorreu – provavelmente, é o que você está se referindo. Realmente, eu conduzi um design sprint para um cliente nosso da área da saúde, e que, no início do design sprint, todas essas questões e vieses, que a Cecília e a Yas comentaram, começaram a surgir, que é tentar abordar algo mais grandioso, talvez um produto que fosse uma visão de um ano. E aí, utilizando as ferramentas, tentando ser bem racional e pé no chão, a gente tentou ir reduzindo esse escopo. Então, vamos dizer que eles queriam atacar cinco, seis processos diferentes; a gente conseguiu ir conduzindo para atacar um processo, que seria só a recepção do cliente ali na… como é o nome daquela etapa de autorização?Yas: Triagem?Felipe: De autorização, exatamente.M1: De convênio.Felipe: É, do convênio. Então, eu disse: “vamos focar só nessa etapa”. E aí, um outro viés que começou a surgir é a percepção de quem já trabalhava naquele assunto: “espera aí, o que tem legislação…” – realmente, tem algumas situações que a gente tem restrições legais, que eu já ouso dizer que, às vezes, a gente já pode começar a desafiar algumas restrições legais, porque, às vezes, um produto e uma nova forma de pensar podem reafirmar ou revisar algumas questões legais. Então, eu acho que nem isso deveria ser uma restrição tão forte. Mas voltando, então, à linha da concepção desse produto: começaram a tentar colocar essas restrições do status quo, de como era: “não, mas isso aqui a gente tem que pegar a informação A, B, C, D, E, F”, e aí virou um formulário enorme, que parecia, de novo, aquele sistema de padaria, e não algo que estava realmente transformando digitalmente. Eu sei que a gente foi lapidando essa ideia, a ponto de parar um pouco do design sprint e tentar trazer, realmente, os usuários – que eu acho que é uma falha que também a gente incorre ou incorreu no passado, em alguns dos nossos designs sprints, que era ter as pessoas que estão fazendo a gestão do negócio, mas não quem está de fato utilizando e sendo transformado por aquele produto dentro da sala. Então, trouxemos as pessoas de fato – pessoas que trabalham nos hospitais. Aí quando eles começaram a falar, a gente descobriu que, na verdade, a primeira parte desse produto precisava de um campo – ao invés de 20, 30, era um campo, era a carteirinha do convênio. E aí você conseguia fazer a autorização. Aí fizemos, terminamos o design sprint, fizemos um protótipo, construímos a primeira tela…M1: E é curioso, ou seja: era uma autorização para um cenário mais simples, só que já dava muito valor, não dava?Felipe: Exatamente.M1: Que é a dificuldade. Alguém fala: “mas vai fazer só isso?”, esse só isso já retornou bastante valor.Felipe: E o só isso, quando chegou lá na ponta, no usuário, você imagina o tanto que facilitou a vida de quem colhia. Falava assim: “isso aqui, realmente, transformou, eu agilizei muito o processo”. E como era um parceiro do hospital, o próprio hospital, depois, falou assim: “eu quero que façam o que fizeram com esse sistema, com o nosso também, que é muito mais moroso”. Então, esse gerou valor real.M1: Olha que curioso, vê como as coisas são todas ligadas. Eu fico falando que a transformação é maior, por que as pessoas não acreditam no product discovery, de fazer aos pouquinhos? Na minha visão também, porque a visão que eles têm de TI é algo que, se der certo, vai entregar alguma coisa no final, e muito atrasado. É aquela brincadeira que algumas pessoas falam: TI é Tempo Indeterminado. Então, por isso que a gente insiste demais com os clientes, a gente tem que procurar a cadência, porque se você está entregando com cadência sempre, você acredita que pode trilhar um caminho de product discovery, porque vou estar sempre entregando com cadência. Agora, se eu estou acostumado que, um dia, me entregam alguma coisa, o que eu faço? Eu tenho que pedir tudo que eu puder pedir ali, e tenta adivinhar tudo antes. Concordam?Yas: Sim, é até um ponto que eu queria trazer: uma outra dificuldade muito grande, que eu vejo, na prática de trabalhar com hipóteses é que, se estou trabalhando com hipóteses, então espera-se que eu vá testá-las, e eu posso estar errada, e tenho que corrigir meu rumo. Esse corrigir meu rumo é uma confusão danada, porque você fala assim: “mas você vai remexer naquela feature de novo? Você já entregou”.M1: É considerado desperdício. Esse é um problema seríssimo. Você vê como o problema é profundo e estrutural, porque a maior parte das empresas, quando contratam (inint) [00:30:55], as empresas estão acostumadas a medir eficiência de uma forma tal, que você revisitar uma hipótese e pivotar ou mudar um caminho, dependendo do jeito que a empresa trabalha, aquilo é desperdício total.Cecília: Mesmo que seja para melhorar, que seja para aprimorar alguma coisa, para evoluir, eles ainda acreditam que é um retrabalho, que é um retrocesso de alguma forma.M1: E aí, a pessoa compara aquilo com alguma coisa que nunca deu certo na vida, e que não existe, e fala: “se tivesse feito de um tal jeito, que ninguém sabe qual é, eu não teria tido esse desperdício”, e não assim: “na verdade, eu gastei menos aqui para descobrir”. Imagina esse exemplo que o Felipão deu: não se descobriu rapidamente que só aquele campo era suficiente para várias situações, mas, idealmente, se descobriria que mais uma coisinha ali já resolveria aquilo e pronto.Felipe: Aí é o incremento real.M1: É o incentivo. Ou então: “vamos mudar isso aqui e fazer”, é muito difícil. Outra coisa que eu acho que influencia muito também – estou querendo mais é mostrar que você tem que olhar, realmente, de forma sistêmica – porque não adianta você falar: “você tem que fazer product discovery, testar hipótese e etc.”, se, desde a equipe não tiver esse mindset, até a empresa aceitar pivotar e desperdício, a equipe realmente trabalhar com cadência; tudo tem que ser condição para você conseguir fazer product discovery de verdade. Outra coisa é (inint) [00:32:16], porque se você não tiver tudo automatizado, não conseguir dar deploy fácil, como vai fazer?Felipe: Não conseguir recuperar rapidamente de uma falha ou de uma hipótese mal-sucedida. Realmente, se você não tiver estrutura que te habilite, uma estrutura habilitadora, você não consegue evoluir um produto dessa forma – de forma ágil, com testes AB, com hipóteses, enfim. Eu queria pegar o seu chapéu de host por um minuto e fazer uma pergunta para a Cecília e para a Yas, até…M1: Só uma, por favor.Felipe: Muito obrigado. Até apoiado nesse caso que eu contei. Porque, naquele momento, eu acreditei bastante nas ferramentas do design thinking, no que o design sprint prega, de realmente ter o usuário. Eu queria ouvir, das experiências que vocês já tiveram, se, em algum momento, a coisa não passa por um viés mais burocrático e não tem uma crença real naquelas ferramentas, de chamar o usuário para vir para dentro de fato, utilizar processos de construção rápida – tem até aquele oito… como se chama?Yas: Crazy eights.Felipe: É o crazy eights, de você realmente fazer alguns desenhos bem rápidos para tentar testar – bem low tech – alguma hipótese. O quanto que, às vezes, dentro de um processo desse de design de descoberta do produto, isso não passa a ser olhado assim: “não, isso aí está no método, mas isso aí é firula, vamos ser mais práticos aqui”? O quanto que isso não acontece? Porque, nesse momento, quando eu parei e falei assim: “gente, nós estamos tentando abraçar o mundo, vou me apegar à ferramenta”, e acabou tendo sucesso no final das contas. Vocês sentem isso? A galera olha para o método e fala assim: “não, isso aí é firula, isso aí é para os startups, isso aí não funciona para a gente”, vocês sentem isso?Yas: Nossa, muitas vezes. Já tive vários casos em que eu senti que a gente estava lá fazendo as ferramentas, e, de verdade, as pessoas estavam só expondo o que elas sempre acharam num formato de ferramenta com post-it, e não, de fato ali, abertas para a ferramenta e dispostas a serem questionadas e a questionar. E é realmente um grande desafio, porque a ferramenta não é mágica, não é só ela, não é só o processo que vai garantir que dali sai alguma coisa legal. Todo o envolvimento daquelas pessoas que estão lá, de realmente comprarem o processo e para o que aquilo significa, e estarem realmente abertas, que faz um resultado legal. E o que a gente tenta fazer, de novo: a gente, como outsiders, como pessoas sem apego àqueles produtos, àqueles processos, àquelas formas burocráticas, a gente tenta sempre dar aquelas cutucadas e questionadas: “você já pensou assim?”. Às vezes, a gente fala umas besteiras, mas é de propósito, mas acho que ninguém tem… quando estão, ali na sala, pessoas que estão às vezes há 20, 30 anos trabalhando com o mesmo processo, eu entendo elas, eu fico empática em relação a elas também. Não é fácil elas falarem uma coisa que pode ser percebida como besteira. Mas eu, como facilitadora, consigo ter essa imunidade de fazer perguntas bestas mesmo, e questionar coisas que parecem inquestionáveis. E aí é legal, que quando isso começa, as pessoas ganham aquela segurança, e aí você vê que a coisa começa a fluir mais legal. Mas a ferramenta em si não vai resolver nada. Se a pessoa entrar lá para fazer aquilo: “vou passar para um design sprint, porque, burocraticamente, essa é a primeira etapa do product discovery”, não resolve, não é só isso.Felipe: E aí você falou a palavra-chave: o (inint) [00:35:54] design, ou quem estiver ali conduzindo a dinâmica, é o facilitador. Ele vai fazer o que é a ideia, energia e hipótese, através da ferramenta, mas ele não vai fazer nada sozinho, a ferramenta não vai fazer nada sozinha, e as pessoas que estão lá também não vão conseguir fazer nada sozinhas. E aí me lembra um outro design sprint que eu conduzi também, que na hora que estava no meio, a gente utilizando uma ferramenta para traçar a jornada ideal, a coisa não andava porque era muita discussão, e uma das envolvidas falou assim: “estou achando…” (inint) [00:36:24].M1: (inint) [00:36:25] tenso.Felipe: Começou a ficar tenso, me chamou no canto e falou assim: “estou achando que a gente está perdendo tempo, o pessoal não desenvolve”, aí eu falei assim: “fica calma, as discussões estão sendo produtivas, porque elas estão afunilando, estão chegando, estão convergindo”, “mas não está surgindo post-it ali no quadro”…M1: Precisamos de tantos post-it por minuto.Felipe: Aí eu falei assim: “olha, acredita na dinâmica e acredita no método. Tenho certeza que, no final, alguma coisa vai surgir – eu não sei o quê, mas alguma coisa vai surgir”, e aí passou o final da dinâmica. Ela veio, me deu um abraço e falou assim: “cara, eu vou repetir isso para todo mundo agora: acredita no método, porque realmente sai”.Cecília: Acho que isso até transcende um pouco essa questão das hipóteses de um design sprint, por exemplo, mas isso também tange outros aspectos do nosso dia-a-dia, como, por exemplo, os nossos ritos – e numa mission command, por exemplo, a gente levantar OKRs e alinhar o nosso desenvolvimento às estratégias de negócio, por exemplo. E, em tudo isso, eu vejo e sinto, em algumas partes, de algumas pessoas – não podemos colocar que é geral – num âmbito generalista, acontece essa visão de que isso é um clichê. Mas eu acho que uma das coisas que as pessoas conseguem entender e enxergar melhor o resultado e a eficiência disso que a gente faz, é quando elas veem resultado mesmo, de quando a gente faz os ritos…M1: Marcando o ciclo virtuoso.Cecília: Exatamente. Então, ciclos curtos. Nossas sprints, ou ciclos curtos de OKR, por exemplo, mesmo que, a princípio, eles não consigam entender e simpatizar com aquilo, mas quando as coisas começam a melhorar – e, tendenciosamente, elas vão melhorando naturalmente – as pessoas começam a acreditar nisso.M1: Legal o que você faz, tem muito a ver com a forma como a gente acredita que o processo de mudança acontece. Você vai tangenciando o que é possível, vai arrendando aos pouquinhos, quando você vai ver, você tem um time. Eu acho importante falar isso, porque quem escuta isso pode ficar até assustado – tanta dificuldade em fazer product discovery que (inint) [00:38:40] fala assim: “não vou conseguir fazer”. Mas é aquilo que a gente sempre fala – recomendamos o episódio The Fucking First Step – se você começa com um time que realmente começa com esse espírito, e que mesmo errando – a gente fala muito isso aqui na DTI – mesmo que você defina os OKRs errados, mas se você estiver perseguindo os OKRs, e no próximo ciclo, aprender a definir muito (inint) [00:39:02], definir um objetivo muito genérico, é melhor partir de alguma coisa do que…Cecília: Do que não ter.M1: … do que não começar. Tem algum comentário adicional: Nós já estamos caminhando para o final. Alguém esqueceu de alguma dimensão ou não?Yas: Acho que a gente falou bem de tudo, quais as dificuldades de se trabalhar com hipótese. O que eu acho legal é que o Henrique, um designer aqui da DTI, fez um encontro da nossa guilda recentemente, onde ele fez um material super legal sobre como validar essas hipóteses – porque a gente precisa ter ferramentas para isso também – e ele falou uma coisa que ficou na minha cabeça, e eu acho que é válido falar assim: é muito chato ter certeza. Nem é legal, não sei porque as pessoas querem tanto ter certeza. Porque é tão melhor mesmo quando você sente o time está ali aprendendo, que ele tem esse espírito de explorar, de questionar, de colocar para a produção e ver o resultado. E tão mais gostoso e melhor de trabalhar, que eu não sei porque existe essa vontade tão grande…M1: De ter certeza.Yas: … de morrer abraçado com aquela ideia, com aquela solução: “eu tenho certeza”.Felipe: Tem tudo a ver com isso. Eu terminaria com uma frase que tem naquele livro Sense and Respond – que a gente gosta pouco – que é justamente esse ciclo de concepção, o início do ciclo, que é: estabeleça uma hipótese, construa algo muito rápido, coloque no mercado e assuma que vai dar errado. Essa quebra de paradigma – assuma que vai dar errado – é a quebra dessa certeza. Se você já coloca algo assumindo a possibilidade grande de dar errado, você já começou no caminho certo.M1: Beleza. Eu sempre gosto de fazer uma mini-síntese. Para mim, o que eu entendi nessa conversa com vocês é que o product discovery é tanto um mindset, e mesmo um conjunto de técnicas, que vão ser até trazidas muito pelo PO e pelo designer, pelo líder de (UX) [00:40:53], para poder garantir que aquele produto está gerando valor; mas ele requer uma série de mudanças estruturais e mudanças, inclusive, de como o time se organiza para que ele possa ter cadência e ferramentas de automação. Acho que isso é importante, porque, senão, o que acontece? Alguém ouve isso e fala assim: “beleza, vou contratar um PO, bota aqui no meu time ele executando da mesma forma de sempre, e agora, pronto, nós vamos começar a fazer product discovery”. Se não for um time que consegue trabalhar com cadência, que consegue testar hipóteses, que foi o grande tema nosso aqui, vai continuar não acontecendo nada. Então, pessoal, até o próximo episódio, um abraço a todos.Felipe: Valeu, pessoal.Cecília: Obrigada.Yas: Tchau, gente, foi um prazer.