> ## Content Index > Fetch the complete content index at: https://productoversee.com/llms.txt > Use this file to discover other available public pages before exploring further. # Estatística para PMs - Parte 4 - URL: https://productoversee.com/blog/estatistica-para-pms-parte-4/ - Published: 2026-01-30T17:30:25.000Z - Updated: 2026-01-30T17:33:30.000Z - Description: Nem só de passado vive o Product Manager - Author: Pablo Silva - Tags: Indicadores e Dados, Discovery, Experimentação e Testes, #blog Nas três primeiras partes desta série, nós aprendemos a olhar para o passado. Calculamos a média do nosso app de delivery, entendemos a variância das entregas e desenhamos Boxplots para ver onde os usuários se encaixavam. Nós **descrevemos** a realidade de uma amostra. Mas a vida de um Product Manager não é feita apenas de descrever o que já aconteceu. Nós somos pagos para tomar decisões sobre o futuro. - "Se liberarmos essa feature para 1 milhão de usuários, ela vai se comportar do mesmo jeito que se comportou no teste com 1.000 pessoas?" - "O tempo de entrega caiu de 30 para 29 minutos. Isso é uma melhoria real ou foi pura sorte?" Aqui termina a Estatística Descritiva e começa a **Estatística Inferencial**. Hoje vamos entender a matemática que nos permite provar uma sopa inteira provando apenas uma colherada: o **Teorema do Limite Central** e os **Intervalos de Confiança**. ## O problema da sopa (População vs. Amostra) Imagine que você está cozinhando um caldeirão gigante de sopa para um batalhão. Você precisa saber se o sal está bom. Você não bebe o caldeirão inteiro (isso seria inviável). Você mistura bem, pega uma única colher e prova. Se aquela colher estiver no ponto, você **infere** que o caldeirão todo está no ponto. No nosso App de Delivery, é a mesma coisa: - **População (o caldeirão):** todos os milhões de pedidos que já aconteceram e vão acontecer. É impossível analisar tudo em tempo real. - **Amostra (a colher):** os 500 pedidos que analisamos no teste da semana passada. A Estatística Inferencial é a garantia matemática de que a sua "colherada" não pegou, por acaso, o único pedaço de batata que estava sem sal. ## A mágica matemática: Teorema do Limite Central (TLC) Este é o conceito mais importante para validar qualquer teste A/B. Lembra da **Parte 3**? Vimos que os dados de entrega não seguem uma curva normal bonita. Eles são caóticos: a maioria entrega em 30 min, mas tem uma cauda longa de gente que demora 2 horas. Se os dados são caóticos, como podemos usar estatística para prever algo? É aqui que o TLC entra. > **O teorema:** se você tirar várias amostras aleatórias da sua base (ex: pegar a média de entrega de 50 motoboys diferentes todo dia) e colocar essas médias num gráfico, **essas médias formarão uma distribuição normal** (curva em sino), mesmo que os dados originais sejam uma bagunça. ### **Exemplo prático no delivery** Imagine que os tempos individuais de entrega são uma loucura (`[10, 15, 90, 12, 120...]`). Se você pegar **amostras de 100 pedidos** e calcular a média delas repetidamente: - Amostra A: média 28 min. - Amostra B: média 31 min. - Amostra C: média 29 min. Ao plotar essas médias, elas magicamente se organizam em um sino perfeito. ![](https://productoversee.com/content/images/2026/01/Code_Generated_Image.png) *(A linha cinza pontilhada são os dados reais dos pedidos individualmente: caóticos. A linha roxa sólida são as médias das amostras: organizadas e previsíveis.)* **Por que isso é importante para o dia a dia do PM?** Graças ao TLC, nós podemos usar a matemática padrão para calcular riscos em testes A/B. Sem ele, não poderíamos confiar que a média de um teste com 1.000 usuários representa a realidade. ## Erro Padrão: a precisão da sua colherada Na Parte 2, calculamos o **Desvio Padrão** dos nossos pedidos e descobrimos que era de **2,1 minutos**. Isso media o quanto *um pedido individual* variava. Agora, precisamos do **Erro Padrão (SE)**. Ele mede a precisão da *média do seu teste*. A fórmula é: ![](https://productoversee.com/content/images/2026/01/Screenshot-2026-01-30-at-14.18.13.png) Vamos aplicar números reais do nosso app: - **Cenário A (Discovery Rápido):** Você analisou apenas **25 pedidos**. ![](https://productoversee.com/content/images/2026/01/Screenshot-2026-01-30-at-14.18.48.png) *A sua média tem uma margem de erro grande.* - **Cenário B (Teste A/B Robusto):** Você analisou **1.600 pedidos**. ![](https://productoversee.com/content/images/2026/01/Screenshot-2026-01-30-at-14.20.04.png) *O erro é minúsculo. Sua precisão é cirúrgica.* **Algo muito muito importante:** Quanto maior o seu **N** (tamanho da amostra), menor o seu erro. É por isso que não confiamos em testes A/B que rodaram apenas por 2 horas. ## Intervalo de Confiança: o fim das certezas absolutas Números exatos em estatística ("A média é 30") quase sempre estão "errados" porque ignoram o erro padrão que calculamos acima. O jeito certo de pensar é usando **Intervalos de confiança**. Geralmente usamos o intervalo de 95%, que é, grosseiramente falando: **Média ± 2x Erro Padrão**. **Aplicando ao nosso App de Delivery:** Você rodou um experimento para otimizar rotas. - Média da Amostra: **29 minutos**. - Erro Padrão (calculado acima): **0,5 minutos**. Seu Intervalo de Confiança é: 29 **± (2 X 0,5).** Ou seja: **\[28 a 30 minutos\]**. Você diz para o stakeholder: *"Com 95% de confiança, o tempo real de entrega está entre 28 e 30 minutos."* ### **A regra de ouro da sobreposição (teste A/B na prática)** Isso resolve 90% das discussões sobre resultados de experimentos. Imagine que você está comparando a versão atual do app com uma nova versão: - **Versão A (atual):** média 30 min. Intervalo: **\[29 a 31 min\]**. - **Versão B (nova):** média 29 min. Intervalo: **\[28 a 30 min\]**. O PM afoito diria: "A versão B é 1 minuto mais rápida! Sucesso! Vamos lançar!". O PM que sabe estatística plota os intervalos e vê isto: ![](https://productoversee.com/content/images/2026/01/Code_Generated_Image--1-.png) *(A zona vermelha é onde os intervalos se cruzam. Se existe cruzamento, existe a chance real de que as duas versões sejam iguais.)* O gráfico mostra que os intervalos se sobrepõem (o intervalo de 29 a 30 minutos existe nas duas versões). Isso é um e**mpate técnico**. Estatisticamente, você não pode afirmar que a versão B é melhor. A diferença pode ter sido mero acaso. Se você lançasse essa funcionalidade achando que ganhou 1 minuto, estaria apenas adicionando complexidade ao código sem ganho real para o usuário. --- Agora você já sabe descrever seus dados e sabe calcular a margem de erro deles. Mas resta a pergunta final, o "santo graal" das decisões de produto: *"Ok, os intervalos não se cruzam e eu tenho um vencedor. Mas como eu provo que foi a minha funcionalidade que causou a melhoria e não o clima, o marketing ou o acaso? Existe relação de causa e efeito?"* Na próxima (e última) parte falarei sobre: t**este de Hipótese, valor-P e a diferença real entre correlação e causalidade.** Até lá.