No começo as coisas parecem simples.
Depois elas parecem mais complicadas.
Mas a medida que vamos estudando, elas parecem simples (e óbvias) novamente.
A imagem acima, apesar de minimalista, contém muita informação por trás.
Sentimento de síndrome de impostor, sentimento de não valorizar o que sabemos.
Quem nunca pensou que o que sabia era óbvio só para descobrir depois que muita gente PAGARIA para você ensinar?
Eu certamente vivencio isso com o PAAD.
Desde que comecei essa newsletter a quantidade de artigos, livros e podcasts que consumi aumentou muito.
Afinal de contas, inspiração não cai do céu (e também não quero falar o mais do mesmo pra vocês.)
Nós, analistas, fomos ensinados a quebrar problemas em pequenas partes e descobrir o que está errado.
Mas tu sabes o que não fomos ensinados?
A sintetizar todo esse processo, a entender como o que fazemos se conecta com as atividades da empresa, a explicar o processo para diferentes stakeholders.
Ninguém liga se o seu modelo aumentou 0.5%.
O negócio quer saber como esse 0.5% vai afetar eles.
Aprendemos a destruir e não a construir.
Nesta newsletter eu vou coletar todo o conhecimento “destruído” de Produtos, Dados, Growth e Projetos que tenho e vou construir a minha visão de como eles se conectam.
Ao meu ver, agora, é óbvio como tudo está conectado.
E espero passar isso pra vocês.
Vamos lá?
O motivo dessa newsletter
Recebo muitas perguntas do tipo:
"Heitor, eu trabalho com Produto/Projetos/Growth e sou zerado em dados, eu consigo fazer a migração?”
Como eu sou alguém preguiçoso, eu decidi escrever essa newsletter.
Desse jeito eu não preciso explicar toda vez que:
Você não é zerado em dados
Essas áreas trabalham juntas e se você tem experiência em uma, tem experiência indireta nas outras.
Vamos começar por dados e ir conectando com as outras áreas durante o texto.
Dados = Alavanca de Negócios
No que eu tiver uma empresa e/ou ser head de um time dados eu vou mudar o nome da área.
Eu não gosto do termo Business Intelligence.
Esse termo induz a algumas ideias erradas para quem ta começando na área ou não entende muito do assunto.
Primeiro, o time de negócio não é burro. O time de negócios certamente sabe muito mais sobre como ganhar dinheiro para a empresa do que o time de dados.
Eles não precisam de inteligência, eles já são inteligentes.
O que eles precisam são novas ideias para alcançar o objetivo deles. Seja receita, aquisição de clientes, awareness, retenção e etc (esses termos vão voltar depois).
E é ai que o time de dados entra.
O time de dados vai procurar, ajudar na implementação, validar e monitorar se essas avalancas estão sendo usadas e estão dando ROI.
Por isso, time de Monetização de Dados me parece muito melhor.
Afinal de contas, tudo que é feito dentro de uma empresa tem como objetivo o lucro no curto e/ou longo prazo.
A mudança de paradigma acabaria com muitos efeitos indesejados que vemos no time de dados como:
A Pastelaria de Dados
Dashboards sem contexto nenhum (só mostram os infames TOP 5)
Adoção dos usuários
Perceba que só aqui já temos uma conexão com Growth (funil AAARRR), produto (implementação de melhorias) e projetos (implementação tá dentro do orçamento?).
Vamos ir pra Growth agora.
Growth = Percepção de Valor Rápida
De acordo com Elena Verna, Growth pode ser definido como:
Como você adquire, retém e monetiza clientes de forma previsível, sustentável e defensável em termos de concorrência.
Eu nunca trabalhei com times de Growth, mas pelo que eu pude estudar o time tem como objetivo fazer com que o cliente compreenda o valor do produto/serviço o mais rápido possível.
Em outros termos, fazer com que o Funil AAARRR seja percorrido rapidamente.
E como fazer isso com que isso aconteça rapidamente?
Teste y teste.
Analistas de Dados sabem fazer teste de hipótese mas você sabe o que eles não são bons? Saber o que testar.
Parece idiota, mas nos cursos os testes de hipóteses são sempre dados e a pessoa só vai calcular e verificar se é valido ou não.
Na vida real não é assim. Ninguém vai te dizer o que testar.
Saber o que testar é mais importante do que saber fazer o teste.
O profissional de Growth manja dos paranauês e consegue fazer o design de testes juntamente com o time de negócios e dados.
Esses testes giram torno das alavancas de crescimento que são:
Aquisição: Como você adquire clientes?
Retenção: Como você ativa e envolve seus clientes?
Monetização: Como você monetiza seus clientes?
Como você pode ver, é um trabalho em conjunto. Dados e Growth andam juntos.
Agora como Produto entra nessa parada?
Produto = Solução para um Problema
De acordo com Lenny Rachitsky, o trabalho de um Gestor de Produto é:
Definir o produto: Aproveite os insights dos clientes, das partes interessadas e dos dados para priorizar e criar um produto que terá o maior impacto nos negócios.
Entregar produto: Entregar um produto de alta qualidade dentro do prazo e sem surpresas.
Sincronizar as pessoas: Alinhe todas as partes interessadas em torno de uma visão, estratégia, meta, roteiro e cronograma para evitar desperdício de tempo e esforço.
O Lenny tem a maior newsletter de negócio do mundo e fala muito sobre Gestão de Produtos (inclusive recomendo) e lendo a definição dele já podemos ver as conexões com Produto, Dados e Projetos.
O Gemini me ajudou a listar algumas atividades abaixo. Perceba que se você já trabalhou com isso, a migração para qualquer uma dessas áreas é possível.
Definir o produto:
Dados:
Análise de pesquisas de clientes: Compreender as necessidades, desejos e frustrações dos clientes através de pesquisas, entrevistas e feedbacks.
Análise de dados de mercado: Identificar tendências, oportunidades e a concorrência no mercado.
Análise de dados de uso do produto: Avaliar como os clientes usam o produto e identificar pontos de melhoria.
Growth:
Priorizar features: Concentrar o desenvolvimento nas features que impactam o crescimento do negócio e a retenção de clientes.
Validar hipóteses: Testar e validar ideias de produtos com experimentos e protótipos rápidos.
Projetos:
Criar um roteiro do produto: Definir as features a serem desenvolvidas e a ordem de desenvolvimento.
Gerenciar o backlog do produto: Priorizar as features e tarefas do projeto.
Entregar o produto:
Dados:
Monitoramento de desempenho: Acompanhar o desempenho do produto e identificar problemas.
Análise de logs de erros: Diagnosticar e solucionar problemas técnicos.
Growth:
Acompanhar as taxas de conversão: Medir a efetividade do produto em converter usuários em clientes.
Análise de coorte: Identificar grupos de usuários com diferentes comportamentos e necessidades.
Projetos:
Gerenciamento de sprints: Planejar e acompanhar o desenvolvimento do produto em sprints curtos.
Gerenciamento de entregas: Garantir que o produto seja entregue dentro do prazo e do escopo.
Sincronizar as pessoas:
Dados:
Compartilhar dashboards e relatórios: Comunicar o progresso do projeto e as principais métricas de desempenho.
Realizar workshops de dados: Apresentar insights e análises para as partes interessadas.
Growth:
Definir objetivos de crescimento: Alinhar as partes interessadas em torno de objetivos de crescimento específicos.
Comunicar o valor do produto: Demonstrar como o produto contribui para o crescimento do negócio.
Projetos:
Realizar reuniões de stakeholders: Manter as partes interessadas informadas sobre o progresso do projeto.
Gerenciar expectativas: Definir expectativas claras para o projeto e comunicar as mudanças de forma transparente.
Projetos = Fazer com que isso tudo aconteça (de preferência sem riscos)
Um projeto é um conjunto de tarefas que devem ser concluídas dentro de um cronograma definido para atingir um conjunto específico de metas.
Todas as atividades que descrevemos até aqui podem fazer parte de um projeto/programa e o Gestor de Projeto é responsável com que tudo seja feito dentro do prazo, orçamento e com a qualidade esperada.
O gestor de projeto trabalha como se fosse um facilitador, faz com que a roda gire.
Um bom PM consegue transitar bem com os stakeholders de tecnologia e de negócios.
Existe uma controvérsia que diz que as empresas deveriam focar em entregar com o mindset de produto ao invés do mindset de Projeto.
Basicamente a polêmica gira em torno de que o mindset de produto tem como peça fundamental a melhoria contínua, enquanto que o projeto tem data pra começar e pra terminar.
Eu concordo com isso, no entanto, nem toda empresa tem maturidade para tal e muitas ainda trabalham com o mindset de Projetos.
Portanto, adapte-se.
Tudo tá conectado
Eu sei que parece papo de coach, mas se você entende um, você entende e consegue trabalhar nas outras áreas.
Isso não é física quântica, teoria de cordas, nada disso.
Se você entende:
Quais as alavancas de negócio
Quais as alavancas de crescimento
Como definir o Produto
Como Entregar o Produto
Como Gerenciar o Processo
Você consegue trabalhar em qualquer uma dessas áreas.
Entender isso ai acima é mais dificil do que a parte técnica. Isso querer experência e prática no campo.
A parte técnica você aprende, meu chapa.
Note que ainda dá pra ir mais a fundo nessa análise.
Branding traz mais aquisição de clientes ou aquisição de clientes deixa o branding mais forte? Como medir isso?
Dados e Branding também andam juntos.
Mas isso aí é história para outro dia.
Espero que tenha gostado da newsletter (me dá um feedback?).
Não foi tão fácil sintetizar tudo.
Bom domingo e nos vemos na próxima.
Heitor “Tudo é um e um é tudo” Sasaki
As vagas do PAAD de Março foram encerradas.
Se você perdeu o prazo, fique atento para a próxima janela de oportunidade e nos workshops.
Vamos acelerar muito nesses próximos 4 meses.
Relação simbiótica entre as áreas...
Super interessante!