Dados para Totós: Um Curso Intensivo para Gestores de Produto Não Técnicos

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 bot não está correto 100% do tempo.

Hannah Clark: Podemos ser honestos sobre uma coisa? Esta indústria está um pouco obcecada por ser orientada por dados. Não, essa não é a parte honesta, já sabíamos disso. A parte honesta é que nem todos somos assim tão bons com dados. E, se é o tipo de pessoa que se orienta bastante bem num painel de análise, pode nem sempre estar a trabalhar com os tipos certos de informações para mostrar o quadro completo.

O meu convidado de hoje é Mo Hallaba, CEO da Datawisp, que, caso não conheça, é uma ferramenta de visualização de dados alimentada por IA. Tendo em conta esta posição, Mo tem uma perspetiva única sobre a desconexão entre a quantidade de dados que a maioria das organizações recolhe e a eficácia com que os utiliza. Além disso, devo dizer que raramente falo com pessoas tão inteligentes que conseguem pegar em assuntos altamente complexos e torná-los acessíveis a qualquer pessoa. Mas, felizmente para si e para mim, é disso que trata esta conversa. Vamos começar.

Bem-vindo de volta ao podcast The CPO Club. Mo, muito obrigada por ter arranjado tempo para se juntar a nós hoje.

Mo Hallaba: Obrigado por me receber. Estou entusiasmado por estar aqui e falar sobre IA, dados e todas essas outras palavras da moda também.

Hannah Clark: Nós também estamos ansiosos por esta conversa.

Pode contar-nos um pouco sobre o seu percurso e explicar-nos como chegou onde está hoje na Datawisp?

Mo Hallaba: Claro. É uma história longa, mas tenha paciência comigo. Comecei a minha carreira na área financeira, na investigação de ações, dizendo às pessoas que ações deviam comprar e coisas desse género. Isso envolvia muita investigação e trabalho manual com dados, o que era uma verdadeira dor de cabeça.

Acabei por sair dessa área e trabalhar em fusões e aquisições empresariais durante algum tempo. Era mais do mesmo, mas de uma perspetiva diferente. Em vez de dizer às pessoas o que comprar, fazíamos aquisições. E, para essas aquisições, também fazíamos muita investigação própria. Mais uma vez, passávamos o tempo a escavar montanhas de dados.

Por fim, cansei-me disso e decidi: “Quero sair e fazer algo por conta própria. Quero criar uma startup.” Sempre fui muito apaixonado por videojogos, por isso pensei em fazer algo nesse setor. Criei então uma startup de jogos que falhou completamente, de forma absolutamente miserável, mas, durante o processo, conheci algumas pessoas que estavam a trabalhar em algo muito interessante: uma equipa de desportos eletrónicos. Compravam jogadores de regiões desconhecidas e utilizavam software para os treinar com recurso a dados e análises.

Achei isso muito interessante. Era como o Moneyball dos videojogos. Depois, a partir daí, o projeto começou a crescer por si próprio, porque algumas das outras equipas também o queriam e alguns dos outros organizadores de torneios queriam colocá-lo no ecrã e mostrar estatísticas. Foi assim que passei de trabalhar em finanças a trabalhar numa empresa de análise de dados.

Mais tarde, decidimos crescer para além dos videojogos. Agora, somos uma empresa de análises em toda a linha.

Hannah Clark: Excelente. Daqui a pouco vamos aprofundar isso. Na verdade, é uma transição perfeita.

Hoje vamos falar sobre como utilizar realmente os dados para orientar a tomada de decisões. Para começar, gostaria de saber: o que acha que muitas organizações fazem mal relativamente à chamada tomada de decisões “orientada por dados”? Sei que esse termo é um pouco polémico.

Mo Hallaba: Sim, acho que há muitas pessoas que esperam que os dados tomem decisões por elas, como se a tomada de decisões orientada por dados funcionasse assim. É verdade que alguns setores são altamente técnicos e que existem cientistas de dados e decisões fortemente baseadas em dados, mas não é esse o nosso objetivo.

Não é essa a finalidade da Datawisp. Estamos muito mais focados na tomada de decisões informada por dados. Trata-se de pegar em decisões que já ia tomar sem dados e simplesmente dar-lhe acesso a alguns dados para analisar, para que, quando tomar essa decisão, esteja mais informado. Um exemplo seria: “Onde devemos colocar este botão na nossa interface de utilizador?”

Devemos colocá-lo aqui em cima? Mais abaixo? Devemos sequer mudá-lo de posição? Se verificar que as suas taxas de conversão mostram que as pessoas entram no seu site e depois se perdem na página principal, talvez queira mudar o botão, certo? Mas, se descobrir que 90% das pessoas chegam à sua página e clicam no botão, não precisa de se preocupar com isso. São apenas pequenas coisas deste género: em vez de adivinhar, passa a tomar decisões com base em alguns dados. Ou seja, decisões informadas por dados.

Hannah Clark: Sim, eu também prefiro “informada por dados”. O meu lado canadiano veio ao de cima.

Pode explicar-nos de que formas a visualização de dados pode ajudar a democratizar a compreensão e a utilização de dados nas organizações?

Mo Hallaba: Claro. Acho que nem toda a gente é uma pessoa de números, especialmente quando falamos de pessoas não técnicas.

Quando analisamos áreas mais criativas, gestores de produto ou outras funções semelhantes, há pessoas que simplesmente compreendem melhor os dados quando os veem visualizados, sob a forma de imagens, à sua frente. Uma coisa é dizer que determinado padrão está a mudar ao longo do tempo. Outra é mostrar a alguém um gráfico onde possa ver como o indicador-chave de desempenho está a evoluir ao longo do tempo.

Depois, se tiver um ramo principal e um ramo novo que estejam a avançar juntos e, a certa altura, os dados se desviem numa determinada direção, é muito fácil olhar para o gráfico e perguntar: “O que aconteceu em julho?” É muito mais simples do que analisar uma tabela, declarações trimestrais ou algo semelhante. Na minha opinião, visualizar os dados, especialmente para pessoas não técnicas, torna muito mais fácil saber que perguntas fazer a seguir.

Hannah Clark: Sim, enquanto pessoa que admite não ser de todo uma pessoa de números, apoio plenamente a visualização de dados.

Quais são algumas das formas de as organizações se protegerem contra interpretações incorretas dos dados, já agora, para que os decisores tenham uma compreensão clara dos pontos de dados?

Mo Hallaba: Muitas pessoas olham para a IA e dizem: “A IA vai substituir as pessoas.” Não é essa a nossa perspetiva. O nosso objetivo é remover parte do trabalho rotineiro que cria estrangulamentos para os cientistas de dados. Uma excelente forma de evitar problemas é ter um cientista de dados na equipa ou contratar alguém que saiba realmente o que está a fazer. A diferença é que pode trabalhar com um ou dois cientistas de dados em vez de dez se tiver um bom software que permita às pessoas analisar dados. O que se pretende eliminar é a necessidade de competências técnicas para conseguir analisar dados.

Não devia ter de escrever SQL para obter um gráfico, mas isso não significa que deva tomar decisões com base nesse gráfico sem compreender o significado dos dados. Quando elimina essa barreira técnica, permite que as pessoas passem mais tempo com os dados e aprendam quais são as formas corretas de os utilizar.

Assim, passam a ter mais tempo para falar com um cientista de dados e compreender o que esses dados mostram e o que não mostram. Por exemplo, pode haver variáveis correlacionadas entre si por causa de causalidade ou por qualquer outra razão. Mas, basicamente, manter uma pessoa envolvida no processo é a melhor forma de evitar esse problema.

Quer seja um cientista de dados ou o seu melhor engenheiro, continuo a achar que, se as opções forem não fazer nada ou fazer alguma coisa, deve optar por fazer alguma coisa.

Hannah Clark: Qual é o seu método para dividir os dados em segmentos contextuais? Pode partilhar um exemplo de como isso funciona na prática?

Mo Hallaba: Posso. Na minha opinião, a melhor forma de pensar nisso é começar por analisar quais são os objetivos da sua empresa. Não se trata apenas de trabalhar com dados no vazio. Fazemos tudo isto com dados porque estamos a tentar compreender algo sobre o nosso negócio que não sabíamos antes de analisar os dados, certo?

Normalmente, depende da pergunta de negócio. Se estivermos a tentar perceber se o nosso tutorial é útil, uma forma de dividir os dados poderia ser separar as pessoas que utilizaram o tutorial das pessoas que não o concluíram. Depois, analisamos as taxas de abandono ou dividimos todo o conjunto de dados entre as pessoas que fizeram o tutorial e as que não o fizeram, para ver como diferem. Talvez não haja qualquer diferença.

Nesse caso, podemos dizer: “Está bem, ou o tutorial não é eficaz ou a aplicação é muito fácil de utilizar e as pessoas não precisam do tutorial.” Mas, se verificarmos que as pessoas que concluem o tutorial utilizam muito mais o produto, são muito mais eficazes com ele e permanecem clientes durante mais tempo, podemos pensar: “Talvez este tutorial tenha mesmo alguma utilidade.” Portanto, tudo depende do problema que está a tentar resolver desde o início.

Hannah Clark: É um exemplo muito claro. Agradeço bastante.

Já falou anteriormente sobre a diferença entre dados acionáveis e não acionáveis. Pode explicar um pouco o que quer dizer com cada um desses conceitos? O que são dados acionáveis? O que são dados não acionáveis? E como podemos identificar e utilizar eficazmente ambos os tipos?

Mo Hallaba: Tem mais que ver com a sua capacidade de agir com base nos conhecimentos que obtém. Não é que os dados em si sejam diferentes. A questão é saber quais são as suas opções. Vou tentar dar um exemplo.

Se analisarmos a Datawisp, por exemplo, temos um funil. Fazemos marketing, tentamos atrair pessoas, elas chegam, iniciam a utilização, usam a aplicação, gostam dela ou não gostam e depois abandonam ou permanecem. Quanto mais acima estiver no funil, mais coisas pode fazer.

Se ninguém marca uma demonstração, pode pensar que o botão não é suficientemente grande, que a página de destino não é apelativa ou que precisa de um novo elemento gráfico. Mas, se alguém inicia sessão, marca uma demonstração, fala connosco, experimenta o produto, faz muitas perguntas e depois abandona, talvez simplesmente não tenha gostado.

Ou talvez o produto não tenha resolvido a sua necessidade. Isso é muito menos acionável do que alguns dos aspetos no topo do funil. A questão é: o que pode fazer com base nesta informação? Algumas coisas são mais claras do que outras. Se tiver um funil em que passa do passo um para o passo dois e verificar uma queda de 50% no passo três, pode fazer uma lista das coisas que podem estar a causar essa queda e agir sobre elas. Mas, quando chega ao fim e as pessoas estão simplesmente a utilizar o seu produto, torna-se muito mais difícil perceber por que razão abandonaram.

Nesse caso, quem sabe? A forma de descobrir é realizar mais entrevistas com clientes e observar as pessoas a utilizar o seu produto. Existem outras ferramentas para isso.

Hannah Clark: Quais são algumas das ferramentas que as equipas de produto podem utilizar para recolher e analisar melhor alguns dos seus dados de utilizadores, de modo a informarem as decisões que tomam?

Mo Hallaba: Depende. Há muitos tipos diferentes de software que pode utilizar e depende realmente do tipo de produto que está a criar. Se estiver a desenvolver um jogo, é muito diferente de criar um site, uma plataforma de comércio eletrónico ou outra coisa qualquer. Mas precisa de algo que recolha eventos, ou seja, que registe quando as coisas acontecem e os armazene num local que facilite a análise.

Idealmente, se estiver a criar um jogo, existem extensões do Unity que conseguem recolher os eventos que acontecem no jogo, registá-los e armazená-los no Snowflake. Se conseguir algo desse género, torna-se muito mais fácil começar a analisar efetivamente esses dados. Esse é o requisito básico. Para comércio eletrónico e outras áreas, existem muitas soluções específicas para cada setor que fazem esse tipo de coisa. Portanto, diria que depende simplesmente do que está a criar.

Hannah Clark: Quanto à IA e ao papel da IA na assistência à análise de dados, mencionou que ter um cientista de dados na equipa é a melhor opção, ou vários.

Existe um lugar para a IA no que diz respeito a ajudar a tornar os dados mais compreensíveis, especialmente para pessoas não técnicas?

Mo Hallaba: Claro. Essa é precisamente a nossa atividade na Datawisp. A IA pode ajudar com o tipo de competência técnica necessária para analisar dados, transformá-los e moldá-los da forma pretendida, de modo a obter as respostas que procura.

A IA é muito boa nisso. Antes, esta era uma tarefa que apenas os cientistas de dados conseguiam realizar. Agora, qualquer pessoa como eu, completamente não técnica, pode utilizar uma destas ferramentas de IA e deixar que ela trate da parte do código. Basta fazer perguntas em linguagem simples. Qualquer pessoa com alguma curiosidade e conhecimentos básicos sobre o negócio ou o produto pode começar a explorar os dados.

Acho isso interessante porque cria um efeito de ciclo virtuoso: quanto mais pessoas se preocuparem com os dados, mais a empresa investirá recursos em ter dados limpos e bem organizados, em disponibilizá-los às pessoas e em tudo o que está relacionado com isso. E, consequentemente, beneficiará mais dessa realidade.

Hannah Clark: Vamos falar um pouco sobre a utilização de dados para iterar. Depois de aplicar os seus dados e os conhecimentos obtidos a uma funcionalidade específica, por exemplo, como cria um ciclo de feedback para orientar futuras iterações dessa funcionalidade?

Mo Hallaba: Posso dar-lhe um exemplo de algo que fizemos na Datawisp.

Com o Wispy, a nossa IA, preocupamo-nos muito com o número de pessoas que o utilizam e, mais importante ainda, com o tempo que estão dispostas a esperar por uma resposta. No início, tínhamos a opção de disponibilizar um Wispy muito rápido, que dava respostas aceitáveis, ou um Wispy muito mais lento, que dava respostas muito melhores — embora nem sempre, mas por vezes bastante melhores.

Descobrimos rapidamente, através dos dados, quanto tempo as pessoas estavam dispostas a esperar. Depois de determinado período, as pessoas simplesmente abandonavam; não estavam dispostas a esperar mais de 30 segundos ou um minuto. A versão inteligente do Wispy demorava por vezes dois minutos, mas apresentava resultados muito interessantes e ninguém ficava à espera esse tempo todo.

Por isso, decidimos concentrar-nos na velocidade. Tentámos tornar a Datawisp o mais rápida possível. E conseguimos ver as métricas a subir. No início, tínhamos a versão lenta. Depois fizemos uma divisão de 50/50, em que metade das pessoas recebia uma versão e a outra metade recebia a outra. Por fim, passámos simplesmente para a versão rápida.

Vimos os números aumentar à medida que avançávamos nesta iteração. É o tipo de trabalho em que eu e o Moritz, o nosso diretor de tecnologia, estávamos numa chamada a conceber aquelas pequenas mensagens que aparecem enquanto o Wispy está a preparar a resposta. Se o processo demora 30 segundos, não pode simplesmente ficar a mostrar um indicador durante 30 segundos, certo?

Por isso, criámos mensagens como “Ainda estou a trabalhar nisso”, “A ciência dos dados é difícil” ou algo semelhante. Estávamos a tentar perceber qual deveria ser o intervalo entre essas mensagens e pensámos: “Espera, podemos simplesmente consultar os dados.” Analisámos quanto tempo as pessoas estavam dispostas a esperar, ajustámos os intervalos de acordo com isso e lançámos a funcionalidade.

Esse é um exemplo concreto de como iterar utilizando dados.

Hannah Clark: Isso é muito interessante e fico a pensar, porque falamos frequentemente sobre o treino de modelos de IA e sobre aquilo que isso implica. Existe também um elemento de treino dos utilizadores? Quando diz que há um certo grau de impaciência por parte dos utilizadores enquanto esperam por uma resposta de maior qualidade, parece que esse comportamento pode ser treinado. Como aborda essa decisão?

Mo Hallaba: Está a segurá-lo mal. Não é assim que se faz. Não se lembra? Quando foi, Steve Jobs? Ele disse: “Está a segurar o telemóvel de forma errada.” Foi uma situação famosa: saiu um novo iPhone e a receção não era boa porque a antena estava colocada num local onde a mão ficava, e eles limitaram-se a dizer: “Está a segurá-lo mal. Deve segurar o telemóvel assim.”

Esse é um exemplo da forma errada de lidar com a situação. É a pior forma possível. Em geral, trata-se de definir expectativas. É uma combinação de educação e definição de expectativas. As duas coisas estão interligadas, mas, no final do dia, o utilizador tem uma ideia daquilo que pretende.

Por isso, acaba por ser um compromisso. Compreendemos que a Datawisp se destina a pessoas não técnicas. O comportamento existente é: “Vou enviar um e-mail ao João e o João vai obter as respostas por mim.” São pessoas que não têm de se esforçar muito para obter algo.

Isso é mau para o João, mas é a realidade dessa pessoa. Não podemos pedir-lhe que faça um esforço enorme. Podemos pedir-lhe que faça um pequeno esforço. Mas, se for mais do que isso, há também uma componente de marketing e de definição de expectativas. O que pretende? Uma boa resposta? Quando precisa dela? Quanto tempo demora o João a responder-lhe? Uma semana? Vale a pena esperar um minuto por uma resposta da Datawisp? Trinta segundos seria bom, mas um minuto continua a ser menos do que uma semana.

Assim, vai dando pequenas pistas e precisa de um bom redator para isso, tanto no seu site como na forma de definir expectativas desde o início. “Obtenha a sua resposta em minutos, não em semanas.” Não deve dizer segundos, porque, se disser segundos, as pessoas esperam que aconteça imediatamente. Se disser “obtenha uma resposta em segundos”, cria uma incompatibilidade de expectativas.

É curioso, porque digo tudo isto e provavelmente o nosso site ainda fala em segundos. Mas penso que, nas chamadas de vendas, temos de ser muito claros com o cliente e dizer: “Veja, se isto lhe demora atualmente quanto tempo?” E o cliente responde. Então podemos dizer: “Está bem, conseguimos fazê-lo numa fração desse tempo.” E assim definimos um pouco melhor as expectativas.

Hannah Clark: Sim, é interessante. Sinto que existe um comportamento criado por pessoas tão habituadas a utilizar motores de pesquisa que esperam que as respostas surjam instantaneamente, apesar de a tecnologia ser muito diferente.

Mo Hallaba: O ChatGPT também habituou mal as pessoas, porque estas pensam simplesmente que a IA é magia. Não compreendem de todo como funciona. Além disso, já viram a rapidez com que consegue produzir muito texto. Se eu disser: “ChatGPT, cria um itinerário de viagem para uma viagem de cinco dias a Milão”, ele responde imediatamente.

Por isso, as pessoas comuns assumem que isto é magia e que consegue fazer tudo rapidamente. Mas há uma diferença. Quando se liga a uma base de dados que contém mil milhões de linhas, a IA nem sequer é a parte que demora mais tempo. É preciso executar a consulta e essa consulta pode demorar algum tempo a ser processada.

Não há absolutamente nada que possamos fazer quanto a isso. Mas, como alguém viu o ChatGPT a ser muito rápido, pensa: “Isto devia demorar dois segundos.” Por isso, uma das coisas que o Wispy faz agora e que não fazia antes é informar o utilizador sobre o estado em que se encontra enquanto está a processar. Primeiro diz: “Estou a pensar.” Quando termina de pensar e está apenas à espera da base de dados, diz: “À espera da sua base de dados.” Assim, comunica o que está a acontecer em todos os momentos e define expectativas ao longo de todo o processo.

Hannah Clark: Consigo perceber como isso pode ser muito útil. Também acho que os utilizadores estão muito habituados a assumir que, quando algo fica a carregar durante aquilo que consideram demasiado tempo, está avariado ou é necessário reenviar o pedido. Muito interessante.

Mo Hallaba: Analisámos muitos dados sobre isso. Em primeiro lugar, registe tudo. Assim que tiver um produto em funcionamento, comece a registar os acontecimentos. Nós registámos tudo: todos os botões que podem ser premidos na Datawisp, sempre que alguém os prime.

Por isso, temos uma ideia muito clara de como tudo funciona. Também fizemos testes com utilizadores e percebemos que, se algo ficasse a carregar durante algum tempo, as pessoas simplesmente atualizavam a página premindo F5. O produto tem realmente de comunicar o que está a fazer se obrigar as pessoas a esperar mais de cinco segundos.

Hannah Clark: Isso faz todo o sentido. E sim, penso que “registe tudo” poderia ser o lema deste episódio.

Mo Hallaba: Registe tudo o que os seus utilizadores fazem no seu produto, porque será útil em algum momento.

Hannah Clark: Sei que já partilhou um exemplo de dados a informar uma decisão. Foi um exemplo concreto muito bom. Gostaria de saber qual foi o exemplo mais triunfante de dados a informar uma decisão, quer tenha sido com um cliente ou com a sua própria equipa.

Mo Hallaba: Este exemplo não é da Datawisp, mas o mais triunfante foi, como já lhe disse que trabalhei anteriormente em desportos eletrónicos, termos literalmente ganho um torneio com base nisto, com base em dados.

O funcionamento do software era realmente interessante. Também posso dar-lhe um exemplo da Datawisp, se quiser. O software permitia filtrar os dados com base em diferentes condições. A maioria das ferramentas disponibilizava mapas de calor.

Este é o mapa completo e mostra os locais onde os outros jogadores da outra equipa costumavam estar. Se observar um mapa de calor relativo a um jogo de uma hora, tudo parece verde. Mas isso não é útil. Se estiver num jogo e o mapa inteiro estiver verde, não sabe onde os adversários estão.

O que era realmente interessante era dividir os dados por situação. Na primeira ronda do jogo, onde estão? Quando têm esta quantidade de dinheiro, onde estão? Quando não têm dinheiro, onde estão? Quando têm estas armas, onde se posicionam em comparação com quando têm armas diferentes?

Assim, pode começar a criar cenários em que, de repente, o mapa de calor mostra cinco pontos vermelhos e sabe exatamente onde está o adversário. Utilizámos isso em competição e vencemos com o orçamento salarial mais baixo de qualquer equipa no torneio.

Foi incrível.

Hannah Clark: Fantástico. Tenho a certeza de que há pessoas do mundo dos desportos eletrónicos a ficar muito interessadas neste momento.

Mo Hallaba: O melhor exemplo da Datawisp que posso dar é o de termos ajudado um jogo a triplicar a sua base de utilizadores num período muito curto. Fizeram isso segmentando os utilizadores com base na fonte de aquisição utilizada.

Depois, procuraram comportamentos específicos dentro do jogo que valorizavam mais do que outros. Conseguiram perceber que, quando adquiriam utilizadores através de determinado canal, esses utilizadores tinham no jogo o comportamento que lhes interessava. Assim, conseguiram concentrar os seus esforços nos canais de aquisição que preferiam.

A empresa chama-se Honeyland. Fizemos um estudo de caso com eles. Está disponível no nosso site. Foi muito interessante.

Hannah Clark: Sim, é muito interessante. Gostaria de consultar esse estudo.

Mo, muito obrigada por se ter juntado a nós hoje. Onde é que as pessoas podem acompanhá-lo online?

Mo Hallaba: Se estiver no X, sou o ElectronicMo. Caso contrário, pode acompanhar-me no LinkedIn. É simplesmente o meu nome. A Datawisp utiliza o mesmo nome, por isso também pode acompanhar a Datawisp no X e no LinkedIn.

Hannah Clark: Excelente, muito obrigada por se ter juntado a nós e por este curso intensivo, que foi muito acessível para pessoas que não trabalham com dados, como eu.

Mo Hallaba: Tento tornar as coisas simples. Muito obrigado por me receber, Hannah.

Hannah Clark: Obrigada por nos ouvir. Para obter mais conhecimentos, 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 onde quer que ouça os seus podcasts.