Prova em números: usando Big Data para gerar resultados

Publicados: 2022-07-22

Em um determinado ponto de sua carreira como gerente de produto, você pode enfrentar problemas de grande escala que são menos definidos, envolvem causas e áreas de impacto mais amplas e têm mais de uma solução. Quando você se encontra trabalhando com conjuntos de dados complexos — quando começa a pensar em números na casa dos milhões em vez dos milhares —, você precisa das ferramentas certas para permitir a expansão na mesma taxa.

É aqui que o gerenciamento de produtos orientado por dados pode gerar um tremendo valor comercial. Nos exemplos a seguir, extraídos de casos em minha própria carreira, a aplicação de análise de dados a problemas aparentemente intratáveis ​​produziu soluções que trouxeram enormes retornos para meus empregadores – variando de milhões de dólares a centenas de milhões.

Adquirir habilidades em ciência de dados pode ajudar a criar o próximo caminho de crescimento em sua carreira de gerenciamento de produtos. Você resolverá problemas mais rapidamente do que seus colegas, transformará insights baseados em evidências em retornos concretos e fará grandes contribuições para o sucesso de sua organização.

Aproveite os dados em grande escala

A aplicação da ciência de dados no gerenciamento de produtos e na análise de produtos não é um conceito novo. O que é novo é a quantidade impressionante de dados que as empresas têm acesso, seja por meio de suas plataformas, software de coleta de dados ou dos próprios produtos. E, no entanto, em 2020, a Seagate Technology informou que 68% dos dados coletados pelas empresas não são alavancados. Um white paper da IBM de 2014 comparou esse desperdício de dados a “uma fábrica onde grandes quantidades de matérias-primas permanecem sem uso e espalhadas em vários pontos ao longo da linha de montagem”.

Os gerentes de produto com habilidades em ciência de dados podem aproveitar esses dados para obter insights sobre as principais métricas, como ativação, alcance, retenção, engajamento e monetização. Essas métricas podem ser direcionadas para uma variedade de tipos de produtos, como comércio eletrônico, conteúdo, APIs, produtos SaaS e aplicativos móveis.

Em suma, a ciência de dados é menos sobre quais dados você coleta e mais sobre como e quando você os usa, especialmente quando está trabalhando com números novos e de ordem superior.

Mergulhe nos dados para encontrar as causas-raiz

Vários anos atrás, trabalhei em um provedor de tecnologia de viagens com mais de 50.000 clientes ativos em 180 países, 3.700 funcionários e US$ 2,5 bilhões em receita anual. Em uma corporação desse tamanho, você está gerenciando grandes equipes e grandes quantidades de informações.

Quando comecei a trabalhar lá, me deparei com o seguinte problema: apesar de ter roadmaps atualizados e backlogs completos, a pontuação do NPS caiu e a rotatividade de clientes aumentou em dois anos. Os custos associados ao suporte ao cliente cresceram significativamente e os departamentos de suporte estavam constantemente combatendo incêndios; durante esses dois anos, as chamadas de suporte quadruplicaram.

Nos meus primeiros três meses, estudei como o negócio funcionava, desde a negociação de suprimentos até a resolução de reclamações. Conduzi entrevistas com a vice-presidente de produto e sua equipe, em contato com VPs das equipes de vendas e tecnologia, e conversei extensivamente com o departamento de suporte ao cliente. Esses esforços renderam insights úteis e permitiram que minha equipe desenvolvesse várias hipóteses, mas não forneceram dados concretos para respaldá-las ou estabelecer bases para rejeitá-las. Possíveis explicações para a insatisfação do cliente incluem a falta de recursos, como a capacidade de editar pedidos depois que eles foram feitos; necessidade de produtos complementares; e assistência técnica e/ou informações sobre o produto insuficientes. Mas mesmo que pudéssemos decidir sobre um único curso de ação, persuadir os vários departamentos a acompanhá-lo exigiria algo mais firme do que uma possibilidade.

Em uma empresa menor, eu poderia ter começado realizando entrevistas com clientes. Mas com uma base de usuários finais na casa das centenas de milhares, essa abordagem não era útil nem viável. Embora isso tivesse me dado um mar de opiniões – algumas válidas – eu precisava saber que as informações com as quais estava trabalhando representavam uma tendência maior. Em vez disso, com o apoio da equipe de inteligência de negócios, extraí todos os dados disponíveis do call center e dos departamentos de suporte ao cliente.

Os casos de suporte dos seis meses anteriores chegaram a mim em quatro colunas, cada uma com 130.000 linhas. Cada linha representava uma solicitação de suporte ao cliente e cada coluna era rotulada com a área do problema do cliente à medida que avançava no processo de atendimento. Cada coluna tinha entre 11 e 471 rótulos diferentes.

Uma ilustração intitulada "Dados de suporte ao cliente". A ilustração representa 130.000 linhas nas quais os dados foram documentados, com quatro colunas de áreas problemáticas, identificadas como Primeira Área Problema, Segunda Área Problema, Terceira Área Problema e Quarta Área Problemática. O número de rótulos de área problemática em cada coluna é anotado como 11 rótulos, 58 rótulos, 344 rótulos e 471 rótulos, respectivamente.
Dados de suporte ao cliente, compreendendo 130.000 casos individuais, cada um com quatro áreas problemáticas.

A aplicação de filtros e a classificação do enorme conjunto de dados não produziu resultados conclusivos. Os rótulos de problemas individuais eram inadequados para capturar o quadro maior. Um cliente pode ligar inicialmente para redefinir sua senha e, embora essa chamada seja registrada como tal, um problema raiz diferente pode se tornar evidente depois que todos os quatro problemas forem considerados como uma sequência. Em 130.000 linhas com milhões de strings possíveis, procurar padrões revisando cada linha individualmente não era uma opção. Ficou claro que identificar o problema nessa escala era menos fornecer insights de negócios e mais comparável a resolver um problema de matemática.

Para isolar as strings que ocorrem com mais frequência, usei amostragem de probabilidade proporcional ao tamanho (PPS). Este método define a probabilidade de seleção de cada elemento para ser proporcional à sua medida de tamanho. Embora a matemática fosse complexa, em termos práticos, o que fizemos foi simples: amostramos casos com base na frequência de cada rótulo em cada coluna. Uma forma de amostragem em vários estágios, esse método nos permitiu identificar sequências de problemas que pintavam uma imagem mais vívida do motivo pelo qual os clientes estavam ligando para o centro de suporte. Primeiro, nosso modelo identificou o rótulo mais comum da primeira coluna, depois, dentro desse grupo, o rótulo mais comum da segunda coluna e assim por diante.

Uma ilustração intitulada "Dados de suporte ao cliente após amostragem PPS". A ilustração representa 130.000 linhas nas quais os dados foram documentados, com quatro colunas de áreas problemáticas, identificadas como Primeira Área Problema, Segunda Área Problema, Terceira Área Problema e Quarta Área Problemática. O número de rótulos de área problemática em cada coluna é anotado como 11 rótulos, 58 rótulos, 344 rótulos e 471 rótulos, respectivamente. Além disso, caixas destacadas são adicionadas para representar a identificação de rótulos de ocorrência comum em cada área problemática.
Dados do centro de suporte ao cliente após a aplicação da amostragem PPS, com as sequências de rótulos que ocorrem com mais frequência identificadas.

Após a aplicação da amostragem PPS, isolamos 2% das causas-raiz, que representaram cerca de 25% do total de casos. Isso nos permitiu aplicar um algoritmo de probabilidade cumulativa, que revelou que mais de 50% dos casos se originaram de 10% das causas-raiz.

Essa conclusão confirmou uma de nossas hipóteses: os clientes estavam entrando em contato com a central de atendimento porque não tinham como alterar os dados do pedido após o pedido ter sido feito. Ao corrigir um único problema, o cliente poderia economizar US$ 7 milhões em custos de suporte e recuperar US$ 200 milhões em receita atribuída à perda de clientes.

Realize Análises em Tempo Real

O conhecimento de aprendizado de máquina foi particularmente útil para resolver um desafio de análise de dados em outra empresa de viagens de tamanho semelhante. A empresa serviu como uma ligação entre hotéis e agências de viagens em todo o mundo por meio de um site e APIs. Devido à proliferação de mecanismos de metabusca, como Trivago, Kayak e Skyscanner, o tráfego da API cresceu três ordens de magnitude. Antes da proliferação da metapesquisa, a proporção look-to-book (total de pesquisas de API para total de reservas de API) era de 30:1; após o início das metabuscas, alguns clientes atingiriam uma proporção de 30.000:1. Durante os horários de pico, a empresa precisava acomodar até 15.000 solicitações de API por segundo sem sacrificar a velocidade de processamento. Os custos do servidor associados à API cresceram de acordo. Mas o aumento do tráfego desses serviços não resultou em aumento nas vendas; as receitas permaneceram constantes, criando uma enorme perda financeira para a empresa.

A empresa precisava de um plano para reduzir os custos do servidor causados ​​pelo aumento de tráfego, mantendo a experiência do cliente. Quando a empresa tentou bloquear o tráfego para clientes selecionados no passado, o resultado foi PR negativo. Bloquear esses motores, portanto, não era uma opção. Minha equipe recorreu aos dados para encontrar uma solução.

Analisamos aproximadamente 300 milhões de solicitações de API em uma série de parâmetros: hora da solicitação, destino, datas de check-in/out, lista de hotéis, número de hóspedes e tipo de quarto. A partir dos dados, determinamos que certos padrões estavam associados a picos de tráfego de metabusca: hora do dia, número de solicitações por unidade de tempo, pesquisas alfabéticas em destinos, listas ordenadas de hotéis, janela de pesquisa específica (datas de check-in/out) e configuração do convidado.

Aplicamos uma abordagem de aprendizado de máquina supervisionado e criamos um algoritmo semelhante à regressão logística: calculou uma probabilidade para cada solicitação com base nas tags enviadas pelo cliente, incluindo carimbo de data/hora delta, carimbo de data/hora, destino, hotel(s), datas de check-in/out e número de hóspedes, bem como as etiquetas dos pedidos anteriores. Dependendo dos parâmetros fornecidos, o algoritmo identificaria a probabilidade de uma solicitação do servidor de API ter sido gerada por um humano ou por um mecanismo de metabusca. O algoritmo seria executado em tempo real quando um cliente acessasse a API. Se determinasse uma probabilidade alta o suficiente de que a solicitação fosse conduzida por humanos, a solicitação seria enviada ao servidor de alta velocidade. Se parecesse ser uma metabusca, a solicitação seria desviada para um servidor de armazenamento em cache que fosse mais barato de operar. O uso do aprendizado supervisionado nos permitiu ensinar o modelo, levando a uma maior precisão ao longo do desenvolvimento.

Esse modelo forneceu flexibilidade porque a probabilidade poderia ser adaptada por cliente com base em regras de negócios mais específicas do que aquelas que usávamos anteriormente (por exemplo, reservas esperadas por dia ou nível de cliente). Para um cliente específico, as solicitações podem ser direcionadas em qualquer ponto acima de 50% de probabilidade, enquanto para clientes mais valiosos, poderíamos exigir mais certeza, direcionando-os quando ultrapassassem um limite de 70% de probabilidade.

Uma ilustração intitulada “Classificando clientes por meio de um algoritmo de aprendizado de máquina”. Esta ilustração é um fluxograma que mostra os caminhos possíveis pelos quais as solicitações são classificadas dependendo de seu ponto de origem. O início do fluxograma tem duas origens possíveis, “Internet Users” e “Metasearches”. Ambos levam a “XML, API Server”. Isso leva à “Pesquisa Natural?” Se o resultado for "Sim", a próxima etapa é "Servidor de alta velocidade". Se o resultado for "Não", a próxima etapa será "Servidor de cache". Depois disso, ambos são levados de volta para “XML, API Server”.
O caminho pelo qual as solicitações foram classificadas para o servidor de alta velocidade ou o servidor de armazenamento em cache, dependendo do ponto de origem.

Depois de implementar o algoritmo de classificação, a empresa desviou até 70% das solicitações dentro de um determinado período de tempo para a pilha mais barata e economizou cerca de US$ 5 milhões a US$ 7 milhões por ano em custos de infraestrutura. Ao mesmo tempo, a empresa satisfez a base de clientes ao não rejeitar o tráfego. Ele preservou o índice de reservas ao mesmo tempo em que protegeu a receita.

Use as ferramentas certas para o trabalho

Esses estudos de caso demonstram o valor de usar a ciência de dados para resolver problemas complexos de produtos. Mas onde sua jornada de ciência de dados deve começar? É provável que você já tenha uma compreensão básica das áreas de conhecimento amplas. A ciência de dados é uma atividade interdisciplinar; engloba o pensamento profundamente técnico e conceitual. É o casamento de grandes números e grandes ideias. Para começar, você precisará aprimorar suas habilidades em:

Programação. A linguagem de consulta estruturada, ou SQL, é a linguagem de programação padrão para gerenciar bancos de dados. Python é a linguagem padrão para análise estatística. Embora os dois tenham funções sobrepostas, em um sentido muito básico, o SQL é usado para recuperar e formatar dados, enquanto o Python é usado para executar as análises para descobrir o que os dados podem lhe dizer. O Excel, embora não seja tão poderoso quanto o SQL e o Python, pode ajudá-lo a atingir muitos dos mesmos objetivos; você provavelmente será chamado a usá-lo com frequência.

Pesquisa operacional. Depois de ter seus resultados, e daí? Toda a informação do mundo é inútil se você não souber o que fazer com ela. A pesquisa operacional é um campo da matemática dedicado à aplicação de métodos analíticos à estratégia de negócios. Saber como usar a pesquisa operacional ajudará você a tomar decisões de negócios sólidas apoiadas por dados.

Aprendizado de máquina. Com a IA em ascensão, os avanços no aprendizado de máquina criaram novas possibilidades para a análise preditiva. O uso comercial da análise preditiva aumentou de 23% em 2018 para 59% em 2020, e o mercado deverá experimentar um crescimento anual composto de 24,5% até 2026. Agora é a hora dos gerentes de produto aprenderem o que é possível com a tecnologia.

Visualização de dados. Não basta entender suas análises; você precisa de ferramentas como Tableau, Microsoft Power BI e Qlik Sense para transmitir os resultados em um formato que seja fácil de entender para os interessados ​​não técnicos.

É preferível adquirir essas habilidades por conta própria, mas, no mínimo, você deve ter a familiaridade necessária para contratar especialistas e delegar tarefas. Um bom gerente de produto deve conhecer os tipos de análises possíveis e as perguntas que podem ajudar a responder. Eles devem ter uma compreensão de como comunicar perguntas aos cientistas de dados e como as análises são realizadas, além de serem capazes de transformar os resultados em soluções de negócios.

Exerça o poder de gerar retornos

A Pesquisa Executiva de Liderança de Dados e IA de 2022 da NewVantage Partners revela que mais de 90% das organizações participantes estão investindo em iniciativas de IA e dados. A receita gerada por big data e análise de negócios mais que dobrou desde 2015. A análise de dados, antes uma habilidade especializada, agora é essencial para fornecer as respostas certas para empresas em todos os lugares.

Um gerente de produto é contratado para gerar retornos, determinar a estratégia e obter o melhor trabalho dos colegas. Autenticidade, empatia e outras habilidades sociais são úteis nesse sentido, mas são apenas metade da equação. Para ser um líder dentro de sua organização, traga fatos para a mesa, não opiniões. As ferramentas para desenvolver insights baseados em evidências nunca foram tão poderosas e os retornos potenciais nunca foram maiores.