Porque todo Analista de Dados deveria ser um Product Manager

Nesses últimos dois anos, estive completamente imerso no dia a dia de uma área de Produtos. Participei de diversos rituais diferentes que até então eram novidades na minha carreira e, por isso, sempre fui muito curioso para entender mais sobre as dinâmicas, pessoas e processos dessa área.

Nessa jornada, também tive a oportunidade de conhecer muitos produteiros incríveis que, talvez até sem perceberem, me inspiraram (e seguem inspirando) de diversas formas no meu desenvolvimento de carreira.

Para me aprofundar um pouco mais no tema, eu recentemente terminei um curso bem interessante de Product Management da Escola PM3 e ai resolvi trazer 5 pontos para te convencer do porquê que todo Analista de Dados deveria ser um pouco mais produteiro em seu dia a dia.

1) “Putting myself in my main stakeholders shoes”

Eu tentei procurar outra expressão para explicar isso, mas essa em inglês foi a que mais serviu. A adaptação seria algo do tipo "veja da perspectiva deles". Mas o ponto é: os PMs são os meus principais stakeholders. São as pessoas que frequentemente me pedem ajuda. As que estão construindo de fato o que a empresa é, tendo muitas vezes uma interface direta com os próprios clientes e que, por conta disso, têm insumos suficientes para direcionar análises e fornecer feedbacks valiosos.

Com o curso, pude entender como os meus stakeholders são treinados para serem quem são. Me tornei mais empático e talvez até menos ansioso, porque agora entendo melhor os seus desafios diários. Vi melhor as suas motivações e o que diferencia produteiros excepcionais de produteiros medianos, o que é algo realmente importante para mim, porque eu talvez possa tentar contribuir nos seus desenvolvimentos pessoais.

Quando o assunto são stakeholders, saber “quem são, o que fazem, o que comem e onde vivem” passa a ser então algo fundamental para um Analista de Dados e, se você assim como eu também atua na área de produtos, navegar bem pelo entorno dos produteiros não é um diferencial, mas sim, uma obrigação.

2) PMs comem a VISÃO e a ESTRATÉGIA no café da manhã

Eu sei, eu sei… Temos muitas áreas importantes e que participam desse processo, mas as lideranças de produto são AS PESSOAS que tangibilizam as diretrizes globais de uma empresa. Não tem discussão, essas pessoas intrinsecamente são as que mais pensam no “ONDE QUEREMOS CHEGAR?” e fazem isso em cada reunião de planejamento e em cada dia de trabalho.

Aprendi que os PMs, nesse processo, ajudam no cascateamento dessas ideologias. Eles são as pessoas que conseguem conectar os outros colaboradores a essa tal da visão e à estratégia. Conseguem reforçar esses pontos em cada feature lançada, relembrando as pessoas que as constroem do propósito dos seus produtos.

Nós naturalmente não somos assim. Analistas de Dados geralmente têm um perfil mais técnico. Estamos bem preocupados com o HOW, com que técnicas serão utilizadas e, sinceramente, até dominamos isso. Mas nessa onda do extremismo, nos preocupamos menos com o WHY (por que temos que fazer isso?) e ainda menos com o THEN (o que recomendo que você faça, dada a minha análise). E sabemos disso, tá? O Business Acuman é o termo da moda, mas ainda existe muito trabalho a ser feito.

3) PMs dominam a gestão de stakeholders, alinhamento de expectativas e a comunicação, nós não.

Foram diversos módulos do curso que de alguma forma tratavam sobre isso. Gerenciar stakeholders é um dos super poderes de um bom PM. Aprendi que isso envolve desde um mapeamento de quem são os seus stakeholders, entendendo a influência e as necessidades que eles têm e construindo talvez até uma matriz RACI para te ajudar a entender quando e como você deve se comportar com eles.

Mas isso segue também para uma importante parte de co-criação de iniciativas, para que os stakeholders realmente acreditem e deem buy-in no que você está desenvolvendo, e isso ainda segue com o alinhamento de expectativas, para comunicar e mantê-los engajados com o desenvolvimento de tudo e também satisfeitos com as entregas parciais e evoluções necessárias.

É um baita desafio, até para PMs. Mas definitivamente também não é algo que em Dados dominamos, apesar de parecer ser algo fundamental para nós que trabalhamos com diversas pessoas e entregas. Mas adivinha? Isso não se ensina em NENHUM curso sobre Análises de Dados. risos.

4) PMs amam frameworks!

Na real, se você é um PM que está lendo esse artigo, por favor, depois me diga: Você ama ou odeia frameworks? Brincadeiras à parte, com certeza você não vive sem! PMs são os guardiões das metodologias ágeis. Se você está no início de alguma ideia de negócio, vão te sugerir um Lean Canvas. E, se você já está numa fase mais avançada do seu produto, vão te sugerir seguir num Kanban ou Scrum da vida! É quase uma seita!

Para mim, nunca faltou um ritual macabro de Refiniment, Planning, Daily, Sprint Review ou Retrospective. Tem nome para tudo e eu amo muito tudo isso. E não basta só nomear uma reunião com esses nomes, viu? Tem que viver cada uma delas. Cada reunião tem o seu propósito, tem o seu requisito e tem a sua expectativa. E as coisas curiosamente funcionam. Ou às vezes não também, e está tudo bem. Errar rápido é o mantra. Depois? Evoluir e adaptar.

Sigo pensando: ainda temos muito que aprender.

5) Nós também construímos PRODUTOS, apesar de frequentemente esquecermos disso.

Vamos falar um pouco mais sobre nós agora… Fazemos EDAs, Dashboards e Modelos de machine learning muito chiques e avançados. Mas e depois? Aliás, por que fizemos eles? Será que alguém está utilizando isso? Quem consome, gosta da forma que está consumindo? Chegou a hora de anunciar o encerramento do suporte? Ou ainda precisamos incentivar o uso, construir documentações, tutoriais em vídeo e publicar alguns exemplos de grandes insights que podem ser percebidos, incentivando seu uso?

Isso é Produto! Nós também entregamos produtos! Mas não pensamos nas responsabilidades que entregar um produto envolve. Os PMs sim. É uma obrigatoriedade, um Definition of Done de qualquer coisa que eles fazem, e isso é muito massa! Deveríamos ter muita atenção com priorização (utilizando MosCow, Kano Model, PICK, GUT), mas também entender sobre como entregar valor, de forma recorrente e no pós-Release de nossas features. Mesmo que isso signfique um Sunset do seu dashboardzinho.

Uma lista de itens de Backlog que foram movidos para Done não deveria ser um motivo de promoção, mas entender o real impacto do que você está causando com suas análises, sim.

O desafio

Isso não é uma espécie de Manifesto Ágil para Analistas de Dados, nem caberia a mim fazê-lo. Nem espero que seja uma verdade absoluta sobre todos os analistas de dados aqui genalizados. Eu mesmo não sei se me encaixo em todos esses pontos de melhoria. Aliás, espero que não. Tenho tentando melhorar a cada dia.

Mas fazendo uma reflexão sobre os feedbacks que já recebi na vida e os amigos que obsevei nesses últimos 6 anos de profissão, percebi que eram coisas inerentes ao nosso perfil.

Não cabe somente a nós mudar isso. Eu acredito em dois grandes pontos:

Sofremos por sempre sermos tiradores de pedidos, construtores de dashboards, as pessoas que entendem de números, “porque afinal eu sou de humanas, não preciso me envolver nisso”;
Nos acostumarmos a isso.

É sobre esse segundo ponto que esse texto vem falar. Escrevi ele para inspirar meus amigos de profissão a tentaram expandir seus horizontes para lados não tão convencionais. Inferência Causal e LLM Models são interessantes, mas o básico precisa ser bem feito.

Mas o 1) é sobre um pedido de ajuda para você PM guerreiro que leu até aqui. Você não é chefe de ninguém , eu sei. Mas tem o dom de extrair o melhor das pessoas ao seu redor para influenciá-los a chegarem lá. Como você pode extrair o máximo dos Analistas de Dados do seu time? Como você pode contribuir, absorvendo tarefas simples, entendendo mais sobre como funciona o racional deles, engajando em desafios relavantes e provocando-os a irem mais longe?

Colaborar. Esse é o real desafio.