Como os Gestores de Produto Podem Usar os Superpoderes dos Dados para Vencer a Concorrência
Ler a transcrição:
Estamos a experimentar transcrever os nossos podcasts através de um programa informático. Perdoem-nos quaisquer gralhas, pois o robô não está correcto 100% das vezes.
Hannah Clark: Num mundo perfeito, todas as decisões que tomamos seriam orientadas por dados. Então, o que acontece quando o coração está disposto, mas os dados que queremos simplesmente… não estão disponíveis? Ou quando o processo de obtenção desses dados é tão trabalhoso que o resultado não compensa o esforço? Para muitas equipas de produto, demasiadas decisões acabam por basear-se apenas num número — o salário da pessoa que as toma.
Hoje falei com Vijay Umapathy, Director de Gestão de Produto na Heap. O Vijay partilha como a sua equipa de produto se tornou progressivamente mais orientada por dados, bem como os avanços que alcançaram para gerar mais informações em menos tempo. Também falou de uma táctica verdadeiramente brilhante que a sua equipa utilizou para evitar conflitos entre as equipas de produto e engenharia. Vamos começar.
Vijay, muito obrigada por te juntares a nós hoje.
Vijay Umapathy: Excelente. Obrigado pelo convite. É óptimo estar aqui.
Hannah Clark: Sim. Vamos começar por falar um pouco sobre o teu percurso. Podes contar-nos um pouco sobre a tua evolução profissional e sobre como acabaste por chegar à Heap?
Vijay Umapathy: Sim, claro. Comecei por estudar engenharia, estudei informática no MIT e comecei logo a trabalhar em produto depois de terminar os estudos. Entrei no programa APM da Google. Uma coisa engraçada é que fui uma daquelas primeiras pessoas convencidas pelo discurso de que, “enquanto gestor de produto, és o mini-CEO”, o que não é de todo verdade e é hoje visto como uma forma realmente arcaica de descrever a área — e está completamente errado.
Mas devo dizer uma coisa: desde o início gostei muito da ideia de desempenhar vários papéis. Usar um chapéu voltado para o cliente, ou um chapéu de design, ou de engenharia, ou de produto, e alternar entre todas essas perspectivas diferentes quando se trata de ajudar as pessoas através da tecnologia.
E essa parte tem sido verdadeira sobre ser gestor de produto; não era totalmente falsa a ideia de como seria.
Hannah Clark: Queria perguntar-te: há algo na tua biografia, na tua conta do Medium, que diz que gostas muito de criar ferramentas que dão superpoderes às pessoas. Achei uma forma muito divertida de o dizer e queria saber como é que isso se manifesta no contexto da Heap, que, para quem não conhece, é uma ferramenta que também pode ser utilizada por profissionais de produto.
Vijay Umapathy: Sim. A Heap é uma ferramenta de análise de produto. Para dar uma ideia do que penso que muitos gestores de produto vivem com a análise, posso contar-te como era na última empresa onde trabalhei. Trabalhava numa startup de robótica e tínhamos uma espécie de responsável pelo painel de controlo, um especialista em dados.
Se alguma vez tivesse uma pergunta sobre o comportamento dos utilizadores — quantas pessoas estavam a utilizar uma funcionalidade, o que estavam a fazer, onde ficavam bloqueadas — tinha de abrir um pedido para essa pessoa e esperar semanas até que fosse priorizado. E isto era apenas para criar um gráfico que respondesse à minha pergunta.
Era realmente arcaico e extremamente incapacitante. Por isso, penso que o que me atraiu verdadeiramente na Heap, quando a estava a avaliar como empresa para integrar, foi ter percebido: estão a criar coisas para gestores de produto. O que é especial? Penso que o aspecto realmente interessante da Heap é automatizar o trabalho de escrever manualmente código para acompanhar cada acção dos utilizadores que nos interessa.
Por exemplo, se tiver uma loja de comércio electrónico e quiser saber quantas pessoas estão a clicar em adicionar ao carrinho, normalmente, com as ferramentas de análise, tenho de escrever uma linha de código que diga que alguém clicou no botão de adicionar ao carrinho. Depois tenho de manter isso ao longo do tempo. É uma grande confusão. Com a Heap, capturamos automaticamente todos esses dados.
Automatizamos grande parte desse trabalho de acompanhamento. Mas o aspecto realmente poderoso é que, se seis meses mais tarde eu estiver a fazer uma pergunta — quantas pessoas realizaram esta acção ou utilizaram esta funcionalidade? — e me tiver esquecido de pedir a alguém que acompanhasse isso, de criar o pedido ou de falar com o responsável pelo painel de controlo, não tenho de esperar.
Posso fazer a pergunta, tenho acesso imediato a todos os dados históricos e posso simplesmente obter a resposta em segundos. Para dar uma ideia do que há de interessante nisto, pensem em quantas reuniões acontecem em que alguém pergunta: quantas pessoas estão a fazer isto?
E, se não tivermos imediatamente a resposta na ponta dos dedos, a pessoa mais insistente toma conta da conversa. Estive literalmente numa destas reuniões pouco depois de entrar na Heap. Estávamos a trabalhar numa página que tinha uma experiência de navegação e uma experiência de pesquisa.
Podem imaginá-la como o Google Drive. Alguém disse: então, vamos assumir que muitas pessoas estão simplesmente a pesquisar nesta página. Uma suposição estranha. Eu disse: está bem, vamos falar sobre o futuro da pesquisa e sobre a reformulação desta funcionalidade. Enquanto essa pessoa continuava a falar, entrei na Heap e criei um evento para as pessoas que pesquisavam nessa página.
Tinha acesso imediato a todos os dados históricos. Depois criei um gráfico que mostrava que percentagem de pessoas fazia isso. E percebi que eram apenas 27%. Disse: desculpem? Parece que a minoria das pessoas pesquisa aqui. Podemos falar um pouco mais sobre a navegação? Isso mudou o rumo da reunião.
É isto que quero dizer com superpoderes. Penso que daqui a dez anos vamos olhar para trás e achar absurdo que, naquele momento, não fosse possível responder a essa pergunta.
Hannah Clark: Tu tens pessoalmente uma grande paixão pela utilização de análises de dados na tomada de decisões. Como pensas que algumas dessas paixões influenciaram o desenvolvimento do produto e algumas das informações que consegues obter?
Vijay Umapathy: Não sei se influenciaram necessariamente o produto. Muitas vezes apoiamo-nos nos nossos clientes para isso, mas diria que provavelmente ajudaram a moldar a forma como falamos sobre boas práticas.
Uma das coisas realmente interessantes é a capacidade de fazer todas estas perguntas pontuais, uma após outra. O que descobri é que, quando damos às pessoas o poder de fazer essas perguntas e obter respostas muito rapidamente, o problema passa a ser, na realidade, os processos.
Muitas pessoas estão habituadas a pensar que, quando lançam uma funcionalidade, se sentam e definem as cinco métricas que vão medir. Depois sentam-se mais tarde, analisam o painel de controlo, partilham-no com os executivos numa reunião e seguem com as suas vidas.
Na Heap, tentámos praticar algo diferente — até criámos modelos para isso. Devemos ser realmente orientados por hipóteses. Quando começamos por dizer que queremos resolver um problema com este produto ou com esta funcionalidade, temos um modelo para algo chamado resumo do problema, no qual descrevemos detalhadamente o problema sem prescrever uma solução.
No final, temos aquilo que consideramos a parte mais importante: uma hipótese quantificável. Acredito que este grupo de utilizadores vai alterar o seu comportamento desta forma mensurável. E talvez esta seja a dimensão da mudança que espero observar.
O que significa fazer bem? Depois das funcionalidades serem lançadas, temos um ritual que criámos e praticámos várias vezes, e sobre o qual escrevemos modelos e artigos: os relatórios pós-acção. Essencialmente, começamos por perguntar qual era a minha hipótese antes de construirmos isto e se estava correcta.
As coisas evoluíram como pensávamos? E o que mais nos surpreendeu? A partir desse aspecto, podemos entrar numa verdadeira toca de coelho. Penso que essa é a parte em que a Heap incentivou este tipo de comportamento na nossa equipa e nos nossos clientes: explorar perguntas adicionais.
Que segmentos de utilizadores tiveram comportamentos muito diferentes? Que percursos diferentes fizeram as pessoas através da funcionalidade ou do fluxo de trabalho que adicionámos ao produto e que não esperávamos que utilizassem?
Hannah Clark: Podes dar-nos um exemplo de uma toca de coelho que tenhas explorado recentemente e que nos ajude a perceber bem o poder que isso pode ter?
Vijay Umapathy: Sim, claro. Um bom exemplo é o lançamento de uma capacidade de reprodução de sessões na Heap, há cerca de seis meses. Adquirimos uma empresa que fazia reprodução de sessões, o que permite ver uma reconstrução visual do que um utilizador está a fazer e acompanhar cada clique.
Quando lançámos essa funcionalidade, inicialmente pensámos em fazê-lo como uma integração. Criámos vários pontos de entrada para ela dentro das nossas funcionalidades de análise. Vimos que estavam a ser utilizados e que as pessoas os experimentavam. Mas descobrimos que havia alguma fricção quando as novas contas estavam a configurar a funcionalidade, porque esperavam fluxos de trabalho inicialmente um pouco mais qualitativos.
Conseguíamos ver padrões em que navegavam para outras partes do nosso site para tentar obter isso. Como resultado, começámos a trabalhar em algumas iterações para lhes facilitar bastante a navegação nesses fluxos de trabalho. Penso que este é um padrão muito comum em produto: lançamos algo, temos algumas suposições, algumas coisas correm bem e outras surpreendem-nos, e está tudo bem.
Depois continuamos a iterar e acabamos por chegar a um ponto em que o comportamento se normaliza em torno de percursos próximos daqueles que definimos. Mas, normalmente, no início nunca é assim.
Hannah Clark: Está bem. Mudando um pouco de assunto: tenho pensado muito em avanços recentes, aqueles momentos em que temos uma epifania que passa a fazer parte dos processos. Podes falar-me de um avanço que tenhas tido relacionado com a utilização de informações dos utilizadores e a criação de algo realmente interessante com base nelas?
Vijay Umapathy: Penso que o maior avanço que alcançámos no nosso produto, e que também provocou muitas mudanças na forma como trabalhamos enquanto equipas de produto e na forma como os nossos clientes trabalham, vem realmente da capacidade de reprodução de sessões que adicionámos ao produto.
Para dar algum contexto, normalmente temos os dados quantitativos numa ferramenta. Temos um silo com todos os dados comportamentais, criamos gráficos, relatórios de funil e tudo isso. Separadamente, temos outro silo com dados qualitativos.
Podem existir duas equipas diferentes a analisar esses dois silos. Talvez a equipa de design veja regularmente algumas reproduções de sessões. O que acaba por acontecer é uma acumulação: temos milhões e milhões de horas de reproduções de sessões, mais do que alguma vez conseguiríamos ver.
Mas um dos grandes problemas é não sabermos quais as sessões que devemos realmente ver. Além disso, mesmo que abramos uma sessão com uma hora de duração, não sabemos que momentos são importantes nem quais são importantes de uma forma que tenha impacto no negócio como um todo, e não apenas num utilizador.
Costumávamos ter uma reunião todas as sextas-feiras em que nos sentávamos e víamos algumas reproduções de sessões. Era um processo normal. Sei que muitas equipas de produto fazem isto actualmente.
O objectivo era criar um ritual que nos permitisse ter empatia com o cliente e, ao mesmo tempo, orientar a discussão para um fluxo de trabalho específico que nos interessasse ou no qual estivéssemos a trabalhar, para gerar ideias sobre possíveis alterações com impacto.
Esse era o objectivo. O problema era haver uma pessoa que tinha de preparar a reunião. Era uma reunião de 30 minutos com 20 ou 30 pessoas, portanto era dispendiosa. Uma pessoa tinha de passar cerca de três horas antes da reunião a ver horas e horas destas sessões, a maioria das quais era inútil.
Depois tinha de escolher três para vermos em grupo. Era um trabalho horrível e penoso. E, quando as coisas ficavam ocupadas, era muito fácil essa pessoa não ter tempo para o fazer. Não era essa a sua função. Assim, todo o ritual se desmoronava e a utilização dos dados qualitativos estagnava.
Tornava-se informação arquivada e inutilizada. Quando adquirimos a empresa de reprodução de sessões, a oric, em Junho do ano passado, não nos limitámos a adicionar uma página de reprodução de sessões ao produto. Integrámo-la profundamente na própria análise. Sempre que se analisa qualquer tendência quantitativa, oferecemos essencialmente um botão “mostra-me”.
Esse botão não só selecciona as sessões certas para o contexto analisado, como também pode responder a perguntas como: lancei uma funcionalidade; mudou entre a semana passada e esta semana? Como é que as pessoas clicaram nela de forma diferente? Ou: muitas pessoas estão a abandonar o processo no terceiro passo do meu fluxo de trabalho. O que está a acontecer?
Integrámo-la profundamente, oferecemos o botão “mostra-me”, seleccionámos as sessões certas e levámos o utilizador directamente ao momento certo dessas sessões. Foi isto que mudou na reunião. Recuperámos uma versão dessa reunião, mas sob a forma de uma sessão de ideias, liderada pela nossa equipa de crescimento.
Ainda me lembro de andar atordoado pelo escritório depois de a realizarmos, porque esta equipa não fez qualquer preparação. Pegaram nos relatórios de funil existentes para diferentes partes do nosso processo de configuração e integração. Dividiram as pessoas em grupos e disseram: tu vais para esta sala, tu para aquela, e vejam o maior número possível destas reproduções, gerando notas virtuais semelhantes a post-its sobre áreas de fricção.
Cada equipa escolheu um funil ou passo diferente. Mais uma vez, não houve preparação. A pessoa que antes passava três horas a filtrar sessões deixou de ter de o fazer. Saíram dali com centenas de ideias em 30 minutos. Foi um momento decisivo: percebemos que isto podia ajudar as equipas a gerar ideias muito mais rapidamente do que alguma vez tinham imaginado.
Hannah Clark: Fantástico. E com um impacto tão grande.
Vijay Umapathy: Sim, sem dúvida. E o melhor é que também é orientado por dados. Penso que muitas pessoas esquecem que 90% das decisões de produto no mundo são actualmente tomadas com base nas opiniões das pessoas.
É o chamado HIPPO: a opinião da pessoa mais bem paga. É um acrónimo engraçado entre gestores de produto, mas penso que é muito real. A maioria destas decisões baseia-se simplesmente na intuição. Por isso, mesmo que estejamos a analisar algumas histórias e criemos uma publicação numa dessas reuniões, se essa história tiver sido informada por um contexto quantitativo, como parte de um fluxo de trabalho que não está a funcionar bem, isso já é uma vitória.
Estamos progressivamente mais informados do que estaríamos de outra forma. É isso que as pessoas têm de perceber: podemos vencer dando mil pequenos passos na direcção certa. Ser orientado por dados não tem de ser um grande interruptor ligado/desligado. Não é necessário estar completamente fora ou dentro. Podemos subir lentamente essa escada.
Hannah Clark: Voltando à ideia de inovação: como equilibras a necessidade de inovar e iterar com a garantia de que o produto que entregas é sempre estável, fiável e continua a proporcionar uma experiência consistente ao cliente?
Vijay Umapathy: Quero desenvolver um pouco esta pergunta, se me permitires.
Hannah Clark: Claro.
Vijay Umapathy: Para responder à primeira parte, sobre fiabilidade e estabilidade, penso que, normalmente, se monitorizarmos métricas básicas de fiabilidade e estabilidade, e se a empresa tiver um acordo de nível de serviço com os clientes sobre aspectos como a disponibilidade, os dados indicarão claramente quando é necessário deixar tudo e corrigir o problema.
Noutros casos, pode tratar-se do desempenho. A questão mais interessante, com muitas nuances e que cria desafios para os gestores de produto, é saber como gerir a dívida técnica com a equipa de engenharia enquanto se continuam a criar novas capacidades de produto e a resolver problemas dos clientes.
Existe um estereótipo comum: um gestor de produto diz para continuarmos a criar novas funcionalidades para resolver todos os problemas dos clientes. Os executivos adoram essa pessoa porque as ideias são brilhantes e vêem sinais de dinheiro.
Entretanto, a equipa de engenharia está sentada num canto a dizer que precisa mesmo de actualizar a versão do Node. Vai ficando cada vez mais ressentida à medida que a sua ideia é despriorizada. Isto cria conflitos entre as equipas de produto e engenharia sem necessidade.
Uma prática que adoptámos em várias equipas da Heap é utilizar o roteiro para priorizar os nossos investimentos técnicos nas fundações do produto. Criámos algo chamado quadro de avaliação da agilidade.
Começámos com o princípio de que os computadores devem trabalhar para nós. Deve tornar-se cada vez mais fácil fazer as coisas que precisamos de fazer com maior frequência no nosso roteiro.
O primeiro passo é analisar o roteiro e perguntar: que tipos de alterações quero fazer ao meu produto com mais frequência e quais quero fazer com menos frequência? Depois, para as coisas que quero fazer mais vezes, cada vez que as faço estou limitado? Sempre que altero algo deste tipo estou a acumular dívida técnica? Talvez leve semanas, quando deveria levar minutos, e seja extremamente frustrante.
Ou estou capacitado? É relativamente fácil de fazer e bastante directo, embora continue a exigir trabalho. Ou está tudo optimizado? Foi concebido para que eu faça isto milhares de vezes por dia? Não queremos optimizar tudo, porque nesse caso não optimizamos nada.
Devemos recuar e identificar o subconjunto de tarefas que sabemos que vamos realizar constantemente. Na Heap, percebemos que vamos criar novos tipos de visualizações de dados para sempre. Também percebemos que vamos criar interfaces para as pessoas fazerem perguntas aos dados para sempre.
Analisámos essas áreas e perguntámos quanto tempo estavam a demorar, quanto deveriam demorar e quais eram as queixas da equipa de desenvolvimento. Conseguimos recuar e dizer: vamos interromper durante algum tempo o desenvolvimento de funcionalidades em algumas equipas e dar prioridade à migração do nosso front-end para React.
Sei que muitas empresas têm feito isto nos últimos anos. São projectos grandes e dolorosos. E, já agora, é difícil. Demora muito tempo e tem muitos casos-limite. Mas é importante sentarmo-nos antecipadamente, inclusive com a equipa executiva, e enquadrar isto como um investimento na nossa velocidade futura.
Estou a investir agora um mês para pegar numa tarefa que sei que vou fazer cem vezes e reduzi-la de uma semana para uma hora. Isso vai compensar rapidamente. Passamos de dívida técnica para dividendos técnicos.
Quando pensamos desta forma, torna-se uma actividade colaborativa e entusiasmante entre as equipas de produto e engenharia. Deixamos de criar conflitos entre equipas.
Hannah Clark: Vijay, que tendências estás a observar actualmente na área de gestão de produto e análise de dados? E como te manténs à frente dessas tendências para garantir que a tua equipa está sempre na vanguarda?
Vijay Umapathy: Uma das grandes tendências é a eliminação dos silos entre dados.
Há algumas coisas que estão a impulsionar isto. Uma é a ideia de fluxos de trabalho obviamente fragmentados. Falámos disso anteriormente no exemplo da reprodução de sessões. Quando a combinamos com o contexto dos dados quantitativos, conseguimos chegar ao valor e às informações muito mais rapidamente.
Quando existe a oportunidade de melhorar fluxos de trabalho que actualmente estão distribuídos por várias ferramentas, começamos a observar uma maior consolidação de ferramentas. O que acelerou este fenómeno nos últimos meses foram as condições do sector tecnológico: os desafios macroeconómicos das empresas tecnológicas que assumiam que cresceriam infinitamente e que o capital seria sempre praticamente gratuito.
Com os orçamentos a apertarem, os directores financeiros e as equipas de compras estão a pressionar as empresas para consolidarem ferramentas. Isto é particularmente importante para empresas B2B. Muitos gestores de produto trabalham em empresas B2B SaaS e provavelmente estão a sofrer pressão para criarem alguma versão de todas as ferramentas em áreas adjacentes à sua.
Porquê? Por causa da consolidação. Mas existe um grande risco de dispersarmos demasiado os nossos esforços. Temos de ser muito cuidadosos e ponderados.
Devemos perguntar se existe uma oportunidade para criar uma melhor experiência de cliente através da combinação dessas ferramentas, ou se as estamos apenas a combinar por combinar. Existe realmente uma oportunidade para criar algo melhor? E, mais importante, além de criar algo melhor, há algo que estejamos particularmente bem posicionados para fazer?
Quando construímos uma versão inicial de uma ferramenta adjacente que existe há anos, por definição estaremos atrasados. Não vamos conseguir acumular anos de trabalho de um dia para o outro. Mas, se tivermos um verdadeiro factor de diferenciação e melhorarmos significativamente um fluxo de trabalho real para o consumidor final, teremos uma forma de começar a gerar valor e a superar a concorrência.
É muito importante que, ao pensar nesta tendência de consolidação de ferramentas e eliminação de silos, se reflicta cuidadosamente sobre a forma de resolver esses problemas e construir essas funcionalidades.
Hannah Clark: Fascinante. Como estamos prestes a terminar, uma pergunta completamente inesperada: o que tens na tua lista de reprodução neste momento? O que gostas de ouvir quando estás a trabalhar ou fora do trabalho?
Vijay Umapathy: Ouço muita música electrónica. Sou grande fã dos Above and Beyond, caso conheças. Já existem há imenso tempo, mas têm várias editoras. A que ouço bastante e que tem listas de reprodução no Spotify chama-se Anjunabeats e inclui muitos artistas emergentes.
Há muitas pessoas que estão apenas a começar a destacar-se nas suas carreiras e criaram todo um ecossistema de música fantástica. Normalmente, ouço isso. É o que tenho na minha lista de reprodução.
Hannah Clark: Que bom. Vou ter de ouvir. Vijay, se as pessoas quiserem acompanhar-te ou seguir o teu trabalho, onde te podem encontrar online?
Vijay Umapathy: Podem encontrar-me no Medium e no Twitter, em @vijayumapathy. E, claro, não deixem de conhecer a Heap se estiverem a criar produtos digitais; vamos ajudar-vos a tomar decisões muito rapidamente. Espero que alguns dos exemplos aqui apresentados tenham ajudado a perceber como podem fazer isso e ganhar autonomia. E não deixem o hipopótamo vencer.
Hannah Clark: Combinado. Muito obrigada por te juntares a nós. Agradecemos imenso o teu tempo.
Vijay Umapathy: Está bem, obrigado.
Hannah Clark: Obrigada por nos ouvirem. Para obterem mais informações, guias práticos e análises de ferramentas, subscrevam a nossa newsletter em theproductmanager.com/subscribe. Podem ouvir mais conversas como esta subscrevendo o The CPO Club na plataforma onde ouvem os vossos podcasts.

