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 os primeiros 30 dias como Technical Product Manager.
Sair de um contexto de atuação como Product Manager generalista para um domínio mais específico como o de produtos técnicos ou de plataforma, exige uma dedicação a mais no onboarding, estruturação dos aprendizados e definição dos primeiros quick wins a serem trabalhados.
Recentemente assumi como Technical Product Manager em um time de Plataforma Mobile. Neste artigo, quero compartilhar um pouco sobre minha experiência nessa transição e as estratégias que adotei para documentar meus aprendizados iniciais e definir os primeiros itens de trabalho.
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.
Além disso, minha experiência em consultoria e o eterno shift de contexto entre engajamentos com diferentes clientes, me ajudaram a desenvolver estratégias de rápida adaptação que também puderam ser aplicadas nesse novo contexto.
Em seguida, vamos explorar as estratégias que segui no primeiro mês e as que ainda estão em andamento nesses primeiros 90 dias. Elas não necessariamente seguiram essa ordem de execução à risca, algumas foram desenvolvidas em paralelo em algum momento, e algumas podem ser executadas de forma contínua.
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 ou usuárias dos produtos 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.
No meu caso, na primeira semana e a partir do primeiro contato com as minhas lideranças e pares, já consegui mapear outros nomes de pessoas com quem faria sentido conversar. Na segunda e terceira semanas, foquei em conhecer outras lideranças do círculo (conceito semelhante a tribo) de plataformas de engenharia, as pessoas do meu time e as lideranças de produto e lideranças técnicas de áreas estratégicas para o contexto de Plataforma Mobile.
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 chat 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 sobrava tempo e eu percebia abertura para uma conversa mais profunda nesse primeiro papo, eu também aproveitava o momento para explorar algumas perguntas do diagnóstico que vou especificar na próxima sessão. Caso eu não conseguisse nesse primeiro papo, eu já verificava 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 do meu papel e empresa atuais. 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 (link para o template):
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 aqui):
- 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 investi um tempo de leitura de toda a documentação existente dos ú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.
No final de cada dia, eu revisava minhas notas, destacava os principais insights e anotava perguntas adicionais para validar com a minha liderança ou com a pessoa em questão, sempre que precisava 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, foi iniciar uma validação com as minhas lideranças e com meu time.
Validação com as lideranças
A cada 1:1 com as minhas lideranças, semanalmente íamos discutindo meus achados, validando minhas percepções, buscando por mais respostas e discutindo quais insights acionáveis faziam sentido.
Assim conseguimos atacar primeiro o que era prioridade, de acordo com as expectativas para o meu papel nos primeiros 30 dias que alinhamos no onboarding. Dessa forma, logo na terceira semana já tínhamos 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
A validação com o time foi um pouco mais complexa e cuidadosa, pois algumas áreas do diagnóstico tocavam em processos e alinhamentos prévios feitos entre eles nos meses anteriores e meu intuito não era criticar, ou apontar problemas no trabalho que foi desenvolvido antes da minha chegada. Ou seja, a ideia era sugerir ações de melhoria em alguns cenários que possuíam gargalos de processo, documentação ou até mesmo entrega de valor.
Para essa validação e início da evangelização do time na temática de produto (antes da minha chegada, o time era formado apenas por pessoas desenvolvedoras), começamos com um papo muito aberto sobre a definição do papel da TPM no time. Nisso, falamos sobre o que era esperado de mim pelas lideranças e o que era esperado de nós enquanto time a partir de agora.
Dado esse contexto, compartilhei com eles meu diagnóstico inicial e, em conjunto, fomos discutindo o que fazia sentido dentro da percepção deles e outras coisas que quisessem adicionar. A partir dali, fomos listando algumas ações de mudança e melhoria para o time e quick wins para mim.
O template da dinâmica que usei para essa conversa também está disponível no Miro. Basicamente dividi o diagnóstico 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.
Esses foram os temas mais mencionados nas conversas de diagnóstico. Além disso, foram temas que se destacaram durante as observações de processos e leitura de documentação que fiz nesse primeiro mês.
Para cada tema destaquei algumas afirmações e dúvidas na coluna “Diagnóstico inicial”, também deixei um espaço para que o time pudesse adicionar outros pontos que achassem relevantes na coluna “Validação com o time”. E ao lado, na coluna “Como podemos resolver/melhorar?”, abri espaço para sugestões e action items.
Esse papo foi dividido em duas reuniões de 1 hora e, ao final, saímos com uma lista de ações para o time e alguns quick wins para a TPM.
Esse diagnóstico inicial foi 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 meus primeiros quick wins.
A validação com a liderança garantiu que tudo estivesse alinhado com as expectativas do meu papel, e a validação com o time, além de ter sido um momento de troca muito valioso, permitiu que eles também se colocassem como “donos” das melhorias que estávamos nos dispondo a implementar a partir daquele momento.
4. Mapeando e classificando stakeholders
Essa foi uma das práticas que aprendi em consultoria e recomendo para qualquer Product Manager, trabalhando em qualquer domínio de negócio.
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 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 técnico, terão 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.
Eu gosto muito de usar o modelo de Matriz de Stakeholders que faz o cross entre influência x interesse, mas no meu contexto atual, dado o grande número de stakeholders de diferentes áreas da empresa, e com diferentes tipos de relação com nossos produtos, precisei começar um passo atrás.
Pareando com outra TPM do círculo (responsável pelos times de infra e observabilidade), iniciamos mapeando todas as lideranças de Engenharia e de Produto de cada círculo que usa nossos produtos técnicos de plataforma. Ou seja, praticamente toda a estrutura da empresa. Da mesma forma, também incluímos nossos usuários e as pessoas desenvolvedoras mobile e backend.
Criamos um mapa inicial em forma de árvore e desenvolvemos um modelo de classificação desses stakeholders em 3 categorias com diferentes níveis de envolvimento que fizeram sentido para o contexto atual (como ilustra a imagem abaixo):
- Usuários: pessoas desenvolvedoras backend e mobile;
- Tomadores de decisão: lideranças executivas e lideranças de círculo;
- Parceiros: lideranças técnicas, de produto e outros papéis que de alguma forma se relacionam com nossos produtos.
O próximo passo foi 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 seriam as primeiras pessoas a serem entrevistadas no nosso Discovery e conseguimos ter um mapeamento completo dos nossos usuários fácil de consultar.
Situar esse grande número de stakeholders numa matriz não pareceu uma boa ideia para o momento, por isso decidimos manter o formato de árvore e evoluir outras formas de classificação conforme necessário.
A estrutura da árvore ficou parecida com a imagem abaixo e ela é um organismo vivo, que recisamos 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.
No nosso caso, também seria interessante ter incluído uma categorização considerando a stack de desenvolvimento ou outro critério de tecnologia, também poderíamos ter uma ramificação da árvore para incluir fornecedores. Enfim, há muitas possibilidades.
5. Estudando o domínio técnico
Um outro grande desafio ao assumir o papel de Technical Product Manager é o mergulho profundo no domínio técnico.
Como TPM você ainda vai precisar entender o domínio do core business da empresa, 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 e como elas se relacionam com as entregas do produto user-facing e com as metas do negócio.
No meu caso, o domínio técnico era totalmente novo, pois sempre trabalhei com produtos web, e agora estou mergulhando no contexto mobile. Por isso, trago aqui algumas dicas que podem ser úteis.
Aprender o vocabulário
A primeira abordagem que eu aplico quando preciso estudar qualquer coisa do zero é aprender o vocabulário. Nesse caso não foi diferente. Desde a primeira interação com o time e com as lideranças, comecei a ouvir termos que até então eram desconhecidos ou que eu não sabia o significado.
Durante as reuniões iniciais, além das notas de diagnóstico, eu costumava ter um caderninho do lado para anotar termos, nomes de ferramentas e expressões que eu não conhecia. 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, dediquei em média 2 horas por dia para estudar temas específicos de desenvolvimento mobile. 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
Uma outra fonte de aprendizado valiosa (que eu recomendo para qualquer domínio) é o pareamento. Ao final do primeiro mês, uma atividade que me ajudou muito a entender o contexto dos nossos usuários foi fazer um mapeamento de jornada. Para isso, eu contei com a ajuda das pessoas desenvolvedoras do meu time, especialistas nas 3 plataformas de desenvolvimento mobile: iOS, Android e Flutter.
Foi o momento de, além de trazer o mindset user-centric para dentro do time, também tirar minhas dúvidas e entender como é feito todo o processo de desenvolvimento mobile até a release dos apps nas lojas.
Service Blueprint
Uma outra atividade que você pode fazer em conjunto com o time e pode te ajudar muito a compreender os 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 TPM 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, demonstrar curiosidade e vontade de aprender o novo contexto durante essas interações, é fundamental.
Aprender com os outros
Outro ponto que acredito ser importante é ouvir histórias e conhecer as experiências de outras pessoas e empresas. Essa é uma incrível fonte de conhecimento — o famoso “learn from others”.
Então, nos últimos tempos além de conversar com TPMs da comunidade, também tenho ouvido muitos episódios bons sobre produtos técnicos, produtos de plataforma e sobre o universo mobile.
Documentar insights
Falando brevemente sobre documentação de aprendizados, aqui eu vou de old style: o modo de aprendizado que funciona melhor para mim é escrever à mão. Gosto de ler e resumir no papel os principais insights com minhas próprias palavras, nesse caso minha única recomendação é: estudar e documentar da forma que funciona para você, e nunca deixar de tirar dúvidas com as pessoas especialistas naquele domínio ou tecnologia.
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. Caso você não consiga acessar o template no Miro, aqui tem uma versão em PDF apenas para visualização, e aqui um documento com as perguntas norteadoras do diagnóstico inicial.
Leia também:
