Growth Teams e Product Management: quem decide quando os dois mexem na mesma tela?

Imagine uma fintech com 40 pessoas em produto. O time de Growth testa um onboarding mais curto, que adia a verificação de identidade para depois do primeiro Pix, e a ativação sobe 9% em três semanas. O teste é comemorado e vai para 100% dos usuários. Dois meses depois, o time de Produto percebe que a retenção de 60 dias caiu e que o suporte recebe o dobro de chamados sobre conta bloqueada. Ninguém errou de má-fé. Cada time otimizou a métrica que tinha, e nenhum dos dois era dono da pergunta que importava: a mudança criou clientes melhores ou só cliques mais rápidos?

Essa cena, ilustrativa mas familiar, resume o problema. Product e Growth trabalham na mesma jornada, mexem nas mesmas telas e afetam as mesmas métricas, mas pensam de jeitos diferentes. Product pensa no valor que o produto entrega, na coerência da experiência e no longo prazo. Growth pensa em trazer, ativar, reter e monetizar usuários, e em testar rápido.

Quando a empresa não desenha essa interface, a colaboração vira disputa de território. Quando desenha bem, a mesma tensão vira vantagem.

O tema ganhou peso porque o crescimento deixou de morar só em canais, CRM e mídia paga. Hoje boa parte dele acontece dentro do produto: onboarding, paywalls, loops de ativação, gatilhos de retenção, ofertas de upgrade, recomendações. E Product não pode mais definir visão e backlog sem ver como o usuário percebe esse valor em cada etapa do funil.

Em 1968, Melvin Conway observou que os sistemas que uma organização projeta tendem a copiar a estrutura de comunicação dessa organização. A lei de Conway explica por que discutir se Growth deve se reportar a Produto ou a Marketing rende pouco: o produto vai refletir as fronteiras que você desenhar, sejam quais forem.

A pergunta útil é outra. Como estruturar os dois times para que trabalhem sobre aquisição, ativação, retenção e monetização sem duplicar esforço, sem otimizações locais que prejudicam o todo e sem desacelerar o aprendizado? A resposta passa por papéis, hierarquia de métricas, governança de experimentos, direitos de decisão e um modelo adequado ao estágio da empresa.

Product e Growth dividem superfícies demais para operar sem regras claras

Poucas zonas geram tanta ambiguidade quanto onboarding, ativação, retenção inicial e monetização. O onboarding é parte central da experiência e, ao mesmo tempo, a principal superfície de ativação. O paywall é decisão de monetização, mas também de UX, de posicionamento de valor e de arquitetura de oferta. Os loops de retenção dependem de funcionalidades centrais, mas também de gatilhos, mensagens e ciclo de vida do cliente.

Quando a sobreposição não é reconhecida, a empresa cai em dois erros clássicos: várias equipes mexem na mesma tela com critérios diferentes, ou ninguém assume a responsabilidade porque todos acham que "isso é do outro time".

O conflito fica mais agudo porque os dois times trabalham com relógios diferentes. Um experimento de Growth dá resultado em semanas; o efeito sobre a lógica de valor aparece em meses, quando ninguém mais liga a queda de retenção ao teste que a provocou. O motivo é conhecido: efeitos medidos em testes curtos podem divergir dos efeitos de longo prazo, porque os usuários aprendem e mudam de comportamento depois da exposição.

Sem um mecanismo que reconcilie os dois tempos, Product parece lento e protetor demais, e Growth parece oportunista. Os dois estão reagindo à mesma lacuna: falta dizer o que cada um otimiza, em que nível e com quais limites.

Há ainda a leitura fragmentada de métricas. Growth acompanha CAC, ativação, uplift de experimentos, retenção por coorte, conversão no paywall, ARPU e recuperação de churn. Product acompanha valor percebido, adoção de funcionalidades, sucesso em tarefas, North Star Metric e profundidade de uso.

Nenhuma dessas leituras está errada. O erro aparece quando elas não pertencem a uma mesma hierarquia, e cada time passa a contar uma história diferente sobre a saúde do produto. A organização debate números em vez de aprender com eles.

Boa parte da confusão se desfaz com uma distinção simples. Product Management cria, estrutura e protege o valor central do produto. Growth acelera a descoberta, a ativação, a expansão e a captura desse valor. A distinção não elimina a sobreposição, mas a torna governável.

A colaboração melhora quando Product enxerga Growth como a função que faz o valor do produto aparecer no comportamento real dos usuários, e quando Growth enxerga Product como quem mantém o produto coerente, escalável e útil no longo prazo.

Muitas empresas erram para um dos lados: reduzem Growth a uma célula tática sem poder real, ou deixam Growth operar como força paralela que otimiza o que consegue medir sem estar acoplada à lógica do produto.

Um arranjo comum em empresas de software é dividir o trabalho em duas trilhas (o chamado dual-track). O time de produto cuida do núcleo da experiência, do valor central, da arquitetura e do roadmap de longo prazo. O time de Growth cuida do funil: roda testes, tira atritos e faz crescer, de forma medida, aquisição, ativação, retenção e receita. Isso só funciona se a divisão estiver clara. Silos não servem, e fingir que toda decisão é dividida por igual também não.

Na fintech do exemplo, essa divisão teria deixado claro desde o início: adiar a verificação de identidade mexe com valor e risco, então a decisão é de Product. Já o desenho das telas em volta dela é de Growth.

Sem hierarquia de métricas, cada time conta a sua história

Para que o acoplamento funcione, os dois times precisam ler o progresso pela mesma régua. Isso exige mais do que dashboards: exige uma hierarquia que organize como a empresa define valor, crescimento e aprendizado.

No topo fica a North Star Metric, a melhor aproximação do valor principal que o produto entrega. Métricas de vaidade e métricas locais de funil não servem para esse posto. Abaixo dela vêm as grandes alavancas: aquisição, ativação, retenção e monetização. É o território natural de Growth, mas Product precisa entender como cada uma se conecta à entrega de valor.

No terceiro nível estão as métricas de produto: adoção de funcionalidades, sucesso em tarefas, tempo até valor, fricção, satisfação. No quarto, as métricas de experimento: uplift de testes A/B, CTR, taxa de conclusão.

Veja como isso teria mudado a história do início. Suponha que a North Star da fintech seja "contas com pelo menos três transações Pix por semana após 30 dias". Antes do teste, 10.000 novos cadastros por mês geravam 4.000 ativações e 1.800 contas na North Star. Com o onboarding curto, as ativações sobem 9%, para 4.360, mas a proporção de ativados que chega à North Star cai de 45% para 37%, porque parte deles trava na verificação depois. O resultado são cerca de 1.610 contas na North Star, uns 190 a menos por mês. Com a hierarquia no lugar, o uplift de ativação nunca seria lido sozinho.

A hierarquia tem dois efeitos práticos. Impede que Growth celebre melhorias locais que não viram valor, e impede que Product vete oportunidades claras de aprendizado sob o argumento genérico de "proteger a experiência".

Ela também protege contra um risco antigo: quando um indicador vira meta cobrada, ele deixa de medir bem. O jeito mais rápido de cair nisso é transformar uma métrica do quarto nível em objetivo do trimestre. Com uma estrutura comum, a empresa passa a ter uma única linguagem com níveis de detalhe diferentes.

A experimentação precisa ser um sistema compartilhado

Saber o que vale a pena mover é metade do trabalho; a outra metade é aprender a mover. Growth costuma ser o motor da experimentação, mas em organizações maduras ela funciona como um sistema operacional compartilhado entre Product, Growth, Data, Design e Engenharia.

Isso significa templates de hipótese, critérios de priorização, regras estatísticas, protocolos de QA, regras de rollout, registro de decisões e um repositório de aprendizados.

Por que a memória importa tanto? Porque a maior parte dos testes não ganha, mesmo em times experientes.

Faça a conta para uma empresa que roda 120 testes por ano: se 15% vencem, são 18 ganhadores e 102 testes que não deram certo. Se esses 102 não ficam registrados, com hipótese, segmento e resultado, alguém vai repetir boa parte deles daqui a um ano com outro nome. O repositório é o que transforma derrotas em aprendizado barato. Basta uma linha por teste com cinco campos: hipótese, segmento, métrica principal, resultado com intervalo de confiança e a decisão tomada. Preencher leva dois minutos; não preencher costuma custar um trimestre de testes repetidos.

Sem esse sistema, a empresa roda muitos testes e aprende pouco. Alguns resultados são difíceis de interpretar, outros não se conectam à estratégia, outros geram ganhos de curto prazo que criam dívida de UX ou dívida técnica.

Growth precisa de velocidade, e Product precisa garantir que a velocidade não destrua a coerência. O equilíbrio vem de um sistema disciplinado.

Ferramentas de análise experimental ajudam a padronizar a leitura, sem tirar do time a interpretação. Isso conta porque boa parte da tensão nasce quando um teste parece "ganhador" para um time e "irrelevante" ou "perigoso" para o outro. Com padrões de avaliação definidos antes do teste (métrica principal, salvaguarda, duração mínima), o debate fica sobre a decisão.

Quem decide o quê precisa estar escrito

Antes de cada teste, alguém precisa ter a palavra final. Quem decide a UX principal do onboarding? Quem aprova um experimento de ativação? Quem é dono do modelo de assinatura e do paywall? Quem pode testar preços, e em quais condições? Quando isso fica implícito, cada tema vira uma negociação política.

Uma matriz de direitos de decisão resolve boa parte disso, desde que seja revisada quando o produto muda. Ela não precisa ser formal demais, mas precisa deixar explícito quem decide, quem é consultado e quem executa.

Em geral, Product é o decisor natural da arquitetura do onboarding e da UX principal. Growth lidera o desenho e a execução dos experimentos de ativação. Em assinatura e paywall, a responsabilidade costuma ser compartilhada. Em pricing, Product detém a estratégia, e Growth valida experimentalmente junto com o time comercial (GTM).

Matriz de direitos de decisão (um ponto de partida)

A regra por trás da matriz é simples: quem protege o sistema decide arquitetura e valor; quem acelera o aprendizado decide o desenho e a cadência dos testes, dentro desses limites. Quando uma superfície não cabe com clareza em nenhuma linha, ela precisa de responsabilidade compartilhada explícita, com um critério de desempate escrito.

Um bom critério de desempate é a própria hierarquia de métricas: em caso de empate, vence a opção que protege a North Star.

Essa clareza reduz ruído e acelera a execução. Em vez de reabrir cada conflito do zero, a organização passa a operar com protocolos. Em empresas maiores, a colaboração depende menos de boa vontade e mais de mecanismos definidos.

Com a matriz no lugar, fica mais fácil descrever quem faz o quê no dia a dia. O PM continua guardião da estratégia de produto, da proposta de valor e da visão de longo prazo. Ele define os problemas do usuário, garante a coerência entre funcionalidades, trabalha com engenharia pela escalabilidade e evita que otimizações pontuais criem máximos locais que degradam o todo.

O trabalho dele é manter o crescimento ligado à lógica do produto, o que pouco tem a ver com bloquear Growth.

O Growth PM é um PM especializado no funil e em aprender com testes. Ele tira atritos, melhora o onboarding e as mensagens, acelera os testes e acompanha em quanto tempo o custo de aquisição (CAC) se paga. Também procura formas de reter e monetizar que dá para validar rápido.

Trabalha com design, analytics, engenharia e marketing, e o que se espera dele vai além de "pedir experimentos": construir ganho mensurável contínuo sem desconectar o trabalho da experiência central.

Os engenheiros de Growth dão a velocidade: montam a estrutura de testes, as variantes, a medição e as chaves que ligam e desligam funcionalidades (feature flags). Cientistas de dados e analistas checam se o teste prova mesmo o que parece provar: se o sorteio dos grupos foi correto, quem viu cada versão e onde os dados são fracos. Design mantém a experiência coerente mesmo com tantos testes rodando.

Marketing e Lifecycle Ops levam o sistema para aquisição, CRM e reengajamento, incluindo o WhatsApp, que em muitas empresas brasileiras é canal de ativação tão importante quanto o e-mail. Quando esses papéis se conectam a uma mesma lógica de resultado, o sistema funciona. Quando se conectam só pelo organograma, a coordenação quebra.

A estrutura certa depende do tamanho e do estágio

Não existe estrutura ideal única, e quem procura uma fórmula costuma copiar o organograma de outra empresa sem o contexto que o justificava.

Em empresas de porte médio, funciona bem colocar Growth dentro dos squads de produto. Isso espalha a mentalidade experimental e aproxima Growth das superfícies reais da experiência. O risco é duplicar esforço e perder consistência, por isso costuma exigir alguma coordenação central.

Em empresas maiores, um time central de Growth aumenta a disciplina experimental: padroniza práticas, mantém infraestrutura, garante qualidade. Sem interfaces bem desenhadas, porém, vira estrutura paralela ao produto. O modelo híbrido de Product-Led Growth costuma equilibrar as duas coisas: especialistas de Growth ficam perto dos squads, enquanto uma função central de PLG define padrões, compartilha aprendizados e protege a coerência.

Matthew Skelton e Manuel Pais, em "Team Topologies" (2019), dão vocabulário para isso: os squads são times alinhados ao fluxo de valor, e o time central funciona como plataforma ou time habilitador, que existe para reduzir a carga dos outros.

Há ainda empresas que organizam o trabalho por missões, e não por função. Squads de ativação, retenção ou monetização têm responsabilidade conjunta entre PM e Growth. O desenho alinha a responsabilidade ao resultado, mas exige mais maturidade em métricas, em decisão e em coordenação.

Como escolher? Uma regra prática, para começar: com menos de cinco squads, Growth embutido e uma pessoa responsável pela infraestrutura de testes costumam bastar. De cinco a quinze squads, o modelo híbrido compensa, porque a duplicação de testes começa a custar caro.

Acima disso, ou quando há várias linhas de produto, missões com donos conjuntos tendem a funcionar melhor que funções. Se a sua empresa roda menos de um teste por squad por mês, a estrutura ainda não é o gargalo; a infraestrutura de experimentos é.

Organograma nenhum cria colaboração sozinho. Ela aparece nos rituais: revisão semanal do funil, planejamento conjunto do roadmap de experimentos, sincronização mensal de estratégia, recalibração trimestral de métricas e retrospectivas de testes. Uma cadência enxuta cabe em cerca de 3 horas por mês para cada PM: 30 minutos semanais de funil e 1 hora mensal de estratégia. São esses encontros que transformam Product e Growth de áreas vizinhas em um sistema de trabalho compartilhado.

Um fluxo bem desenhado segue uma lógica simples. O PM detecta uma fricção no onboarding ou em outra etapa crítica. O Growth PM transforma essa fricção em backlog de experimentos. O Growth engineer implementa variantes dentro de limites definidos. O analista mede.

O PM avalia riscos de UX, de compliance (LGPD, prevenção a fraude) e de arquitetura. O teste roda. A decisão de escalar, iterar ou descartar é tomada em conjunto, com base em uma leitura comum.

Essa cadência reduz a dependência de alinhamentos improvisados. As diferenças continuam, mas a organização sabe como processá-las sem reabrir a discussão a cada sprint.

Um ritual merece atenção especial: a revisão de 60 dias. Todo teste que foi para 100% volta à pauta dois meses depois, com a métrica de retenção do segmento afetado. É o ritual que teria pego o problema da fintech antes do suporte.

Growth loops mostram onde um time precisa do outro

É nos loops de crescimento que essa cadência se paga. Num loop, a saída de um usuário vira entrada para o próximo; um funil linear precisa ser alimentado sempre pelo topo.

A ideia ajuda a ver por que a separação rígida entre Product e Growth é tão limitada.

Em loops de aquisição, o PM define a proposta de valor e Growth domina distribuição e canais. Em loops de ativação, Growth ajusta fluxos e fricções, enquanto Product garante que o usuário chegue ao valor certo, e não a um clique qualquer. Em loops de retenção, Product cria motivos para voltar, e Growth calibra gatilhos, horário e mensagens. Em loops de monetização, Product define a estratégia de valor e preço, e Growth valida disposição a pagar, elasticidade e impacto no ARPU.

Pense num loop de indicação numa conta digital: o usuário que recebe um Pix de um amigo é convidado a abrir conta. Product decide se o convite aparece e em que momento da experiência; Growth testa a mensagem e o incentivo. Suponha que 1.000 convites gerem 80 contas novas e que 30 delas cheguem à North Star em 30 dias. Um incentivo que dobra as contas para 160, mas mantém as mesmas 30 na North Star, só comprou cadastros. Se um dos dois decide sozinho, o loop quebra.

Diante disso, a imagem de Growth como função externa que "liga o motor" depois que o produto está pronto não se sustenta. Growth faz parte da forma como o valor do produto se manifesta, se ativa e se expande, e o design organizacional precisa reconhecer essa interdependência.

Onde a colaboração entre Product e Growth desanda

Os sintomas se repetem de empresa para empresa, e um puxa o outro. Tudo começa com KPIs conflitantes. Sem régua comum, Growth opera em paralelo à estratégia e colhe ganhos locais à custa de perdas sistêmicas. Product reage e, sem salvaguardas claras, a reação vira bloqueio: qualquer teste parece ameaça.

Para contornar o bloqueio, as responsabilidades se sobrepõem, o que produz mais política do que resultado, e a falta de governança de experimentos fecha o ciclo com muitos testes e pouco aprendizado.

Cada sintoma tem um sinal que dá para checar. Se o número de testes sobe e a North Star fica parada por dois trimestres, os testes estão otimizando o nível quatro da hierarquia. Se o tempo entre a ideia e o lançamento de um teste passa de três semanas, Product provavelmente virou gargalo de aprovação. Se a mesma tela tem dois tickets abertos por times diferentes, a matriz não está sendo usada.

Muita gente de Growth vai dizer que tanta governança mata a velocidade, e que a vantagem do time está justamente em testar sem pedir licença. Em startups com um único squad e menos de um ano de produto, têm razão: o custo de coordenação supera o custo dos erros.

O argumento perde força quando o produto tem usuários suficientes para que um teste ruim afete milhares de pessoas, ou quando há risco regulatório no fluxo, como verificação de identidade, crédito ou dados pessoais protegidos pela LGPD. A partir daí, regras escritas são o que permite testar rápido sem pedir licença a cada vez.

Em fases de escala, as ferramentas de avaliação de competências ajudam a mapear se o problema está na estrutura, nas competências ou em gaps de maturidade dos times. Em horizontes mais longos, ferramentas de modelagem servem para modelar cenários de crescimento e portfólio, para que a conversa entre Product e Growth não fique presa ao próximo experimento.

O ponto de partida mais barato é a matriz de direitos de decisão. Basta listar as superfícies onde Product e Growth se encontram (onboarding, ativação, paywall, pricing, salvaguardas) e preencher quem decide, quem é consultado e quem executa, com os dois times na mesma sala. As linhas que geram discussão na sala são as que hoje viram negociação política, e é por elas que a matriz começa.

Depois vem a régua. Se Growth comemora um uplift que nunca aparece na North Star, ou se Product veta testes sem apontar o risco concreto, a hierarquia de métricas ainda não funciona, por mais bonito que seja o dashboard. Só então faz sentido discutir estrutura.

Na fintech da abertura, a perda de cerca de 190 contas por mês na North Star equivale a mais de 2.200 contas em um ano. Nenhum organograma teria evitado isso sozinho. Uma regra teria: nenhum teste vai para 100% sem data marcada para reler a retenção de 60 dias do segmento afetado.