A Lacuna entre Produto e Processo: Como Travar Esta Fuga no Orçamento da Sua Organização

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoe quaisquer erros tipográficos, uma vez que o sistema automático não está correto 100% das vezes.

Hannah Clark: Uma das coisas maravilhosas das organizações Ágeis é o facto de estarmos constantemente a experimentar e a aprender para melhorar as nossas organizações e os produtos que oferecemos. Cada avanço tecnológico resulta de alguma forma de experimentação, mas aqui está o outro lado da questão: as experiências nem sempre conduzem a resultados positivos. Na verdade, muitas experiências apresentam falhas significativas — e quando centenas de milhares de dólares dependem do resultado de uma experiência, a última coisa que queremos é tomar decisões com base em dados incorretos. E aqui está a parte assustadora: na maioria das vezes, nem sequer percebemos que os dados estão incorretos até ser demasiado tarde.

O meu convidado de hoje é Manuel Da Costa, fundador da Effective Experiments. Como provavelmente pode deduzir pelo nome da sua organização, Manuel está essencialmente focado em ajudar as organizações a realizar melhores experiências, conduzindo a melhores decisões de produto. Embora as ferramentas certas possam certamente ajudar-nos a melhorar a experimentação e a análise de dados, também identificou um fenómeno que tem origem nas margens do organograma, chamado lacuna entre produto e processo — e que está a custar silenciosamente milhões às empresas tecnológicas. Vamos começar.

Bem-vindos de volta ao podcast O Clube CPO. Estou hoje aqui com Manuel Da Costa.

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

Manuel Da Costa: Olá a todos! Hannah, obrigado pelo convite.

Hannah Clark: Pode falar-nos um pouco sobre o seu percurso e sobre como chegou onde está hoje?

Manuel Da Costa: Claro. Sou o fundador da Effective Experiments. Somos uma empresa que fornece software para ajudar as empresas a colaborar melhor e a tomar melhores decisões de produto. O meu percurso começou há bastante tempo, no ambiente das startups enxutas, onde aprendi esta abordagem de testar e aprender para validar ideias. Depois fui entrando no mundo da otimização da conversão e, gradualmente, no meu próprio produto, onde ajudamos verdadeiramente as equipas de produto e de experiência do cliente a trabalhar melhor em conjunto.

E isso traz-me ao ponto atual da minha carreira, em que preciso de contar esta história, que é precisamente o motivo pelo qual estamos aqui neste podcast.

Hannah Clark: Estou entusiasmada por aprofundar o tema.

Hoje vamos concentrar-nos num fenómeno a que chamou a lacuna entre produto e processo. Pode começar por explicar-nos a que se refere e quais são as circunstâncias que a envolvem?

Manuel Da Costa: Sim, claro. A McKinsey realizou recentemente alguma investigação em que analisou a diferença entre boas e más práticas de gestão de produto, e tudo se resume às expectativas da liderança sobre a forma como o produto deve ser executado. E depois há aquilo que realmente acontece no terreno, com os gestores de produto a executar, e existe uma desconexão que identificámos. Dei a isso o nome de lacuna entre produto e processo, mas trata-se realmente da diferença entre as expectativas e a realidade.

Há muitas razões para isto acontecer e vamos abordá-las, mas, em última análise, a gestão quer um produto melhor e os gestores e responsáveis de produto não estão a cumprir essa expectativa. E há inúmeras razões para isso acontecer.

Hannah Clark: Vamos aprofundar um pouco essa questão. Disse que existem muitos fatores que podem levar a isso. Qual é o percurso, ou a origem, desta lacuna e como é que ela surge?

Manuel Da Costa: Claro. Vejamos o que se pede atualmente às equipas de produto: validar todas as decisões de produto que tomam. A experimentação tornou-se o veículo utilizado pelas equipas de produto para validarem essencialmente as suas hipóteses e confirmarem se estão a lançar o produto certo.

Muitas destas equipas de produto receberam a responsabilidade de realizar experiências, mas não têm a experiência nem os conhecimentos necessários. E, mesmo quando têm algum conhecimento, este é muitas vezes superficial no que diz respeito à experimentação. Como resultado, tomam-se decisões através da experimentação, mas a própria experimentação pode apresentar falhas. Pode não ser suficientemente rigorosa. E existem também outros elementos associados.

Estamos a falar de colaboração entre equipas, de saber o que fazer e também de definir prioridades de forma eficiente. Existem tantas prioridades conflituantes no produto, especialmente no que diz respeito ao que devem fazer, e agora que a experimentação foi acrescentada à mistura, é necessário saber como priorizar eficazmente essa lista de tarefas para obter o máximo resultado.

Estes são alguns dos sintomas que temos observado no terreno: como referi, pede-se às equipas de produto que executem, mas também que integrem a experimentação nas suas práticas, sem lhes ser dado o apoio necessário para o fazerem.

Hannah Clark: O que está a faltar nesta equação? Parece que existe quase um conjunto de competências de investigação da experiência do utilizador que está subdesenvolvido nos gestores de produto colocados nesta posição. E isso acaba, pelo menos, por provocar um efeito dominó de resultados defeituosos. Na sua opinião, quais são os principais fatores que contribuem para a falta de preparação com que os gestores de produto se deparam?

Manuel Da Costa: Vejamos onde a experimentação está a ser integrada. Em muitas organizações, a experimentação era realizada sobretudo por uma equipa de marketing, uma equipa de otimização da conversão.

Talvez fossem algumas pessoas, talvez uma pequena equipa central de excelência. Gradualmente, foi-lhes pedido que transmitissem essas competências às equipas de produto, para que estas pudessem realizar autonomamente as suas próprias experiências. O primeiro desafio começa com essa falta de conhecimento. Pode encontrar organizações que realizam algumas sessões de formação ou sessões orientadas, nas quais mostram às equipas como fazê-lo.

Mas é aí que o processo termina. É como se lhes tivessem dado acesso a algumas ferramentas e uma formação superficial. Não existem recursos que as ajudem verdadeiramente a compreender se estão a melhorar ou não. Como resultado, orientam-se pelos números. Limitam-se a dizer que realizaram determinado número de experiências e consideram esse o resultado, mas não há ninguém a acompanhar e a rever se a experiência foi corretamente executada, planeada e analisada.

Esta competência demora bastante tempo a desenvolver. Pense nisso como um músculo. Não é algo que se faça uma vez e depois se domine. Existem gestores de produto que realizam boas experiências, mas talvez demasiado simples. Podem realizar experiências complexas, mas implementá-las da forma errada. Como resultado, quando transmitem a informação à liderança e dizem “eis o que acreditamos que deve ser feito a seguir”, baseiam-se em informação incorreta — ou esta pode ser incorreta — mas não o sabem, porque não existe supervisão.

Isto leva-me ao ponto seguinte: falta esse elemento de supervisão. Muitas vezes, é atribuído um certo nível de confiança a estas equipas: “Vão realizar as experiências e nós acreditaremos no que nos transmitirem.” Devido à falta de recursos, ninguém dedica realmente tempo a verificar os resultados para perceber se são exatos.

Se esses resultados se devem a boas ou más práticas, essa é uma questão. O outro fator é a ausência do nível de liderança. E quando falo do nível de liderança, não estou a falar do responsável de produto. Estou a falar do vice-presidente de produto e dos diretores de produto. São eles que precisam de responsabilizar verdadeiramente essas equipas.

E não apenas responsabilizá-las, mas também dar-lhes alguma margem para poderem dedicar tempo a exercitar esse músculo e aprender a experimentar melhor, a tomar melhores decisões e a definir melhor as prioridades. Devido a estes dois fatores, cria-se este abismo entre as expectativas e a realidade. Os gestores de produto e os especialistas de produto têm dificuldades porque não dispõem da capacidade necessária para abrandar e pôr estas coisas em prática.

Assim, uma parte da responsabilidade cabe à liderança, porque esta precisa de dar a estas equipas não só o mandato, mas também a capacidade para melhorarem neste domínio.

Hannah Clark: Em termos práticos, como é que isso se traduz do ponto de vista da liderança? Quais são alguns dos passos que os líderes podem dar para evitar abrir esta lacuna entre produto e processo?

Manuel Da Costa: Claro. A primeira coisa é definir os indicadores-chave de desempenho certos. O principal problema que observamos surge quando são criados incentivos perversos. E quando falo de incentivos perversos, quero destacar o facto de poderem dizer, por exemplo, que é necessário lançar determinado número de funcionalidades neste trimestre ou neste ano e que esse número tem de ser atingido.

Assim, transforma-se num jogo de quantidade, não de qualidade. Pode lançar uma funcionalidade complexa ou várias funcionalidades simples, desde que atinja esse número. É necessário definir os indicadores certos para estas equipas, para que sejam incentivadas da forma adequada, em vez de poderem fazer qualquer coisa para atingir esse marco e escapar às consequências.

A segunda coisa é proporcionar às equipas e às pessoas que as supervisionam capacidade suficiente para orientar, acompanhar e melhorar novamente estas equipas de produto, permitindo-lhes tomar melhores decisões ao longo do tempo. Como disse, ninguém começa por saber experimentar corretamente. Isso leva tempo e não pode resumir-se a uma sessão de formação.

Estas equipas precisam de orientação e acompanhamento ao longo do tempo. O que descobrimos é que a falta de capacidade se deve ao facto de terem de atingir determinados números, pelo que não dispõem de tempo. E, como não têm tempo, não melhoram. É um ciclo vicioso que continua a repetir-se. Tudo começa com a liderança a dizer: “Queremos melhorar enquanto organização e tomar melhores decisões de produto.”

Como tomamos melhores decisões de produto? Isso resulta da experimentação e da validação dos nossos pressupostos. Esse é o primeiro passo. E, para o fazer, precisamos de equipar as nossas equipas de produto para formularem esses pressupostos. Damos-lhes tempo, damos-lhes capacidade, damos-lhes o mandato, mas também lhes damos segurança para errarem, porque o mais importante na experimentação é que podemos estar errados. Se definirmos os indicadores com base na quantidade, ou dissermos que queremos que lancem experiências com uma determinada taxa de sucesso, as pessoas vão manipular o sistema para atingir esse número.

A experimentação consiste essencialmente nisto: temos uma ideia de que algo pode funcionar, mas não sabemos até a testarmos na realidade. Não sabemos se vai funcionar ou não. Ao colocá-la no mercado, recebemos feedback dos clientes e do mercado, que nos mostra exatamente como funciona.

Depois podemos decidir se continuamos nesse caminho ou não. Esse elemento de segurança é bastante importante, porque, se os responsáveis e gestores de produto não tiverem essa segurança, optarão pelo que consideram ser a solução mais segura para atingirem os seus indicadores. Assim, teremos decisões de produto seguras, mas nunca decisões de produto inovadoras.

Hannah Clark: Consigo imaginar um cenário em que esta lacuna entre produto e processo passa despercebida, os indicadores são atingidos, as pessoas estão geralmente satisfeitas e a empresa se mantém à tona, mas falta alguma coisa. Quais são alguns dos sintomas de que uma organização está silenciosamente a sofrer com esta lacuna e de que poderia haver melhorias significativas, bem como decisões incorretas tomadas algures no processo devido a uma experimentação defeituosa?

Manuel Da Costa: Se estiver a ocorrer uma experimentação defeituosa, já observámos situações em que diretores e vice-presidentes de produto dizem: “Na realidade, não confiamos nos resultados destas experiências.” Assim, as decisões passam a ser tomadas com base na intuição. As pessoas tomam decisões com base no instinto, apesar de existirem dados, porque não confiam neles e simplesmente os ignoram.

E isso é algo que, se uma empresa estiver segura neste momento — sublinho as palavras “neste momento” —, significa que não experimenta, não inova e joga pelo seguro. Mais cedo ou mais tarde, as forças do mercado obrigá-la-ão a trabalhar mais para melhorar, ou determinarão o destino da empresa. Mas a falta de confiança nos resultados das experiências, ou mesmo no processo de tomada de decisão, é aquilo que precisamos de melhorar primeiro.

Essa é uma das coisas. Outra é que as empresas podem falar de serem orientadas por dados, focadas no produto e focadas no cliente, mas estas são apenas palavras da moda. Verá isso nas práticas, e não necessariamente naquilo que dizem publicamente. Também verá funcionalidades e atualizações de produto que não estão verdadeiramente alinhadas com aquilo que os clientes querem.

É simplesmente uma fábrica de funcionalidades. Lançam coisas por lançar, em vez de proporcionarem valor ao cliente ou à empresa como um todo.

Hannah Clark: Tem alguns modelos que recomendaria para realizar melhores experiências ou que tipo de medidas devemos tomar, de forma muito prática?

Porque parece que este é um problema para o qual contribuem muitos fatores e que conduz a este tipo de abismo. Qual é, na sua opinião, o primeiro passo quando reconhecemos que este fenómeno está a acontecer na nossa organização?

Manuel Da Costa: Sem dúvida. Penso que o primeiro passo consiste em uniformizar as coisas. Quando as equipas de produto recebem ferramentas para realizar experiências, o que temos observado é que, ao analisarmos duas equipas diferentes na mesma organização, estas começam subitamente a divergir na forma como realizam experiências, classificam os dados e capturam os dados. Assim, o primeiro passo é compreender qual deve ser o processo.

Depois de saber qual deve ser o processo, uniformiza-o. Quando digo uniformizar, as pessoas ficam bastante apreensivas porque sentem que têm de ser muito rígidas e que não existe margem para flexibilidade. O problema de uma abordagem demasiado flexível é que, com o tempo, se instala o caos e os dados tornam-se praticamente inúteis para qualquer pessoa que os analise no futuro.

Uniformizar significa uniformizar o processo, a classificação dos dados, a nomenclatura utilizada, as práticas de análise e quem aprova cada etapa. Significa implementar coisas como um modelo RACI, que define quem é responsável, quem presta contas e quem precisa de ser consultado e informado.

Estas coisas podem parecer rígidas, mas, na realidade, criam limites de segurança para as pessoas. E não importa se a equipa muda ao longo do tempo, se entram novas pessoas ou se alguém sai para outra equipa ou deixa a empresa. A prática fica integrada em todas as experiências realizadas e em todas as decisões tomadas com base nelas.

A outra questão é aprofundar verdadeiramente a ligação entre essas decisões e os objetivos empresariais. Em vez de tomar decisões ao acaso, estas devem estar alinhadas não só com os seus indicadores, mas também com os objetivos e metas da empresa. Quando estes dois elementos estão implementados, tem uma base muito melhor para avançar. O início será lento, porque as pessoas precisarão de tempo para se habituarem a dar mais atenção à forma como priorizam a sua lista de tarefas, decidem aquilo que devem experimentar, lançam essas experiências e avaliam se o resultado será uma funcionalidade completa que irão desenvolver ou se irão abandonar. Esses aspetos constituem a base.

Depois disso, é necessário garantir que existe uma supervisão clara. Quando falo de supervisão clara, significa que qualquer pessoa pode analisar uma equipa ou uma pessoa e avaliar o seu desempenho. Não se trata de procurar culpados, mas de compreender onde estão as lacunas e como lhes podemos dar melhor orientação.

Por exemplo, pode dizer-se: “Lançou cinco experiências neste trimestre, mas algumas não têm uma hipótese forte ou não selecionou as métricas certas para as avaliar. Eis como pode melhorar.” É assim que as pessoas melhoram: damos-lhes feedback e acompanhamos o seu trabalho, não para lhes dar feedback negativo, mas feedback positivo que lhes permita melhorar.

Estes dois elementos em conjunto melhorarão o nível de base da organização e ajudarão a eliminar esta lacuna.

Hannah Clark: O que é interessante nesta questão é que parece realmente existir um elemento de inteligência emocional necessário ao nível da liderança para gerir eficazmente desta forma. Muito depende da capacidade da equipa de liderança e da equipa de produto para construírem uma relação segura, na qual exista segurança psicológica para cometer erros e realizar experiências que não produzam os resultados esperados.

Que dicas recomendaria para promover relações mais fortes entre equipas e, sobretudo, em diferentes níveis do organograma? Como podemos melhorar a confiança mútua quando trabalhamos em estreita colaboração, especialmente num processo novo como este?

Manuel Da Costa: Sem dúvida. É mais fácil dizê-lo do que fazê-lo, porque estão envolvidas pessoas e egos, e as pessoas têm de se mostrar vulneráveis. Essa é a parte mais difícil. Mas aquilo que considero importante, novamente por parte da liderança, é proporcionar algum nível de segurança psicológica e alterar ligeiramente a linguagem.

Não dizemos que um teste foi bem-sucedido ou falhou. Concentramo-nos sobretudo nas aprendizagens. Mudamos a conversa de vitórias e derrotas para algo como: “Ao realizar esta experiência, validámos a necessidade desta funcionalidade” ou “validámos esta necessidade do cliente e foi assim que ajudámos a empresa.”

Este é o potencial da experiência. Ou: “Ao fazê-lo, invalidámos a necessidade de criar esta funcionalidade. Ao fazê-lo, poupámos à nossa equipa de desenvolvimento determinado custo e foi isto que aprendemos, algo que agora vamos explorar mais para aprender ainda mais.” Trata-se de mudar a mentalidade de experimentar por experimentar ou de experimentar para ganhar, razão pela qual os indicadores são tão importantes e a forma como são definidos também.

Os gestores, especialistas e responsáveis de produto podem ouvir isto e dizer: “Gostaríamos muito de fazer isso, mas não podemos porque os nossos indicadores são diferentes.” É por isso que é tão importante que a liderança preste atenção a esta questão. Se não o fizermos, haverá todo o tipo de efeitos secundários e as organizações acabarão por se tornar fábricas de funcionalidades. Pode parecer que as coisas estão a demorar muito tempo e que estamos a lançar produtos, mas, na realidade, até que ponto?

Hannah Clark: Sim, é um bom ponto.

Também estou curiosa. Enquanto falamos sobre alguns dos elementos práticos ao nível da liderança, é natural que os indicadores variem de equipa para equipa, mas o tamanho das equipas também varia. Como supervisionamos eficazmente uma equipa de produto à medida que começamos a crescer, com a entrada de novas pessoas que têm diferentes níveis de conhecimento ou conhecimento interno, comparativamente a alguém mais sénior?

Como uniformizamos e garantimos que proporcionamos o nível correto de supervisão, especialmente quando, enquanto líderes, temos muito menos pessoas do que os membros das equipas sob a nossa orientação?

Manuel Da Costa: No nosso mundo, criámos uma função a que chamamos orquestrador. Dependendo do número de equipas e de pessoas nessas equipas, cria-se a função de um orquestrador que supervisiona um número mais reduzido de equipas ou um determinado número de pessoas. Essa pessoa pode ser responsável pela integração, orientação e acompanhamento dessas equipas, garantindo que tudo no seu âmbito decorre como deve, e pode depois reportar ao nível seguinte.

Em vez de um líder supervisionar toda a gente, pretende-se ter uma pessoa responsável por uma equipa ou por várias equipas, cuja função específica seja tratar da integração, da orientação e do acompanhamento, garantindo que as pessoas sob a sua responsabilidade realizam melhores experiências e tomam as decisões de produto certas.

E que trabalham dentro dos limites de segurança definidos no próprio processo e nas estruturas. Penso que isso é muito importante quando analisamos a forma como a organização está estruturada. Um orquestrador pode supervisionar várias equipas, mas, mais uma vez, depende do tamanho da equipa.

Hannah Clark: Concordo também consigo relativamente ao conceito de limites de segurança. Penso que é uma daquelas coisas que parece retirar autonomia, mas, na prática, descobri que ter limites de segurança claros tende a reduzir a fadiga decisória e torna as funções muito mais claras, porque as pessoas não sentem que têm de melhorar continuamente os seus processos, além dos produtos que estão a desenvolver. Por isso, penso que existem argumentos muito fortes a favor desta abordagem.

Tenho, no entanto, curiosidade, porque aquilo de que estamos a falar agora também é a necessidade de uniformizar a supervisão. E isso parece-me um pouco mais abstrato: como uniformizamos o processo que utilizamos para supervisionar uma equipa, mesmo quando temos uma equipa mais pequena sob a nossa responsabilidade?

Que recomendações tem para uniformizar a abordagem à supervisão, sobretudo quando, enquanto líder, não se tem necessariamente uma experiência muito sólida em experimentação?

Manuel Da Costa: Tudo começa com a criação de um modelo de governação. Se analisarmos o que isso implica, trata-se de criar as regras para a forma como uma experiência é criada.

Quando digo como uma experiência é criada, refiro-me aos elementos essenciais que precisam de ser capturados quando se cria uma experiência. Alguns podem ser bastante básicos. Outros podem ser obrigatórios, como uma hipótese — uma boa hipótese. Existe uma diferença entre uma hipótese e uma hipótese realmente forte.

Esse é um aspeto, mas também é preciso decidir que outros detalhes devem ser capturados. Refiro-me a informação útil para criar a experiência, como os detalhes técnicos, o público-alvo e outros elementos semelhantes, mas também a aspetos relevantes e importantes para a empresa. Quando criamos um modelo de governação, dizemos que, sempre que alguém na organização cria uma experiência, existem determinados campos ou pontos de dados que têm de ser preenchidos.

Não há exceções: isso tem de ser capturado. É o mínimo indispensável. Depois existem outros aspetos opcionais. Esse é um elemento que pode ser, mais uma vez, imposto — detesto usar esta palavra, da forma mais positiva possível. Mas existem novamente limites de segurança que protegem a organização de acabar sentada sobre uma pilha de dados inúteis, algo que também pode acontecer.

Se der demasiada flexibilidade, haverá variações entre equipas diferentes, cada uma com a sua própria interpretação do que é uma experiência. Assim, existe um modelo de governação que determina que a criação de uma experiência exige a captura de informação relevante para a empresa e de informação técnica relevante.

Depois existe o processo que se segue. Não se pode conceber, executar e analisar uma experiência sem que esta passe por determinadas etapas. Por exemplo, não lançaria uma funcionalidade sem realizar testes de garantia de qualidade. O mesmo se aplica a uma experiência. Não lançaria uma experiência sem que esta passasse por testes de garantia de qualidade. Assim, o modelo de governação deve determinar que uma experiência não pode avançar por determinadas fases sem passar, por exemplo, por uma verificação de qualidade.

Isso não é negociável. Tem de passar por essa etapa. Significa que todas as experiências seguem um percurso e não podem desviar-se dele. Se houver um desvio, é possível acompanhar a situação e descobrir a razão. É aqui que entra o conceito de cartão de avaliação da saúde que desenvolvemos.

O cartão de avaliação da saúde é uma lista de verificação de determinados pontos através dos quais uma experiência pode ser avaliada. Por exemplo: foi criada uma hipótese? Sim ou não? O segundo aspeto é: quando foi criada? Foi criada quando surgiu a experiência? Ou só mais tarde, quando se tentou justificar a experiência?

Isso também acontece. Observámos uma tendência — não fomos nós que criámos o termo. Deparámo-nos com ela. Chama-se formulação retrospetiva de hipóteses: formular a hipótese depois de se conhecerem os resultados. É como dizer que, se torturarmos os dados durante tempo suficiente, eles dir-nos-ão aquilo que queremos saber. É mais ou menos isso que acontece, por vezes, quando temos experiências que não são realmente bem-sucedidas.

Não ganham. Mas depois podemos alterar as métricas e a hipótese. E, de repente, a experiência ganhou. Os modelos de governação e os limites de segurança são importantes porque impedem que estas coisas aconteçam. Não estou a dizer que as pessoas fazem isto deliberadamente. Mas voltamos ao problema de os seus indicadores consistirem em atingir determinado número de funcionalidades de produto, realizar determinado número de experiências ou alcançar uma determinada taxa de sucesso.

Assim, alteram tudo para atingir esse número. É aqui que os modelos de governação e o cartão de avaliação da saúde podem acompanhar estes elementos. O processo foi seguido? Foram feitas alterações às informações essenciais da experiência quando esta foi concluída?

Podemos então começar a acompanhar a situação. A pontuação de saúde pode dar-nos uma imagem sobre se a experiência foi executada corretamente ou não. Em última análise, podemos dizer: “Confiamos nesta experiência, nos resultados e nas decisões que tomámos com base nela”, ou “não confiamos nesta experiência”. E podemos explicar as razões, mas, mais uma vez, isso representa uma oportunidade de orientação.

É uma oportunidade para ajudar a organização a tomar melhores decisões de produto, mas também a realizar melhores experiências para lá chegar.

Hannah Clark: Agradeço muito os modelos que apresentou. Foram realmente úteis.

Tem alguma história de sucesso em mente sobre uma organização que tenha conseguido transformar os seus resultados ao eliminar a lacuna entre produto e processo?

Manuel Da Costa: Não posso revelar o nome da empresa, mas fizemos exatamente isso com uma empresa que estava a passar de uma equipa central de excelência para equipas que eram simultaneamente equipas de produto e equipas de mercado. Tinham uma grande variedade de equipas. Era uma empresa global de comércio eletrónico, com muitas equipas de mercado, mas também equipas de produto que estavam a ser introduzidas aos testes numa fase inicial.

Nesse contexto, era importante não introduzirmos imediatamente todas as equipas de produto e de mercado à experimentação. Criámos uma análise SWOT de cada equipa e avaliámo-las relativamente ao nível de conhecimento que tinham sobre experimentação. O outro fator era perceber até que ponto estavam interessadas e dispostas a envolver-se.

Começámos então a integrar as equipas com melhores pontuações e utilizámo-las como prova social. Depois de integrarmos algumas equipas e de estas começarem a evoluir bem — em ciclos de três meses, que designámos por ciclos de três meses —, cada ciclo tinha um plano para orientar e integrar essas equipas até ao ponto em que fossem autónomas no final do programa de três meses.

Utilizámo-las depois como prova social para integrar o grupo seguinte, proporcionando também apoio comunitário entre as equipas. Consolidámo-las ao longo de um período de dois anos. Foi um processo bastante longo. Mais uma vez, não era algo que fosse acontecer de um dia para o outro, sobretudo numa empresa de maior dimensão.

A mudança cultural não acontece de um dia para o outro. Foi esse o processo que seguimos. No final desse período de dois anos, tínhamos equipas de produto muito mais familiarizadas com a realização destas experiências. Mesmo quando houve rotação de colaboradores, com pessoas a sair da empresa e novas pessoas a entrar, o tempo necessário para um novo colaborador se integrar neste processo era inferior a um mês, porque todos os modelos estavam implementados.

Tinham os sistemas implementados e sabiam exatamente como proceder. Tinham tudo preparado para não poderem fazer nada de errado. É uma forma de dizer, porque era muito mais fácil seguirem o processo do que tentarem introduzir a sua própria interpretação.

Hannah Clark: Agradeço muito os exemplos que partilhou e esta conversa foi bastante esclarecedora.

Muito obrigada por se juntar a nós, Manuel. Onde é que as pessoas o podem seguir online se quiserem saber mais sobre o seu trabalho e sobre a Effective Experiments?

Manuel Da Costa: Podem encontrar-me no LinkedIn. Sou bastante ativo no LinkedIn. Também podem visitar EffectiveExperiments.com para saberem mais sobre aquilo que fazemos. Também publico bastante conteúdo no nosso blogue. Sintam-se à vontade para me seguir através desses dois recursos.

Hannah Clark: Fantástico. Muito obrigada.

Obrigado 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 Clube CPO, na plataforma onde costuma ouvir os seus podcasts.