Como escolher ferramentas que a sua equipa de produto irá realmente utilizar

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros de digitação, pois o robô não está correto 100% do tempo.

Hannah Clark: Rapidamente, sem contar, consegue dizer-me quantos logins utiliza atualmente no trabalho, semanalmente? Se não sabe, faça pausa e tente contar. Aposto que o número é surpreendente. Na verdade, um relatório da CloudZero de 2024 concluiu que o trabalhador médio utiliza atualmente 36 serviços baseados na nuvem por dia, e as equipas de engenharia utilizam o dobro.

Incrível, não é? E aqui está outra coisa surpreendente que provavelmente não o vai surpreender. De acordo com o estudo da CloudZero de 2023, mais de 53% das licenças de SaaS não são utilizadas. Por outras palavras, apesar da necessidade constante da nossa organização de ferramentas que apoiem as nossas operações únicas, estamos a desperdiçar imenso dinheiro em ferramentas que, por alguma razão, simplesmente não se adequam.

O meu convidado de hoje é Moshe Mikanovsky, fundador e principal consultor de produto da Products for Good e coapresentador do podcast Product for Product. Tendo trabalhado em produto e engenharia de software desde 1989, uma das principais áreas de foco de Moshe nos últimos anos tem sido ajudar as equipas de produto a tomar melhores decisões relativamente às ferramentas que escolhem implementar.

É importante referir que Moshe desenvolveu um modelo abrangente para ajudar as organizações a escolher as ferramentas certas para as suas necessidades, aumentando assim a adoção e a produtividade, ao mesmo tempo que reduz os gastos desnecessários. Falamos sobre alguns dos pontos principais do modelo que podem ajudá-lo a escolher ferramentas melhores a partir de hoje. Vamos começar.

Bem-vindos de volta ao podcast The CPO Club. Estou hoje aqui com Moshe Mikanovsky. É o fundador e principal consultor de produto da Products for Good.

Moshe, muito obrigada por se juntar a nós hoje.

Moshe Mikanovsky: Obrigado pelo convite, Hannah.

Hannah Clark: Vamos começar da forma habitual. Pode falar-nos um pouco sobre o seu percurso e sobre como chegou onde está hoje?

Moshe Mikanovsky: Sim, comecei como programador de software há muitos anos. Durante os primeiros 20 anos da minha carreira, trabalhei na área de engenharia. Tive a sorte de trabalhar para organizações pequenas. Ou, na realidade, no terreno, a trabalhar com clientes e utilizadores. Por isso, penso que desenvolvi parte da minha empatia pelos utilizadores e pelas suas necessidades.

Depois, após 20 anos, decidi passar para a gestão de produto. É nisso que trabalho há 14 ou 15 anos. Gosto muito de o fazer. Gosto de falar sobre gestão de produto. Gosto de ajudar outras pessoas a desenvolver produtos. E de ver o que existe, o que funciona, o que não funciona e aprender novas metodologias.

Por isso, tudo o que diz respeito a produto faz parte daquilo que me faz levantar de manhã.

Hannah Clark: Está entre pessoas que o compreendem.

Hoje vamos falar sobre algo que penso interessar a toda a gente: ferramentas. Como podem as equipas de produto tomar melhores decisões ao selecionar ferramentas para as suas organizações? É uma preocupação constante. E esta é também uma das suas principais áreas de especialização. O que o inspirou inicialmente a criar o seu modelo de seleção de produtos, de que falaremos dentro de momentos?

Moshe Mikanovsky: Sim. Tenho um podcast que coproduzo há quatro anos com o meu amigo Matt Green. Chama-se The Product for Product.

No podcast, abordamos essencialmente as ferramentas utilizadas pelos profissionais de produto. Sempre foi um interesse de ambos, embora a partir de perspetivas diferentes. Para o Matt, surgiu quando passou para a gestão de produto; para mim, resulta de ter experimentado diferentes produtos no passado e de ter escolhido produtos porque ninguém os escolheu por mim e eu tinha de fazer o trabalho.

É sempre muito interessante ver o que está disponível. É isso que fazemos no podcast. E, ao longo da gravação de episódios sobre diferentes temas e diferentes produtos temáticos, percebi que existem algumas semelhanças entre as razões pelas quais as pessoas utilizam produtos específicos, o que gostam neles e aquilo de que não gostam.

E coisas desse género. Entrevistávamos sempre utilizadores dos produtos, a menos que se tratasse de uma startup. Nesse caso, não há muitos utilizadores, por isso convidamos o fundador, mas na maioria dos casos entrevistamos utilizadores. Assim, eles já têm conhecimento e uma perspetiva sobre a forma como o produto é utilizado, o que funciona e o que não funciona. A partir daí, reuni muitos desses motivos e aspetos a procurar, o que me levou a colocá-los todos num único modelo que gosto de partilhar com as pessoas.

Hannah Clark: Na sua experiência, se quisermos falar sobre alguns dos erros que as pessoas cometem antes de abordarmos a forma correta de fazer as coisas, ou um modelo para o fazer da melhor maneira para a organização, quais são alguns dos erros mais comuns que as organizações de produto cometem quando escolhem novas ferramentas e a que consequências costumam esses erros conduzir?

Moshe Mikanovsky: Sim, penso que se trata sobretudo da forma como escolhem as ferramentas e de não procurarem uma ferramenta que se adeque melhor à organização. Essa seria a primeira coisa. Mas também não compreendem realmente as ferramentas antes de as escolherem. É algo comum.

Ficamos sempre muito entusiasmados com uma ferramenta nova. Procuramo-la. Vemos as diferentes funcionalidades que pode oferecer. Sentimos, ou pensamos, que irá satisfazer as nossas necessidades, mas, quando começamos a implementá-la, podemos perceber que não é exatamente aquilo que pensávamos. Ou talvez tenhamos analisado apenas a informação de marketing no site do fornecedor, que não nos conta toda a história.

Ou as demonstrações não nos contaram toda a história, ou existem diferentes surpresas que descobrimos ao longo do processo. É isso que vejo muitas vezes: uma ferramenta que não é a mais adequada para a organização e uma compreensão insuficiente de como o produto irá realmente funcionar para ela.

Hannah Clark: Sim, faz sentido.

Muito bem. Então, vamos percorrer o seu processo de seleção. O seu modelo começa por identificar problemas, depois há uma fase de priorização e criação de uma lista restrita e, em seguida, a comparação das ferramentas. Portanto, existe bastante trabalho preliminar antes de chegar efetivamente à comparação.

Porque é que este trabalho preliminar é tão importante antes de começar realmente a comparar funcionalidades?

Moshe Mikanovsky: Penso que é como acontece com qualquer outro produto. Tento abordar quase tudo o que faço como um profissional de produto, depois de tantos anos. Tentei fazer o mesmo com este modelo. Compreender qual é o verdadeiro problema que estamos a tentar resolver é muito importante.

Não queremos criar funcionalidades para uma solução que ninguém irá utilizar. Da mesma forma, não precisamos realmente de funcionalidades específicas se não houver um problema para resolver. O facto de toda a gente fazer algo não significa que também tenha de o fazer, nem que a forma como as outras pessoas o fazem seja adequada ao funcionamento da sua organização.

Por isso, o início do trabalho preliminar, antes de analisar todas as funcionalidades, consiste em compreender quais são os problemas reais que está a tentar resolver e qual é o trabalho, ou o objetivo a cumprir, da sua equipa de produto. É para isso que precisa de escolher essas ferramentas. E depois, quais são as prioridades entre todas essas questões?

Sabemos que, por vezes, não podemos comprar todos os produtos imediatamente. Às vezes, até obter orçamento para um único produto é mais do que aquilo que conseguimos. Por isso, é necessário dar prioridade ao maior problema que temos neste momento. E talvez nem seja sempre um problema: pode ser algo que demora muito tempo a fazer, ou pode haver muita desorganização que precisamos de resolver, seja o que for.

Com base nesse maior problema, devemos dar-lhe prioridade e dizer: está bem, é isto que precisamos realmente de procurar primeiro. Depois, podemos criar quase um roteiro para a escolha dos produtos e para a sua eventual implementação.

Hannah Clark: Está bem, quero falar um pouco sobre algo interessante no processo que utiliza para comparar ferramentas: a filosofia do produto, que é o primeiro critério aqui.

Antes de mais, o que quer dizer com filosofia do produto e porque é que isso é importante? Como se manifestam realmente as diferenças de filosofia e de que forma afetam a adequação das ferramentas a uma organização?

Moshe Mikanovsky: Uma das coisas que notei ao falar com pessoas, e que também resulta da minha própria experiência e da experiência do meu coapresentador Matt, é que não somos iguais na forma como gostamos de trabalhar, na forma como gostamos de comunicar ou naquilo a que damos importância.

É isso que incluo na filosofia. Por exemplo, alguns de nós querem realmente ter um único produto que resolva tudo. Todas as funcionalidades de que precisamos estarão lá. Não precisamos de implementar mais nada. Mas sabemos que, muitas vezes, esses produtos não se aprofundam muito em cada uma dessas funcionalidades; abrangem-nas de forma muito ampla.

Para outras pessoas, a filosofia é: quero o melhor dos melhores para cada problema específico que tenho. Quero que esteja integrado, para que tudo comunique entre si, mas isso também acrescenta complexidade à solução. Este é apenas um exemplo de uma filosofia: quem somos realmente enquanto organização?

Por vezes, é difícil defini-lo se não souber como funciona a sua organização ou quem toma essas decisões, mas é importante procurar esta informação porque o ajudará a identificar um produto específico ou a criar uma lista restrita de produtos. Outra destas filosofias é saber se quer que o produto seja flexível ou determinista.

Alguns produtos dão-lhe a possibilidade de criar qualquer fluxo de trabalho que queira, definir qualquer campo que queira e assim por diante. Mas, por vezes, são muito genéricos, embora flexíveis. Cada organização irá implementá-los de uma forma ligeiramente diferente. Outros produtos da mesma categoria podem ser muito deterministas, dizendo-lhe: não, tem de trabalhar desta forma, porque só o desenvolvemos desta maneira.

Não estou a dizer que um é melhor do que o outro. Por vezes, depende da fase em que a organização se encontra, não tanto da sua antiguidade na criação de um produto, mas da sua maturidade. Por exemplo, se não conhecer uma forma específica de fazer ciclos de desenvolvimento, gerir um backlog e todas essas coisas, e obtiver um produto determinista relativamente a isso, o produto irá ensinar-lhe o processo.

Mas irá ensiná-lo apenas de uma forma, quando existem muitas outras formas de o fazer. Talvez, quando a organização estiver mais madura, se sinta mais confortável a utilizar outro produto que seja muito mais flexível. Estes são alguns dos aspetos que procuro e que fazem parte do modelo, mesmo antes de analisarmos o produto, para perceber qual é a sua cultura, que tipos de produtos são mais adequados para si, entre outros aspetos.

Hannah Clark: Está bem. E, já que falamos de flexibilidade, há outro critério sobre o qual gostaria de o questionar: o fator da necessidade contínua de engenharia. Este é interessante. Como devem as equipas avaliar os recursos de engenharia necessários para integrar diferentes ferramentas e de que forma isso pode estar relacionado com o sucesso a longo prazo desse produto?

Moshe Mikanovsky: Sim, isto também está relacionado com uma espécie de filosofia, a minha filosofia na criação de produtos em geral, tanto na minha própria empresa como quando presto consultoria a outras empresas: os nossos engenheiros devem concentrar-se realmente no valor acrescentado que estamos a criar e não reinventar a roda com coisas que milhões de outros programadores já desenvolveram no passado.

Da mesma forma, quando adiciono funcionalidades ao meu produto, como mensagens na aplicação ou análise de produtos, que já existem nestas ferramentas que temos atualmente, apenas a título de exemplo, não quero realmente que os meus programadores se preocupem com essas coisas. Prefiro que façam uma integração muito simples uma vez e praticamente se esqueçam dela.

Depois, quero dar a mim próprio, enquanto gestor de produto, ou a outras pessoas fora da equipa de engenharia, a capacidade de definir tudo aquilo que for necessário para obter o máximo valor deste produto. No entanto, alguns produtos da mesma categoria, tanto de mensagens na aplicação como de análise de produtos, exigem efetivamente a intervenção contínua de engenheiros, porque, por vezes, é necessário definir eventos a desencadear ou a forma de configurar o aspeto das mensagens na aplicação, entre outras coisas.

Para mim, e mais uma vez isto é algo pessoal, não estou a dizer que é certo ou errado, isso é uma perda de tempo dos programadores. Prefiro que trabalhem no valor que é único para a nossa organização.

Hannah Clark: Muito bem. Falando de valores da empresa e de alguns desses aspetos mais específicos, também mencionou que fatores culturais, como os valores da empresa e os estilos de comunicação, podem afetar a seleção de ferramentas, o que considero muito interessante.

Gostaria de ouvir uma história sobre a forma como isso funciona na prática e sobre como estes elementos menos tangíveis podem influenciar quais das ferramentas conseguem ser bem-sucedidas numa organização.

Moshe Mikanovsky: Sim, claro. Posso dar-lhe o exemplo de um local onde trabalhei e onde tivemos muitas dificuldades com a comunicação assíncrona. Isso incomodava-me bastante, porque trabalhávamos remotamente e seria de esperar que, no trabalho remoto, a comunicação assíncrona fosse uma daquelas coisas que ajudam a colaborar melhor e que evitam a necessidade de reuniões regulares.

Tínhamos de estar constantemente em reuniões regulares para conseguir fazer avançar as coisas. Também optámos por utilizar um sistema de gestão de backlog. Penso que era o Jira, mas, em qualquer um desses sistemas, quando define os seus épicos, por exemplo, num documento do Confluence, e as suas histórias com critérios de aceitação, espera que as pessoas leiam tudo e colaborem através dos comentários, trabalhando em conjunto de forma assíncrona.

Mas simplesmente não funcionou. E sempre que as pessoas me diziam: “Oh, não vi isso”, ou quando abriam o assunto nas reuniões, eu pensava: mas tínhamos tudo isso lá.

Era um problema cultural que estava a afetar a utilidade dos produtos que utilizávamos. Por vezes, sentia que estava a nadar contra a corrente. Tive de fazer uma sessão inteira apenas para lhes explicar o que era a comunicação assíncrona e qual a sua importância. Não me lembro sequer se ajudou ou não.

É disso que estou a falar. É apenas um exemplo de como a sua organização funciona. Uma ferramenta não vai necessariamente resolver esse problema. Uma ferramenta pode ajudá-lo a melhorar a comunicação, se fizer um esforço para a utilizar efetivamente. Uma ferramenta pode ajudá-lo a melhorar os seus processos, se funcionar de acordo com a forma como a sua organização trabalha.

E normalmente não acontece o contrário, embora a ferramenta possa ajudar a modificar a forma como as empresas trabalham. Eu começaria por analisar quais são as limitações culturais que tem e, depois, adequaria a ferramenta a essas limitações.

Hannah Clark: Isso faz muito mais sentido.

Voltemos agora à comparação de funcionalidades, depois de falarmos sobre algum deste trabalho preliminar e sobre os fatores a considerar antes de analisarmos em detalhe aquilo que a ferramenta tem para oferecer.

É óbvio que muitas equipas avançam diretamente para a comparação de funcionalidades e preços quando avaliam ferramentas. Referiu isso anteriormente. Porque é que estes fatores aparecem tão tarde no seu modelo de avaliação?

Moshe Mikanovsky: Principalmente porque não quero que as pessoas analisem primeiro os resultados que podem obter com o produto que estão a utilizar, mas sim os resultados finais que procuram alcançar.

As funcionalidades são provavelmente o aspeto mais fácil de comparar. Além disso, as organizações dirão que têm esta e aquela funcionalidade. Mas, quando analisa os detalhes, que por vezes são publicados e por vezes não, terá de os procurar, perceberá se são realmente as funcionalidades que esperava.

Por vezes utilizam terminologias diferentes. Outras vezes, aplicam preços muito diferentes às várias funcionalidades disponíveis. Tudo isso é perfeitamente aceitável, mas, na maioria das vezes, cabe a nós, os consumidores, analisar todos esses detalhes para encontrar o produto certo para nós.

Mas, mais uma vez, penso que o mais importante é selecionarmos e implementarmos as ferramentas com base nos resultados que queremos alcançar, e não apenas nos resultados imediatos. Posso fazer isto e posso fazer aquilo, portanto esta ferramenta é melhor do que a outra.

Hannah Clark: Está bem, quero abordar talvez a parte mais frustrante da implementação de uma nova ferramenta: conseguir que toda a gente a adote e que todos estejam alinhados quanto à forma de a adotar enquanto organização.

Sobretudo depois de todo o trabalho desenvolvido para encontrar a ferramenta certa, fazer todas estas adaptações e considerar todos estes aspetos para garantir que é a ferramenta adequada, ainda é necessário conseguir que as pessoas a utilizem e que a utilizem da mesma forma. Quais são algumas das principais estratégias para garantir uma adoção bem-sucedida em toda a organização?

Moshe Mikanovsky: Está bem, a primeira é selecionar a ferramenta certa, ou pelo menos a ferramenta menos inadequada que conseguir encontrar, porque haverá sempre alguns problemas. A segunda é o processo de seleção. É uma questão difícil. Depende de quem é responsável, de qual será a governação da responsabilidade e de como será conduzido o processo de seleção.

Pode até haver opositores desde essa fase. Neste momento, não tenho uma recomendação específica. É algo em que estou a pensar e provavelmente irei ampliar um pouco o modelo no futuro, quando obtiver mais informações, também de outras pessoas. Se tiver muitas pessoas envolvidas no processo de seleção, em primeiro lugar, pode demorar muito tempo a selecionar; em segundo, tem consentimento ou consenso? Essa é outra questão cultural da organização. E depois, quem é responsável pelo produto, não apenas do ponto de vista da seleção ou da implementação? Historicamente, quantas vezes é que as TI foram responsáveis pelos produtos na organização porque se tratava de software que tinha de ser instalado num computador? Por isso, as TI assumiam a responsabilidade.

Mas depois não se preocupavam realmente em saber se o produto tinha sido implementado com sucesso. Era sempre necessário outro responsável para o implementar. Por isso, a responsabilidade também é importante.

Atualmente, com as operações de produto, poderá ser mais fácil para algumas organizações que tenham essa função, porque vejo esta responsabilidade a enquadrar-se bastante bem nas operações de produto, especialmente se quiser uniformizar o processo em toda a organização. Assim, essa equipa pode compreender as necessidades de todas as equipas e as diferenças entre elas.

Pode compreender as dificuldades de implementação e de utilização real em cada equipa. Isso pode dever-se a questões de personalidade, limitações do projeto ou muitas outras coisas. Tal como acontece com qualquer outro produto, alguns de nós têm de trabalhar arduamente para que o nosso produto seja corretamente implementado junto dos clientes.

E isto é um produto B2B. Todos os produtos de que estamos a falar são B2B. Por isso, se estiver a desenvolver um produto B2B, provavelmente sabe do que estou a falar. Poderá também ter mais empatia relativamente a esta questão. Por vezes, não é fácil.

Depende da dimensão da organização, do número de projetos e de produtos que tem e de muitos outros fatores, mas diria que, no geral, é uma questão de saber quem toma a decisão, quem é responsável, que tipo de governação existe, como é que as pessoas aceitam realmente essas decisões e as fazem avançar, incluindo através de iterações, para que não tenha de implementar tudo imediatamente.

Pode experimentar coisas diferentes e depois iterar, tal como faria com qualquer outro produto.

Hannah Clark: Sim, faz sentido. Ter um processo de integração um pouco mais faseado. Pelo menos, nesta situação, tem mais acesso aos seus utilizadores. Isso é uma vantagem.

Moshe, muito obrigada por se juntar a nós hoje. Foi realmente esclarecedor. Penso que foi muito útil, porque todos chegamos, em algum momento, a uma fase em que temos de selecionar novas ferramentas, e todo o processo de implementação pode ser uma verdadeira jornada. Agradecemos muito a sua orientação. Onde podem as pessoas saber mais sobre o modelo de seleção de produtos que desenvolveu e entrar em contacto consigo online?

Moshe Mikanovsky: Sim. Antes de mais, foi um prazer e obrigado pelo convite. Qualquer pessoa pode entrar em contacto comigo no LinkedIn. Pode procurar-me pelo meu apelido, Mikanovsky, e o meu site é productsforgood.co. Tenho o modelo num quadro do Miroverse. Está publicado no Miroverse. Tenho uma ligação para ele no meu site, na secção de recursos.

Mas também o vou partilhar consigo, para que possa incluí-lo na descrição dos episódios. Terei todo o gosto em partilhá-lo com todos. Pode copiá-lo e começar a utilizá-lo. Existem explicações no próprio quadro. Há muitos recursos dentro do modelo, como o Airtable e uma lista de produtos com alguma categorização.

Ainda está em desenvolvimento, porque surgem sempre produtos novos e encontro constantemente novos produtos. Se faltar alguma coisa, não hesite em contactar-me no LinkedIn. Terei todo o gosto em ouvir toda a gente.

Hannah Clark: Sim, teremos todo o gosto em partilhá-lo. E obrigada por todos os recursos e pelo seu tempo.

Moshe Mikanovsky: Foi um prazer. Muito obrigado, Hannah.

Hannah Clark: Obrigada por nos ouvir. Para obter mais informações úteis, guias práticos e análises de ferramentas, subscreva a nossa newsletter em theproductmanager.com/subscribe. Pode ouvir mais conversas como esta subscrevendo o The CPO Club na plataforma onde costuma ouvir os seus podcasts.