Comunicando Resultados para Partes Interessadas Não Técnicas: Como Data Scientists Param de Enterrar o Ponto Principal

Da última vez que assisti à apresentação de um Data Scientist para uma CFO, o primeiro slide era uma matriz de confusão. A CFO perguntou, educadamente, o que estava vendo. Doze minutos depois, ela ainda não sabia o que fazer na segunda-feira. O modelo era bom. A apresentação foi um pequeno desastre.

Esse é o padrão de enterrar o ponto principal, e ele mata mais trabalho de DS do que código ruim jamais fará. Você passou seis semanas em um modelo de rotatividade. O executivo tem oito minutos na agenda. Se o primeiro slide não responder à pergunta que ele veio fazer, a reunião termina com um educado "vamos retomar isso depois", e o seu modelo vai para a gaveta junto com os outros.

Este guia apresenta o framework que uso e que transmito para os DS ICs júnior da minha equipe. Não se trata de simplificar demais. Trata-se de respeitar que o trabalho do executivo é decidir, não aprender ML. O seu slide ou os ajuda a decidir ou não.

O ponto principal "o que mudou?"

Toda apresentação executiva responde a uma pergunta primeiro: o que é diferente agora em comparação com o trimestre passado?

Não "como construímos o modelo". Não "a curva ROC está ótima". O que mudou no negócio, e o que devemos fazer a respeito.

O ponto principal é a primeira frase que o executivo ouve ou lê. Se você tiver que rolar para encontrá-lo, já perdeu. Compare estas duas aberturas para a mesma análise de rotatividade:

Enterrado: "Treinamos um modelo de gradient boosting em 18 meses de telemetria de contas, alcançando um AUC de 0,87 com validação cruzada de 5 dobras. A importância dos atributos sugere que a velocidade de tickets de suporte é o sinal mais forte."

Claro: "$4,2M de ARR está em alto risco de rotatividade no Q2, ante $2,8M no trimestre passado. O aumento está concentrado em 12 contas acima de $100K. Precisamos decidir hoje quais 5 o time de CSM vai ligar esta semana."

Mesmo modelo. Mesmos dados. O segundo inicia a reunião. O primeiro a encerra.

Se você não conseguir escrever a frase "o que mudou" em 30 segundos, o trabalho não está pronto para ser apresentado. Volte para o seu computador. A apresentação não consegue corrigir uma tese que você ainda não nomeou.

Um exercício útil: antes de montar um único slide, escreva o assunto do e-mail que você enviaria se o executivo perguntasse "o que você descobriu?" Se o assunto for "atualização da análise de rotatividade do Q2", isso é um relatório de status, não uma descoberta. Se for "$4,2M de ARR exposto em 47 contas; recomendo agir agora sobre as 12 principais", isso é uma descoberta. Monte o deck em torno do assunto do e-mail.

A resposta em 1 slide

Assuma que a reunião seja cortada para 90 segundos. Acontece com mais frequência do que você imagina. O CRO foi chamado para uma ligação com um cliente. A CFO tem a preparação para o conselho às 14h. Você tem um slide e um minuto e meio.

O que está nele?

Três coisas, sempre:

1. O número principal. Uma linha em negrito. O valor em dólares, o lift, a mudança. Não a metodologia.
2. A decisão necessária. O que estamos pedindo que o executivo aprove, financie ou mude? Formule como uma frase com verbo: "Aprovar a contratação de mais 2 CSMs para o grupo de alto risco" ou "Pausar o teste de precificação para o segmento SMB até a próxima semana."
3. O responsável e a data. Quem faz o quê e até quando. Sem isso, a reunião termina em clima.

Tudo o mais é apêndice. A ficha do modelo, a importância dos atributos, o desempenho no conjunto de retenção, a análise por fatia: esses vão nos slides 5 a 30, e você só os mostra se solicitado.

Peço à minha equipe que construa a resposta em 1 slide primeiro, antes de qualquer outro slide. Se você não conseguir escrevê-la, você não tem uma descoberta ainda. Você tem um status de projeto. São artefatos diferentes e vão para salas diferentes.

Uma boa resposta em 1 slide parece um memorando de decisão, não um resumo de pesquisa. A CFO pode levá-la ao chefe dela. O CRO pode encaminhá-la aos VPs dele. Se o seu slide não puder ser retirado do contexto e ainda fazer sentido, não está pronto.

Quando usar intervalos de confiança (e quando omiti-los)

Aqui está a heresia: na maioria das vezes, intervalos de confiança não pertencem ao slide.

Eu sei. Fomos treinados para sempre mostrar incerteza. E em uma revisão de DS entre pares, você deve. É assim que o trabalho é testado. Mas em uma sala de executivos, um intervalo de confiança muitas vezes produz o efeito oposto do que você pretendia. Você quis dizer "estou sendo rigoroso". Eles ouviram "você não sabe de fato". A decisão congela. Ninguém age. O modelo não mudou nada.

A regra que uso: mostre o intervalo quando a decisão muda no limite inferior. Omita-o quando não muda.

Dois exemplos.

Mostre. Um teste de precificação mostra um lift de receita de 4%, IC de 95% [-1%, 9%]. O limite inferior é negativo. A decisão muda absolutamente por causa disso. Se o efeito real for -1%, você não faz o rollout. O IC é o ponto central. Comece com ele.

Omita. Um modelo de rotatividade diz que 47 contas estão em alto risco, com um intervalo de calibração que diz "entre 41 e 53 vão realmente abandonar nos próximos 90 dias". A decisão (ligar para elas esta semana) não muda se o número for 41 ou 53. O intervalo distrai. Coloque no apêndice, mencione uma vez se perguntado: "a faixa é mais ou menos 6 contas com 90% de confiança, não muda a ação."

O custo da falsa precisão é real, mas o custo da falsa incerteza também é. Um IC de [-1%, 9%] apresentado ao lado de uma recomendação direcional dá ao executivo exatamente o sinal errado: que você está se esquivando porque não acredita no próprio número. Se você acredita na decisão direcional, tome a decisão direcional. O IC fica no apêndice onde os pares de DS podem questioná-lo.

Na dúvida, pergunte a si mesmo: "se o limite inferior fosse 20% pior, a recomendação mudaria?" Se sim, mostre o intervalo. Se não, você está mostrando para si mesmo, não para a sala.

A tensão entre "o modelo diz X mas o negócio sabe Y"

Esse é o momento que derruba DS ICs júnior. O modelo diz uma coisa. O Diretor de Vendas questiona: "não é o que estou vendo no campo." A sala se vira para você. E agora?

Não brigar pelo slide. Você vai perder, e deveria perder. O Diretor de Vendas tem contexto que o modelo não tinha.

Em vez disso, faça três coisas, em ordem:

1. Nomeie o conflito, em voz alta. "O modelo está prevendo que negócios de médio porte acima de $50K fecham 30% mais rápido quando começamos com a demo de integrações. Mike, você está dizendo que não é o que vê no campo. Vamos investigar isso. É importante."

Parece simples. É, de fato, a parte mais difícil. A maioria dos DS ICs fica em silêncio ou, pior, na defensiva. Nomear o conflito diz: confio no meu modelo, confio na sua intuição, e um de nós está perdendo algo. Vamos descobrir o quê.

2. Mostre os dados que o modelo viu. Não o algoritmo. Os dados. "Aqui estão os 340 negócios dos últimos 12 meses que alimentaram este modelo." Isso frequentemente resolve o conflito instantaneamente. O Diretor de Vendas olha os dados e diz "ah, esses são principalmente negócios inbound, minha objeção era sobre outbound, que o modelo não capturou." Agora você tem uma descoberta real: o modelo está certo para inbound, a intuição está certa para outbound, e o roadmap é construir um modelo separado para outbound ou limitar este ao inbound.

3. Pergunte o que o negócio sabe que os dados não capturaram. "Mike, o que você precisaria ver no campo para que a recomendação do modelo fizesse sentido para você?" Isso inverte a conversa de defesa para colaboração. Você não está mais defendendo o seu modelo. Está coletando atributos.

Em nove de cada dez vezes, a intuição está certa sobre algo que os dados não capturaram: uma mudança recente de estratégia, um concorrente entrando no segmento, uma mudança no plano de comissões três meses atrás que os dados ainda não absorveram completamente. Trate a objeção como um sinal gratuito. Anote. É o seu próximo atributo.

O único caso em que você deve manter sua posição: quando a objeção do Diretor de Vendas é "eu simplesmente não acredito nisso". Isso não é um contra-sinal. É desconforto em ser medido. Fique calmo, entregue os dados e deixe que ele reflita.

Traduzindo probabilidade do modelo em ação de negócio

Uma pontuação de propensão de 0,73 não significa nada para uma CFO. Pare de colocar probabilidades em slides executivos a menos que as tenha traduzido.

Traduza para uma dessas três coisas, dependendo do público:

• Dólares (para CFOs, CEOs, parceiros financeiros)
• Negócios ou contas (para líderes de vendas, CROs)
• Headcount ou horas (para COOs, líderes de operações)

Um modelo de rotatividade que diz "23% das contas estão em risco" vira:

$4,2M de ARR exposto em 47 contas. 12 delas estão acima de $100K. Se salvarmos 5 das 12 principais, recuperamos $1,7M.

Um modelo de pontuação de leads que diz "este lead tem propensão 0,84" vira:

Leads do primeiro decil fecham em 31%. Se os direcionarmos para AEs sênior, projetamos 14 negócios fechados adicionais por trimestre no nosso ASP atual, aproximadamente $980K de ARR incremental.

Uma previsão de demanda que diz "a demanda do Q3 estará 12% acima do planejado" vira:

Precisamos contratar 6 CSMs adicionais até o final do Q2 ou perderemos o SLA em 18% das novas contas.

A regra de tradução: se o seu número não terminar em dólares, negócios ou pessoas, traduza novamente. O cérebro do executivo opera nessas três unidades. Pontuações de probabilidade, percentuais de lift e ganho de informação não disparam conversas de orçamento. Dólares, sim.

Uma planilha útil que peço à minha equipe preencher antes de qualquer apresentação executiva:

Se não conseguir preencher as colunas da direita, você não tem uma descoberta executiva. Você tem um output de pesquisa. Não são a mesma coisa.

Pré-leituras para partes interessadas

O hábito de maior alavancagem que adotei em cinco anos de trabalho em DS: enviar uma pré-leitura de uma página 24 horas antes da reunião.

Não o deck. Uma página. Três bullets. A decisão que você está pedindo.

Formato que uso:

Assunto: [Decisão necessária] Risco de Rotatividade Q2, recomendo agir nas 12 principais contas esta semana

O que mudou:
- $4,2M de ARR em alto risco de rotatividade no Q2, ante $2,8M no trimestre passado
- 12 contas acima de $100K, concentradas em 5 clientes
- Principal fator: velocidade de tickets de suporte (aumento de 3x nos últimos 30 dias)

O que estou pedindo:
- Aprovar outreach de salvamento dos CSMs para as 12 principais esta semana
- Aprovar orçamento de $40K para pacote de desconto de retenção para as 5 principais
- Decisão até o fim do dia de quarta para a ação começar na quinta

O que trarei para a reunião:
- As 12 contas, pontuadas
- O rascunho do Playbook de salvamento
- O resultado projetado em 90 dias com e sem ação

Três coisas que isso faz:

1. O executivo entra na reunião já 80% a caminho de uma decisão. Ele teve tempo de pensar, de ouvir a opinião da equipe, de voltar com uma pergunta mais precisa.
2. Você descobre objeções por escrito, de forma assíncrona, onde pode abordá-las com calma. Não na hora, onde vai travar.
3. Se a reunião for cancelada (e uma em cada três reuniões executivas na minha experiência é), a decisão ainda é tomada. A pré-leitura é o artefato. A reunião é apenas a ratificação.

O erro que vejo DS ICs cometendo: eles enviam o deck como pré-leitura. O executivo abre o slide 1, vê uma matriz de confusão e fecha o e-mail. Não envie o deck. Envie a página. O deck é o apêndice.

O que deixar de fora

Coisas que não devem estar no slide para um público executivo:

• Curvas ROC
• Matrizes de confusão
• Gráficos de importância de atributos (a menos que um atributo seja toda a história e você o esteja nomeando)
• Tabelas de hiperparâmetros
• Qualquer coisa com "log-loss", "perplexidade", "divergência KL" ou "MAP" no título
• Divisões de dobras de validação cruzada
• Curvas de perda
• O diagrama de arquitetura do seu modelo
• Uma lista das bibliotecas que você usou

Se o executivo perguntar, você tem tudo isso no apêndice. Você deve ser capaz de ir ao slide 18 e responder "sim, AUC é 0,87, calibrado em um conjunto de retenção de 5 dobras". Não ofereça voluntariamente.

O critério é brutal, mas justo: se um slide não ajuda o executivo a decidir, não vai na frente do deck. Os artefatos do modelo vão para a revisão de DS entre pares, que é uma reunião diferente com um público diferente. Confundir esses públicos é como se constroem decks de 30 slides que ninguém lê.

Vou além: se você se pegar querendo mostrar a curva ROC, pergunte por quê. Geralmente é porque você está orgulhoso do modelo. Isso é justo, você deveria estar. Mas orgulho não impulsiona decisões. O número principal, sim. Mostre o número principal. A curva ROC é para o seu líder de DS.

A armadilha do "construímos um modelo que não muda nada"

O pior resultado no trabalho de DS não é um modelo errado. É um modelo correto que ninguém age.

Vi equipes publicarem belos modelos de rotatividade que ficam em um dashboard do Looker por um ano porque ninguém jamais definiu o que o time de CSM deveria fazer com eles. Vi modelos de pontuação de leads com AUC de 0,91 que produziram zero negócios fechados incrementais, porque a lógica de roteamento nunca mudou. O modelo estava certo. O loop de ação estava ausente.

Essa é a armadilha, e ela é armada antes da primeira linha de código ser escrita.

A solução está antes da comunicação. Antes de iniciar o projeto, escreva a resposta para esta pergunta: "se o modelo funcionasse perfeitamente, o que mudaria no negócio na segunda-feira?"

Se você não conseguir responder isso em uma frase, não inicie o projeto. Volte para a parte interessada. Pergunte a ela. Se ela também não conseguir responder, o projeto não está pronto.

Uma boa resposta: "O time de CSM teria uma lista classificada de contas em risco toda segunda-feira e ligaria para as 10 principais naquela semana."

Uma resposta ruim: "Entenderíamos melhor a rotatividade."

Entender não é uma ação. É um sentimento. Ninguém foi promovido por entender melhor a rotatividade. Pessoas são promovidas por reter $4M de ARR ligando para 12 contas.

Depois de ter a resposta, o restante do projeto fica mais fácil:

• O formato do output é ditado pela ação ("uma lista classificada de contas")
• A cadência é ditada pelo fluxo de trabalho ("toda segunda-feira")
• A métrica de sucesso é ditada pelo resultado de negócio ("ARR retido versus controle")
• A estratégia de comunicação é ditada por quem age ("o time de CSM, semanalmente, na revisão de pipeline existente")

Se o loop de ação é real, a comunicação se escreve sozinha. O slide diz: "aqui está a lista. Ligue para as 10 principais. Mediremos a retenção em 90 dias."

Se o loop de ação está ausente, nenhuma quantidade de polimento de slides vai salvar você. O modelo vai para a gaveta. O executivo para de comparecer às suas reuniões. O próximo Data Scientist contratado herda o mesmo modelo e o mesmo dashboard, e o ciclo se repete.

Essa é a disciplina mais difícil no trabalho de DS como IC. Quase ninguém a ensina na faculdade. A barra técnica é a barra fácil. A barra do loop de ação é o que separa os DS ICs que são promovidos dos que não são.

Saiba Mais

• Template de Descrição de Cargo para Data Scientist
• Gestão de Partes Interessadas para ICs
• Relatório de A/B Test Que Não Fica Sendo Questionado
• Quando Questionar um Brief Ruim