Platform Product Manager: um guia para os primeiros 30 dias (e um pouco mais)
Dicas e estratégias de documentação e mapeamento de quick wins para usar no seu onboarding.
Nesse início de 2025 estou iniciando em um novo time de Plataforma no Nubank, e mesmo continuando na mesma empresa, durante meu onboarding resolvi revisitar esse artigo que publiquei em 2023 para relembrar alguns passos, e vi que ele merecia uma atualização.
Segue a versão atualizada:
Iniciar em uma nova empresa não é uma tarefa simples, a complexidade aumenta ainda mais quando também mudamos de contexto ou domínio de atuação ao assumir um novo cargo. Isso vale, por exemplo, para quando você faz uma transição de um produto customer-facing para um produto mais técnico, como plataformas.
Essa transição exige uma dedicação mais pragmática no onboarding, estruturação dos aprendizados e a definição dos primeiros quick wins a serem trabalhados.
Neste artigo, quero compartilhar um pouco sobre minha experiência com transições de papel de PM e as estratégias de adaptação a novos contextos que costumo adotar para documentar meus aprendizados iniciais e definir os primeiros passos de trabalho em um novo time técnico.
A leitura do livro “Os primeiros 90 dias: Estratégias de sucesso para novos líderes“ de Michael Watkins foi uma grande inspiração para as primeiras ações que vou recomendar aqui.
As estratégias recomendadas não precisam se limitar aos primeiros 30 dias e não necessariamente precisam seguir essa ordem de execução à risca, algumas podem desenvolvidas em paralelo em algum momento, algumas podem ser executadas de forma contínua e por quanto tempo for necessário estender seu onboarding.
1. Conhecendo as pessoas e a cultura da empresa
Como parte fundamental de qualquer onboarding, ao chegar em uma nova empresa é importante investir tempo para entender a cultura, conhecer as pessoas e estabelecer relações com seu time, lideranças e stakeholders.
No contexto de um produto técnico ou de plataforma (que geralmente é interno da organização), essa etapa é ainda mais importante, pois você vai se relacionar com diversas áreas da empresa e muitas dessas pessoas serão stakeholders diretos ou usuárias da plataforma que você vai gerir.
Pelo menos nas 2 primeiras semanas, ou nas semanas seguintes ao onboarding institucional, é importante se conectar com as pessoas diretamente relacionadas ao seu papel.
A partir do primeiro contato com as minhas lideranças e pares, já costumo mapear outros nomes de pessoas com quem faria sentido conversar. Na segunda e terceira semanas, foco em conhecer outras lideranças da área, as pessoas do meu time e as lideranças de produto e lideranças técnicas de áreas estratégicas para o contexto da Plataforma.
Dinâmica das conversas
Eu costumo marcar conversas de 30 minutos com cada pessoa. Lembre-se que nesse momento as pessoas ainda não te conhecem e não é de bom tom simplesmente enviar um convite sem se apresentar ou checar a disponibilidade antes.
Sendo assim, comece por uma mensagem via slack ou e-mail, se apresentando, indicando o motivo da conversa e checando qual é a data e hora mais apropriada para a pessoa. Depois envie um convite na agenda (sempre que possível com a opção de modificação ativada para que a pessoa consiga reagendar caso aconteça algum contratempo).
Para esses papos de apresentação, é interessante que você realmente demonstre interesse em conhecer a pessoa e em estabelecer uma relação porque esse é de fato seu objetivo. Eu sempre tenho um script de perguntas anotadas no bloco de notas mas não é uma regra, o legal é deixar a conversa fluir e aprender o máximo possível com aquele primeiro contato:
Quem é você na fila do pão? (Seu papel na empresa, quem são suas lideranças e há quanto tempo você está na empresa? E quem é você fora do trabalho?)
Me conte sobre a atuação do seu papel hoje e suas áreas de influência e decisão
Me conte sobre sua história na empresa (o que te motivou a vir trabalhar aqui ou por quais papéis você já passou)
Quais as mudanças você vivenciou na empresa?
O que te faz feliz aqui? O que te motiva a trabalhar todos os dias?
Quais problemas/desafios/oportunidades você enxerga hoje?
O que as pessoas têm feito para mudar estes cenários?
Um conselho para uma recém chegada?
Quem mais você me indica pra conversar?
Quando sobra tempo e eu percebo abertura para uma conversa mais profunda nesse primeiro papo, eu também aproveito o momento para explorar algumas perguntas do diagnóstico que vou especificar na próxima sessão. Caso não seja possível nesse primeiro papo, já verifique a disponibilidade da pessoa para marcar uma segunda conversa em outro momento.
2. Desenvolvendo um diagnóstico inicial
Essa ideia de diagnóstico foi baseada no livro de Michael Watkins que citei na introdução e adaptado para o contexto de produtos de plataforma. No livro, o autor incentiva a busca de insights acionáveis como forma de retorno do investimento feito em tempo de aprendizado.
Ele também sugere que o aprendizado sobre a organização deve considerar os 3 horizontes de tempo: passado, presente e futuro. As perguntas são direcionadas para entender o porquê das coisas serem feitas como são, a razão pela qual certas decisões foram e são tomadas e quais as expectativas para o futuro e as mudanças esperadas com a sua chegada na organização.
Com base nessas ideias, criei o seguinte template para documentar meu diagnóstico no Miro:
Basicamente, cada horizonte de tempo é subdividido nas categorias listadas abaixo. Além disso, cada categoria tem algumas perguntas norteadoras que também adaptei para o meu contexto (veja os detalhes no template, ou acesse as perguntas norteadoras no anexo, ao final desse artigo):
Passado: desempenho, problemas e mudanças;
Presente: estratégia, pessoas, processos, pitfalls e quick wins;
Futuro: oportunidades, obstáculos, recursos e cultura.
Eu usei post-its de cores diferentes para cada pergunta e uma linha para documentar as respostas de cada pessoa. Nem todas as pessoas terão respostas para todas as perguntas, é importante que você saiba direcionar as perguntas e temas que fazem mais sentido para cada papel e vá anotando os principais insights sobre cada tema durante a conversa.
Em paralelo às conversas, também é importante investir um tempo de leitura de toda a documentação existente dos (pelo menos) últimos 6 meses: Documentação no Confluence, iniciativas, épicos e tarefas no Jira, Boards do Miro e outros documentos de texto e planilhas do Google Docs que contem alguma história sobre seu novo domínio e atuação.
No final de cada dia, recomendo revisitar as notas, destacar os principais insights e anotar perguntas adicionais para validar com a sua liderança ou com a pessoa em questão, sempre que precisar de mais contexto sobre algum assunto. Para isso usei o quadro a seguir (também disponível no template).
3. Validando o diagnóstico e traçando os primeiros quick wins
Um segundo passo após obter material suficiente documentado no diagnóstico, é iniciar uma validação com as suas lideranças e com o time.
Validação com as lideranças
Use os 1:1s com as suas lideranças para discutir os achados, validar suas percepções, buscar por mais respostas e discutir quais insights acionáveis fazem sentido.
Definam juntas o que é prioridade de acordo com as expectativas para o seu papel nos primeiros 30 dias. Dessa forma, é possível que já nas primeiras semanas você tenha uma lista inicial de quick wins, ou seja, uma lista de ganhos rápidos e itens de ação para colocar a mão na massa.
Validação com o time
Se você está entrando em um time que já existe, a validação precisa ser um pouco mais cuidadosa, pois é possível que algumas áreas do diagnóstico toquem em processos e alinhamentos prévios feitos entre eles no passado. E seu objetivo ao chegar em um novo time nunca pode ser criticar, ou apontar problemas no trabalho que foi desenvolvido antes da sua chegada. Entretanto, você pode perceber áreas de melhoria, gargalos de processo e/ou documentação, ou dificuldade na entrega de valor e entrar como a pessoa que sugere ações de melhoria e novos planos de ação.
Para essa validação e início da evangelização do time na temática de produto (quando necessário), você pode começar com um papo muito aberto sobre a definição do papel da PM no time, definir os limites de atuação da PM x Tech Manager, e deixar claro quais são suas responsabilidades.
Depois desse contexto e alinhamento inicial, compartilhe com o time seu diagnóstico inicial e crie espaço de discussão sobre o que faz sentido ou não, na percepção deles. A partir disso, liste algumas ações de mudança e melhoria para o time e quick wins para você mesmo executar.
O template da dinâmica para facilitar essa conversa também está disponível no Miro. Basicamente, o diagnóstico está dividido em temas como:
Visibilidade sobre o propósito do time como um time de plataforma;
Entendimento das necessidades dos nossos usuários;
Visibilidade e validação das nossas entregas;
Documentação e visibilidade do progresso;
Comunicação e ways of working.
Para cada tema destaque algumas afirmações e dúvidas que foram levantadas no “Diagnóstico inicial”, e deixe um espaço para que o time possa adicionar outros pontos que sejam relevantes na coluna “Validação com o time”. E ao lado, na coluna “Como podemos resolver/melhorar?”, abra espaço para sugestões e action items.
Esse diagnóstico inicial é muito importante para obter uma visão geral do momento atual da empresa, para entender porque certas decisões de gestão foram tomadas no passado, para entender os processos do time, entender e ganhar contexto em decisões técnicas, elencar alguns pain points possíveis de serem rapidamente resolvidos e principalmente para identificar os primeiros quick wins.
A validação com a liderança garante que tudo está alinhado com as expectativas do papel, e a validação com o time, permite que eles também se coloquem como “donos” das melhorias que estamos nos dispondo a implementar a partir daquele momento.
Caso você esteja iniciando em um time novo ou que ainda está em formação, é importante executar o diagnóstico inicial com pessoas próximas ao contexto da sua atuação, e se possível validar com o próprio time novo e entender se todos têm as mesmas percepções e estão na mesma página sobre os problemas que vocês estão se propondo a resolver.
4. Mapeando e classificando stakeholders
Essa dica vale principalmente para aqueles que gerenciam algum tipo de produto interno técnico ou de plataforma, pois no final das contas, quase todas as suas relações e entrega de valor vão estar dentro da empresa. Mapear e classificar seus stakeholders é um passo fundamental para entender com quem você precisa se comunicar, como você deve se comunicar e com que frequência você precisa se comunicar com eles.
Em um produto de plataforma, você irá se conectar com alguns stakeholders que só entendem a linguagem de negócio e outros com os quais as conversas serão puramente técnicas. Por isso é essencial ter essa visibilidade para adaptar melhor suas comunicações.
Dependendo do tamanho da sua empresa, o número de stakeholders de diferentes áreas pode ser gigante, e estes podem ter diferentes tipos de relação com sua plataforma, então é importante fazer um mapeamento completo, especialmente sobre as lideranças de produto e lideranças técnicas de cada time cliente.
Em um segundo momento, você também pode querer incluir quem são os usuários internos direto e as demais pessoas desenvolvedoras que vão ou podem consumir sua plataforma.
No template há um exemplo de mapa inicial em formato de árvore e um modelo de classificação desses stakeholders em 3 categorias com diferentes níveis de envolvimento que podem fazer sentido ou não, de acordo com o seu contexto (como ilustra a imagem abaixo):
Usuários: pessoas de engenharia;
Tomadores de decisão: lideranças executivas e lideranças de área;
Parceiros: lideranças técnicas, de produto e outros papéis que de alguma forma se relacionam com a plataforma.
O próximo passo após o mapeamento é então atribuir uma classificação para todos os stakeholders mapeados e identificá-los com a cor e número correspondente aos níveis definidos. Somente com essa estrutura inicial, já conseguimos ter uma boa visibilidade de quem podem ser as primeiras pessoas a serem entrevistadas num discovery inicial, por exemplo. E ao mesmo tempo, conseguimos ter um mapeamento completo dos nossos usuários e fácil de consultar.
A árvore de stakeholders é um organismo vivo, que precisamos manter em constante atualização. Mas é importante ressaltar que essa estrutura vai variar de acordo com a estrutura organizacional da sua empresa, ou da forma que você decide classificar seus stakeholders e usuários.
5. Estudando o domínio técnico
Um outro grande desafio ao assumir o papel de Platform Product Manager é o mergulho profundo no domínio técnico.
Como Platform PM você ainda vai precisar entender o domínio do core business da empresa e/ou área de negócio, saber como a empresa entrega valor para usuário final e como gera receita para o negócio. Mas ao assumir a gestão de um produto técnico ou de plataforma interno da empresa, o seu principal negócio é a própria tecnologia como habilitadora da entrega de valor para o usuário final e geração de receita para o negócio.
Abordagens de aprendizado
Então, além de entender o core business, é necessário dedicar um tempo para absorver conhecimento suficiente sobre as tecnologias que o time trabalha, ferramentas, processos, serviços e como elas se relacionam com as entregas do produto user-facing e com as metas do negócio.
Aprender o vocabulário
A primeira abordagem que eu aplico quando preciso estudar qualquer coisa do zero é aprender o vocabulário. Quando você chega em um contexto novo, é completamente normal que nas suas primeiras interações com o time e lideranças você comece a ouvir termos que até então eram desconhecidos ou que não sabia o significado.
Durante as reuniões iniciais, além das notas de diagnóstico, eu costumo ter um caderninho do lado para anotar termos, nomes de ferramentas e expressões que eu não conheço. Quando há espaço e tempo na reunião, eu já aproveito para perguntar o significado ou pedir para a pessoa me dar mais contexto sobre determinado assunto. Quando não é possível, uso a listinha para pesquisar e ler mais sobre aquele termo no meu momento de estudo.
Durante o primeiro mês, eu costumo dedicar em média 2 horas por dia para estudar temas específicos do contexto da plataforma. Isso incluiu ler documentações internas do time para entender alguns processos, a pesquisa de termos que mencionei anteriormente, leitura de tutoriais e documentação de ferramentas, vídeos no Youtube sobre tecnologias específicas e também leitura de artigos mais direcionados à gestão de produtos técnicos e de plataforma.
Pareamento no Mapeamento de Jornadas
Uma outra fonte de aprendizado valiosa (que eu recomendo para qualquer domínio) é o pareamento. Conforme você vai ganhando contexto, uma atividade que pode ajudar muito a entender o contexto dos usuários internos e/ou a comunicação entre os sistemas que compõem a plataforma é fazer um mapeamento de jornada.
Para isso, é importante contar com a ajuda das pessoas engenheiras do seu time, e/ou especialistas nas plataformas que você gerencia. Aproveite esse momento de colaboração com a engenharia para evangelizar sobre o mindset user-centric na plataforma, tirar dúvidas e entender como é feito todo o processo de desenvolvimento dos componentes e serviços da plataforma. Quando possível, valide a jornada mapeada com os próprios usuários internos.
Uma outra atividade que você pode fazer em conjunto com o time e pode te ajudar muito a compreender produtos técnicos é o Service Blueprint, focando em entender como serviços e processos de tecnologia se conectam com a jornada do cliente principal.
Lembrando aqui que para ser uma boa Platform PM você não precisa saber codar, mas ser a melhor amiga das pessoas desenvolvedoras e da sua liderança técnica é uma ótima ideia. Além disso, fazer as perguntas certas, demonstrar curiosidade e vontade de aprender o novo contexto durante essas interações, é fundamental.
6. Estudando sobre o(s) produto(s) user facing
Confesso que já cometi o erro de menosprezar essa etapa ao entrar em um time de plataforma, foquei demais no domínio técnico e subestimei a importância de entender no detalhe tudo o que os produtos customer-facing integrados a plataforma entregam como valor para o usuário final.
Como mencionado na sessão anterior como Platform PM, além de colocar muito esforço em entender o "tecniquês”, você também precisa entender o domínio do core business da empresa e/ou área de negócio, e saber como os produtos geram impacto e receita para o negócio.
Essa etapa vai depender muito de como a sua empresa está estruturada, quantos times de produto você vai ter acesso, o quanto de documentação há disponível. Mas a minha recomendação principal é: converse com as pessoas!
Para os primeiros 30 dias, essa etapa talvez seja complexa demais, então foque em se conectar com seus principais stakeholders (mapeados anteriormente). Converse com os PMs dos times customer-facing e peça detalhes do funcionamento dos produtos, mapeie fluxos e jornadas, use o service blueprint (mencionado anteriormente) para fazer as conexões do produto com a plataforma, entenda quais problemas eles estão resolvendo para o usuário final.
Na sequência e assim que seu onboarding começar a evoluir para os próximos 60 ou 90 dias, inicie seu discovery e converse com as pessoas de atendimento ao cliente, entenda as dores do usuário final, as necessidades e desejos. Busque participar de sessões como “voice of customer” ou acessar reports de atendimento que contenham esses dados. Se conecte também com stakeholders de negócio, eles vão saber explicar as melhores métricas para você acompanhar os resultados da entrega de valor, e no futuro isso fará toda a diferença na hora de reportar as entregas da sua plataforma e como elas causam impacto no usuário final e no negócio.
Concluindo
Espero que esse guia de primeiros passos te ajude de alguma forma com seus novos desafios. Lembrando que tudo aqui é adaptável e todo o diagnóstico inicial pode ser adaptado para qualquer domínio ou negócio apenas mudando o contexto e o direcionamento das perguntas.
Para usar os templates você vai precisar de uma conta (gratuita) no Miro. Ao abrir o board, vá em configurações > board > fazer uma cópia e seja feliz!
Anexo - Perguntas Norteadoras para o Diagnóstico Inicial
PASSADO
DESEMPENHO
Como se qualifica o desempenho passado do time?
Qual a opinião das pessoas sobre esse desempenho?
Existiam metas? Como eram estabelecidas e acompanhadas?
Quais eram os indicadores de qualidade? Métricas? Quem define/ acompanha/tem ownership?
Que comportamentos essas métricas influenciavam?
O que acontecia quando metas não eram atingidas?
PROBLEMAS
Quais eram as causas do desempenho insatisfatório?
Quais eram os principais pain points / gargalos?
Onde estavam os pain points principais? (estrutura/goals/processo/skills)
Quais os principais fatores para o desempenho satisfatório?
MUDANÇAS
Quais foram os esforços desprendidos para reformar o time?
Quais foram os resultados dessa mudança? Como foi acompanhado?
Quem / o que tem sido o principal instrumento da formatação dessa nova organização?
PRESENTE
ESTRATÉGIA
Qual é a visão e a estratégia da organização?
Como a estratégia é colocada em prática?
Quem tem a accountability? Você acredita que do jeito atual está funcionando?
Como as decisões de tecnologia são tomadas?
PESSOAS
Quem tem plena capacidade? Quem precisa se desenvolver mais?
Quem pode ser par/braço direito da liderança?
Quem é o influenciador no time?
Quem pode ser detrator no time?
Quem precisa de apoio para se desenvolver?
PROCESSOS
Quais os principais processos da organização?
Quais os principais processos do time? Ways of working?
Os processos atuais estão funcionando em termos de qualidade, confiabilidade, pontualidade?
Quais são os blind spots?
Quais são os pain points visíveis?
PITFALLS (ARMADILHAS)
O que pode surgir no caminho que vai desviar o rumo?
Quais são os potenciais passos em falso? Potencialmente danosos?
Existem desafios em termos de cultura, política, processos? Quais são?
Existem possíveis detratores como ponto de atenção?
QUICK WINS
Onde podemos concretizar ganhos imediatos?
Quais ações são mais urgentes?
Há alguma prioridade esquecida?
FUTURO
OPORTUNIDADES
Quais são as áreas com maior probabilidade de dar problema?
O que pode ser feito de imediato para evitar?
Quais são as oportunidades mais promissoras ainda inexploradas?
O que precisa acontecer para todo o potencial se concretizar?
OBSTÁCULOS e RECURSOS
Quais os principais obstáculos para concretização das mudanças?
O que já funciona e pode ser reutilizado? (áreas que são ilhas de excelência/outros recursos de qualidade)
Quais as novas capacidades necessárias de serem desenvolvidas ou adquiridas?
CULTURA
Como é a cultura atual?
Quais elementos devem ser preservados?
Quais elementos são merecedores de mudança?
Show Renata,
Não sou PM sou PD, mas já fiz uma cópia desse seu template, sensacional ter essa visão.
Muito obrigado por compartilhar!