O dia a dia de produto.

Como é essa aventura de ser PM na prática?

12 de janeiro de 2017. Foi nessa noite de nevasca em Denver que tive meu primeiro contato oficial com a área de produto. Estava passando um ano nos Estados Unidos e aproveitando para estudar novas áreas, quando me deparei com um curso/palestra de Product Management 101 da General Assembly. Me inscrevi e fui lá ver. Me apaixonei, claro, mas isso é assunto pra outro post.

O que queria compartilhar aqui é um dos slides específicos desse curso: um slide em que a Jess Sherlock (maravilhosa) falava sobre o dia a dia de um PM. Na época não me conectei muito com vários pontos — não sabia direito nem o que era um PM — , mas há umas semanas lembrei dele de novo e pensei em revisitá-lo, visto que agora provavelmente me diria bem mais do que disse na ocasião. Verdade, disse mesmo. Segue:

O que o PM faz o dia todo? Essa é a principal dúvida de quem não conhece a área e/ou está pensando em entrar nela. Eu mesma, em abril/2017, após ter curtido o 101 e cogitando apostar em um curso mais robusto e na carreira de produto, comecei a buscar pessoas no LinkedIn para fazer exatamente essa pergunta.

E como o mundo é cíclico, mais recentemente tenho sido eu a procurada por contatos para responder a esse tipo de pergunta, e é um prazer retribuir a ajuda que recebi naquela ocasião. ❤

Adivinha qual foi a primeira pergunta do almoço? Como é o meu dia a dia.

Por isso, após 1 ano e 9 meses trabalhando com produto, resolvi listar neste artigo algumas das tasks do dia a dia do(a) produteiro(a), aquelas coisas que preenchem nossos dias e são feitas sempre, de forma rotineira. Lembro que isso muda muito de acordo com a empresa, mercado, contexto, etc. Então o que se segue está baseado muito no que eu vivi nas experiências que tive e estou tendo. Bora?

Entrevista com usuários/clientes

Não que eu vá necessariamente seguir uma ordem de importância aqui, mas coloquei esse ponto como primeiro pois (1) considero um dos mais importantes e (2) considero um dos mais legais/reveladores/divertidos/esclarecedores.

Uma das principais armadilhas em que podemos cair em produto é assumir os nossos problemas/dores como os que devem ser atacados. Tanto para identificar em quais pontos o nosso produto deve melhorar (e em que ordem de prioridade), como para entender como/qual será a solução para esses pontos, é a voz do usuário que conta. Pode parecer óbvio dizer que não estamos fazendo o produto para nós mesmos, e sim para a nossa persona, mas é incrivelmente fácil nos cegarmos por uma suposição nossa, ou por uma dificuldade que nós mesmos passamos com o produto.

O contato frequente com o cliente garante que iremos priorizar o que é importante para ele, que entenderemos o contexto dele para a construção da solução, e que mitigaremos os riscos envolvidos ao construir um produto, como por exemplo, se o cliente verá valor no que estamos propondo.

E concentre-se no “frequente” do parágrafo acima. Conforme estudos que documentei nesse post, a maior parte dos PMs está insatisfeita com o tempo que dedica a isso:

Tempo investido em ouvir o usuário, segundo relatório da Alpha

Não queremos ser essa pessoa, que constrói uma solução sem aparentemente fazer ideia de como é a vida de quem vai usar:

Essa é uma descida íngreme de uma passarela em Florianópolis. Reparem no canto esquerdo atrás da lixeira onde fica o rebaixo da calçada. Simplesmente não tem ângulo para você descer em velocidade e sair para a ciclovia. Claro que o rebaixo não serve apenas para ciclistas, mas também para eles. Assino embaixo do usuário que levou uma lata de tinta até lá para registrar sua revolta. Não precisa andar de bike, mas fala com quem anda, pô. :)

Lembrando que gerentes de conta, atendimentos e o time de customer success também são excelentes fontes de insights aqui, visto que têm contato frequente com clientes e prospects, então vale muito colocá-los na agenda de papos também. No entanto, não acredito que substitua o contato direto do PM com os clientes.

Alinhamento com vendas/comercial/marketing

Da mesma forma como CSs, os vendedores também têm muito insight de produto, e isso já é uma razão para trocar figurinhas com eles: eles passam o dia escutando o potencial cliente, inclusive quando ele diz o que gostaria que o produto tivesse, mas ainda não tem.

Mas, além de escutá-los para obter insights, também é essencial que alinhemos com marketing e vendas o que está por vir em produto porque… bem… são eles que vão ajudar no go to market e vender a solução. Esses times precisam estar 100% a par do que está sendo construído, a razão de estar sendo construído, para quando está previsto o rollout, casos de uso, como funciona a solução, que problema resolve, benefícios que entrega, qual workaround (aka gambiarra) a feature mata, etc. Em resumo, os movimentos de construir e vender uma solução precisam estar sincronizados, para que o vendedor não abra o app (ou qualquer produto aqui) um belo dia na frente do cliente e, opa, o que que é essa nova aba aqui? A responsabilidade do PM vai desde a concepção/levantamento de uma ideia ou demanda até a precificação e venda do produto quando pronto.

Por fim, ressalto a importância dessa comunicação rolar desde o início do discovery, pois marketing pode trazer informações de mercado ou de posicionamento da empresa que podem mudar o rumo de uma solução, ou por vezes até indicar uma possível inviabilidade da mesma.

Análise de dados

Sem chover no molhado aqui, todos queremos tomar decisões baseadas em dados. Ter um dashboard organizado com as principais métricas para bater o olho pela manhã é sempre uma boa ideia, além de atualizá-lo sempre que novidades no produto demandem isso.

Ajuda bastante ter o costume de já no processo de discovery e desenho de solução listar os indicadores que queremos mexer com determinada feature ou melhoria, para que o time de desenvolvimento considere isso na hora de construir, e para que o PM esteja organizado para passar a verificar aquela métrica após o rollout.

Estudo de mercado

Dominar frameworks e metodologias para gerenciar produtos é meio caminho andado, mas entender a fundo sobre o business da empresa e sobre o mercado/indústria em que ela atua é crucial na vida do PM. Fica muito difícil seguir na direção certa sem considerar o contexto em que se está trabalhando.

Quando a empresa conta com um time de Product Marketing, essa equipe ajuda muito o PM nessa parte, conduzindo estudos e construindo materiais sobre concorrência, win/loss, mercado, tendências e por aí vai. Mas, de toda forma, quase que diariamente dou uma lida sobre o mercado de marketing digital, automação de marketing, inbound e companhia. Old but gold, assinar newsletters do seu mercado e ativar alguns alertas do Google ajuda bastante.

Daily e outras cerimônias mais

O papel de PM envolve muita comunicação, como já vimos até aqui, e a comunicação constante com o time/squad talvez seja a mais importante delas. Seja qual for o método ágil que o time utiliza, vejo como essencial haver um checkpoint diário do time para um alinhamento rápido. São 10/15 minutos que podem evitar confusões no dia a dia de trabalho do time.

Dessa forma, o PM consegue acompanhar o que está sendo desenvolvido pelo time de engenharia, os desenvolvedores ficam a par e são envolvidos nos processos de discovery do PM e designer, e o time todo anda como uma unidade, e não como micro áreas — fazendo o seu e passando adiante.

Além desse alinhamento rápido e frequente, a retrospectiva também sempre foi uma cerimônia fixa na minha agenda como PM, normalmente a cada 15 dias. É aquele momento de aprender com os erros passados e reforçar o que foi bom para as próximas entregas. Se me permitem uma dica aqui, conte com um bom líder de time ou assemelhado para conduzir essa cerimônia. Sem foco e organização, essa reunião pode levar horas e trazer mais peso pro dia a dia do time, sendo que a ideia é justamente a oposta.

1:1s

Vejo como um dos principais caminhos de crescimento do PM a troca com outros profissionais. Ter 1:1s fixos com GPMs, diretoria de produto, desenvolvedores e designers do time, outros PMs, ou o que fizer sentido no contexto da empresa e do profissional contribui não só para que o trabalho de todos flua melhor, como também para a evolução do próprio PM. O tempo vai passando e a agenda vai ficando toda colorida, sim, mas vale a pena.

Eu gosto de anotar tópicos no período entre cada 1:1, para aproveitar o tempo da conversa da melhor forma. Em 1:1s com GPMs/heads de produto, entre outras coisa, normalmente levo meus processos de discovery e priorização, para contar com a voz da experiência em cada jornada percorrida. Em outros contextos, já fiz 1:1s com todos(as) os(as) desenvolvedores(as) do time, e esses momentos eram ricos para entender a percepção de cada um sobre a forma como trabalhamos como time, sua própria visão para o produto, as perspectivas profissionais de cada um, e muitas vezes sobre a vida em geral. No fim das contas é tudo sobre pessoas, e vejo muito valor em dedicar um tempo para trocar com elas.

Respostas a perguntas

Sim, amplo desse jeito. Mas a verdade é que em ambos contextos em que trabalhei com produto, isso sempre foi parte do meu dia a dia. Pessoas de todas as áreas vão contar com você para saber se feature X está no roadmap, como funciona aquela parte Y do produto, se é possível fazer XPTO com as features que temos hoje, quais foram as entregas de produto do trimestre passado e quais serão as do trimestre que vem, qual a visão do produto pro ano que vem, se o nosso concorrente faz tal coisa, se já pode vender Z para o cliente, etc.

O próprio time eventualmente terá dúvidas ao longo do processo de construção de uma solução, algo que ainda não foi abordado até o momento de colocar a mão na massa, e o PM está aí para trazer a visão de negócio e do usuário.

Comunicar bem o roadmap de produto, a visão do mesmo e estudos realizados pelo time para toda a empresa ou áreas interessadas, por exemplo, ajuda bastante a diminuir as dúvidas que possam surgir na cabeça das pessoas, mas de toda forma, elas vão existir, e sempre considerei uma honra ser procurada para solucioná-las.

Tudo o que envolve o processo de discovery

Como define Marty Cagan: “In product discovery, we´re essentially trying to quickly separate the good ideas from the bad as we work to try to solve the business problems assigned to us”.

A maior parte do tempo do PM é investido (ou ao menos deveria ser) descobrindo o que deve ser construído a seguir. Nesse processo, o PM trabalha muito em conjunto com o(a) designer do time, e também deve envolver sempre que possível os profissionais da engenharia.

Entender o problema, planejar o discovery, promover ideações, construir protótipos e validar/testar são atribuições que preenchem os dias do PM, e as técnicas utilizadas para cada um desses pontos vão variar de acordo com cada contexto. O primeiro ponto desse post, por exemplo — conversar com usuários — , já faz parte do processo de discovery. Recomendo muito a leitura do Inspired para aprofundar em técnicas de discovery que podem ser aplicadas no dia a dia.

***

Como vimos, englobando as tasks acima e outras mais, os dias dos PMs são bastante dinâmicos. Certeza de não ter um dia igual ao outro. Mesmo que as atribuições da posição possam variar de acordo com cada situação, esse sempre será um papel que permeia diversas áreas da empresa, que está com a cabeça no que ocorre dentro da companhia e fora dela, e que conecta muitos pontos.

PMs desse Brasil, fiquem à vontade para compartilhar também nos comentários um pouco do seu dia a dia.