E aí, como você organiza o seu tempo?
O maravilhoso mundo da agenda de product managers.
Os últimos meses têm me trazido experiências e oportunidades muito ricas. Os convites para participar de eventos e painéis de produto, por exemplo, me colocaram em contato com muita gente legal, contatos esses que continuaram depois do evento via redes sociais.
Em função de várias pessoas me procurarem no LinkedIn para trocar uma ideia depois dos eventos, separei alguns slots de 30 minutos na minha agenda para marcar papos com pessoas do universo de produto interessadas em compartilhar experiências.
Na semana passada, conversei com duas pessoas que estavam iniciando na carreira de produto, e em ambos os papos me chamou a atenção que rolou a mesma pergunta:
"Quais tarefas fazem parte da sua agenda/rotina, e em que proporção?"
Realmente, é uma questão bastante relevante: por ser um papel com muitas atribuições (e demandas que chegam dos mais variados lados), é fácil ficar reagindo aos estímulos e pedidos e perder a rédea do que realmente devemos fazer e do que mais importa para a evolução do nosso produto.
Quem nunca ficou respondendo o Slack, o e-mail, a pessoa que passou e perguntou alguma coisa, foi ver o que é esse bug que está acontecendo, deu mais uma reportadinha sobre o que foi entregue mês passado, preencheu aquela planilha, entrou numa reunião X de outra área e, quando viu, acabou o dia? Não que não sejam necessariamente tarefas importantes e da nossa alçada, mas acredito que devemos ser críticos e organizados com o nosso tempo e atividades, caso contrário, quem paga é o produto.
Coloco abaixo, na ordem decrescente do que eu acho que merece mais tempo nosso, as tarefas que eu acho que devem preencher os nossos dias.
Discovery
Essencialmente (e de forma bem resumida), estamos em nossa posição para garantir que o produto evolua na direção certa. E product discovery é tudo sobre isso.
Ou seja, não tem muito segredo aqui: na minha opinião, a grande maioria do tempo da PM deve ser preenchida pelas atividades de product discovery.
E esse é um processo que requer foco, várias horas de concentração. Ou seja, é o processo que mais sofre quando você tem uma agenda toda "picadinha" em mil reuniões e reports, ou se você sofre com interrupções constantes. Por isso, defenda o seu tempo e a sua agenda com carinho, para poder focar no que mais importa.
Contato com o cliente/usuário
Seja dentro de um processo de discovery específico, ou papos frequentes que você mantem com clientes (internos e externos) para se atualizar sobre as principais oportunidades de melhoria do produto, falar com o cliente é essencial para produteiros.
Sugiro a seguinte reflexão: "estou há mais de uma semana sem falar com algum cliente"? Se a resposta for sim, muito provavelmente seu tempo está sendo drenado para uma série de outras coisas, que eu arrisco com muita segurança dizer que são menos importantes do que ouvir o cliente.
Claro que isso depende um pouco do contexto em que se atua e do estágio em que a empresa está: existem empresas, por exemplo, que focam em clientes B2B de grande porte. Por vezes, e principalmente em um estágio mais inicial, essas empresas vão ter 20 ou 30 clientes em sua carteira. Se você falar muito constantemente com clientes, inevitavelmente vai acabar "enchendo o saco" deles, pois os papos serão sempre com os mesmos e com muita frequência.
Mas cuidado com as desculpas: é bastante fácil ser sugado por coisinhas do dia a dia, e ir deixando de lado essa tarefa. Principalmente porque ela dá trabalho: você precisa selecionar pessoas do perfil que quer falar, recrutar elas para o papo, preparar um roteiro, falar com elas e depois compilar os insights e feedbacks. Mas se você não fizer isso, corre o risco de estar construindo um produto para você mesmo. Ninguém quer isso.
Papos com outras áreas
Também pode já fazer parte do discovery (ou não). O importante é não ficarmos em uma bolha do mundinho de produto e esquecermos de incluir o restante da companhia no desafio de fazer um produto melhor.
Atendimento/CS/gerentes de conta, suporte, jurídico, financeiro, operações, marketing, enfim, todos podem colaborar.
Estudo de mercado e análise da concorrência
É muito problemático quando idealizamos novos produtos ou funcionalidades sem ter um contexto macro. Podemos perder o timing de uma nova tecnologia ou tendência, podemos deixar de mudar nossa estratégia se o cenário pedir por isso, e por aí vai.
Costumo dizer que conhecer bem o mercado em que a empresa atua já é meio caminho andado para a PM que quer trabalhar nela, portanto, não deixemos de fazer nosso tema de casa.
Cerimônias com o time
Defendo que sejam frequentes (assim previne de termos que ficar fazendo alinhamentos desordenados o tempo todo), porém que levem pouco tempo.
Daily meetings de 15 a 30 minutos, retrospectivas quinzenais de no máximo 2 horas (idealmente menos que isso), encontros semestrais para construção/alinhamento de estratégia macro e meio que era isso.
1:1s
De maneira recorrente, entendo que o mais produtivo é manter apenas com o seu líder.
De maneira esporádica, mediante necessidade, pode-se marcar com outros membros do time, mas pense no seu tempo com cuidado. Por vezes, um almoço já pode ajudar naquela aproximação necessária com determinada pessoa.
Backlog, roadmap e priorizações
São tarefas importantíssimas, mas coloquei mais abaixo na lista pois creio que não devam ser tão frequentes ou tomar tanto do nosso tempo.
Ficar repriorizando sempre e obcecando com backlog e roadmap tira o nosso tempo de aprofundar em discovery e pode desfocar o time (traz o risco de ficarmos cada hora olhando para um lado diferente e mudando de prioridade o tempo todo).
Planeje, priorize, comunique e confie. Se precisarmos mudar de rumo, claro, devemos fazê-lo, mas com cuidado para isso não ser uma constante.
Apoio ao go to market
Preparar materiais de comunicação de uma nova feature, precificar (se necessário), treinar áreas internas para vender e dar suporte, etc. Claro que estaremos envolvidos. Encabeçamos essas melhorias e sabemos melhor do que ninguém por que estão lá e que benefícios entregam.
Mas, na minha opinião, o mais saudável é sermos uma fonte de consulta e apoio a essas atividades, e não quem as puxa ou executa. Se formos essa pessoa, o pratinho vai cair lá no que é mais importante para o nosso papel.
Reports
Por mais que seja muito uma atribuição de PM reportar o status das evoluções do produto, coloco aqui embaixo da lista de forma intencional.
Me aflige demais ver PMs passando horas em diversas reuniões para falar o que foi feito, o que está sendo feito, o que será feito, e depois preenchendo planilhas sobre isso, e também o report de fechamento mensal (e trimestral, e semestral, e anual), e também tem aquela cerimônia semanal com a empresa toda só pra dar uma posição na evolução das features… gente, não dá.
Sejamos inteligentes. Primeiro: se o roadmap estiver claro e bem divulgado, isso já minimiza essa necessidade demasiada de reports. Segundo: se, junto ao roadmap, a comunicação de lançamento de cada feature for bem feita, para que ficar reportando a cada segundo em que pé cada coisa está? Terceiro: vamos tentar fazer as coisas async. Uma reunião com muita gente propicia o bikeshedding, toma tempo, gera discussões infinitas, dá a maior dor de cabeça para casar agendas e, geralmente, acaba em "tudo certo, nada resolvido".
Um report simples a ser preenchido pelas PMs com alguma frequência, que pode ser comentado por outros e respondido conforme necessidade é mais efetivo, na minha visão.
Para resumir: menos reports, mais enxutos, async sempre que possível.
Trocas com outros PMs
Quase por fim, sugiro separar um tempo para bater um papo com outros PMs da empresa, para todos estarem por dentro do que todos estão idealizando e trabalhando de forma mais macro.
Tanto para o produto da empresa seguir em uma unidade concisa, quanto para essas profissionais trocarem sobre melhores práticas em produto.
Descompressão
Como bons seres humanos, principalmente aqueles que não trabalham com atividades manuais e repetitivas, arejar as ideias é essencial para conseguirmos seguir raciocinando com qualidade.
Não esqueça de construir sua rotina de forma a ter pequenos intervalos para tomar um café, caminhar na rua uns 15 min depois do almoço, fazer um lanche, etc. Parece banal, mas já negligenciei isso, e não foi legal.
E, abaixo, o que eu acho que não deve entrar na nossa agenda (mas que eventualmente entra).
O processo inteiro de go to market
Conforme citei ali em cima, se isso acontecer, algum outro lado vai ficar descoberto. Isso porque o processo de go to market é complexo e demanda bastante energia. Corremos o risco de levar muito bem a mercado algo que em si não é muito bom, pois foi "mal descoberto".
Áreas como product marketing, conteúdo e enablement, por exemplo, ajudam muito nisso, mas se a sua empresa não dispõe delas, alinhe com a líder da área de produto qual será o papel de cada um nessa jogada. Financeiro não pode encabeçar a precificação de uma nova feature (se for o caso)? Marketing não pode puxar a comunicação de uma nova feature para a base de clientes (internos e externos)? Operações não pode tocar alguns treinamentos?
E quando eu falo puxar/encabeçar/tocar, é ser responsável mesmo, não apenas aparecer numa reunião.Você como PM estará lá para dar insumos, mas não pode fazer tudo sozinha.
QA/testes das novas features antes de por em produção
Eu entendo que, em empresas menores e/ou com equipes reduzidas, a saída é o PM fazer isso. Mas falando em mundo ideal, eu não acho que esse seja o caminho mais produtivo.
Ter alguém especializado e focado nisso, geralmente a pessoa de QA, mantem todos os outros profissionais no seu foco, e profissional no seu foco é sempre algo bom!
Claro que a PM vai querer, e deve, usar a feature (a famosa fuçada) antes de qualquer um. Mas não com a atribuição de assegurar que todos os critérios de aceite estão de acordo, ou que todas a regras de negócio combinadas foram seguidas (em outras palavras, se tudo funciona do jeito que deveria funcionar). Isso envolve bastante responsabilidade para ver se nada "escapou", o que drena muito tempo do PM. Além disso, muitas vezes esse profissional nem domina as melhores práticas para testes de software, o que o fará levar bem mais tempo que alguém especialista levaria.
(D)escrever em detalhes como uma feature deve ser
Entendo que aqui precisamos contar com maturidade e comunicação de todos do time, e isso também varia um pouco de acordo com a metodologia ágil adotada e o papel que a empresa entende para a pessoa de produto.
Dito isso, já trabalhei escrevendo stories e quebrando cards detalhadamente, e não julgo produtivo. Sério, eu não acho que preciso escrever em algum lugar que, ao apertar no botão da casinha, o usuário deve ser direcionado para a home.
Produto e design devem passar para engenharia as diretrizes e protótipos da solução, e engenharia deve ter a liberdade de quebrar e descrever essa solução técnica da forma que fizer mais sentido para ela. Claro que, sempre que houver dúvidas, esse time não deve simplesmente fazer como acha melhor, mas sim trazer para o restante do squad para haver uma combinação.
De maneira geral, o time deve estar sincronizado desde o início do discovery de algo, para que todos cheguem ao ponto de desenvolver a solução com uma noção consistente da mesma, sem precisar de explicações granulares.
Garantir o pace do time, "gerenciar o projeto", ser responsável pelo desenvolvimento ficar dentro do cronograma
Acredito que somos responsáveis pelas entregas de uma forma macro, mas não deve caber à PM ficar entendendo e explicando se os cards estão atrasados, mapeando possíveis obstáculos, se responsabilizando pelo pace do time de desenvolvimento ou cobrando-o por isso. Isso drena o tempo da pessoa de produto e desgasta a relação. Dentro do que foi combinado entre todos do squad, o time de desenvolvimento deve ter autonomia para organizar e responsabilidade sob o seu trabalho.
Contar com um team leader para isso ajuda a todos. O time conta com alguém com o perfil adequado, que pode efetivamente ajudar nessas tarefas, e o PM pode focar no discovery sem diariamente precisar responder sobre story points ou coisas do tipo.
Gestão completa dos bugs/issues
Você está lá, fazendo as suas coisinhas, aí surge alguém X atrás da sua cadeira e fala "aconteceu tal coisa (crítica e inesperada) com o usuário Y". Você não tem como saber a razão, então começa a investigação. Pergunta pra uma pessoa do seu time, que diz que tem que ver com o time de dados. O time de dados não sabe, daí você pergunta para aquela desenvolvedora que está há mais tempo na empresa. Ela não trabalha mais na sua feature há milênios, então não tem como ajudar. Você volta para o seu time, que vai ver os logs. Ninguém descobre nada. Aí a pessoa X volta e fala: "então, falei com Y, era um problema lá com a internet dele, já deu". E o dia se vai assim.
Sério, não seja para-raio de problema. As issues devem vir de forma ordenada, e o seu trabalho não é investigá-las, mas priorizar a resolução do que deve ser resolvido. No meu contexto atual, o time de suporte reúne todas as reclamações iniciais que os usuários podem ter, incluindo questões abertas por colaboradores da empresa advindas de relatos de clientes. Se o suporte não pode resolver, ele conta com a ajuda de um time de desenvolvimento exclusivo para bugs/issues. Por sua vez, caso esse time também não consiga solucionar, há uma pessoa deles responsável por fazer a ponte com o time de engenharia do squad em questão. Caso as devs do squad realmente entendam que é algo que demanda reparo, só então acionam a PM para priorização disso.
Cada um focadinho no seu trabalho! o/
***
Novamente, essas são questões que variam muito de acordo com cada empresa, contexto e momento. Por vezes algo vai sair, por vezes algo vai entrar, e isso é normal.
Na minha opinião, o mais importante é lembrarmos constantemente do maior valor que entregamos para a empresa, e então assegurarmos que a nossa agenda reflete, comporta e prioriza isso.
