[pm letter] #48 - Os relacionamentos com outras especialidades

Como os PMs podem se relacionar com outras especialidades

Letter #48

Imagem: https://icons8.com/ouch/illustration/pablo-sign-up


Este texto faz parte do meu livro Gestão Moderna de Produtos Digitais. R$24,99 na Amaon! Se quiser a versão impressa, encontre aqui.


O Product Manager lida com pessoas que têm interesses e principalmente motivações diferentes. Por isso, é bastante comum que se absorva muita informação importante da vida pessoal das pessoas e também da maneira com que elas trabalham. Você vai precisar trocar várias vezes o escopo e a forma da conversa por causa do fórum que você estará lidando. Em um momento você estará discutindo com os Devs se Call of Duty é melhor que Battlefield e brigando porque eles insistem em jogar FIFA, e no momento seguinte estará falando sobre o goal anual da empresa com os stakeholders e diretores. Isso é muito mais comum do que se imagina.

Com os devs

A motivação dos desenvolvedores é muito parecida com as dos designers: eles querem resolver problemas e ver as soluções desses problemas sendo usadas pelos usuários. Tão simples quanto isso.

Os desenvolvedores têm um pragmatismo que pode ser difícil de entender para os PMs que não trabalharam anteriormente com tecnologia. Dependendo da senioridade dos devs, esse pragmatismo pode se confundir com antipatia, mas não é. Eles prezam muito pelo "flow", pela busca da solução elegante e principalmente usando tecnologias que geralmente são emergentes.

Sua atuação aqui deve ser trazer de maneira clara e objetivo quais problemas devem ser resolvidos e quais os resultados esperados. Ao contrário do que muitas pessoas de negócio, designers e PMs pensam, codificar não é algo fácil e precisa de muita criatividade (não do lado visual, mas pela capacidade de encontrar soluções diferentes). Esse é um dos pensamentos mais detratores que você pode ter sobre o trabalho dos desenvolvedores. Codificar certo envolve muito foco, pensamento de longo prazo e planejamento de escala e crescimento.

Os devs são a última etapa entre ter uma ideia no papel ou sendo usada por usuários reais. Eles são as únicas pessoas que podem dizer se as possibilidades imaginadas podem ser viáveis para o produto. Por isso é importante entender quais processos e quais os débitos técnicos existentes que os devs estão precisando resolver durante o desenvolvimento.

Para descontrair, pergunte quem já ficou preso no servidor por não saber mexer no VIM. :-)

Com os designers

Ao contrário dos desenvolvedores, designers têm um pensamento um pouco mais humano sobre os problemas. Às vezes isso se torna até um problema, pois precisamos moderar entre decisões que podem afetar a experiência dos usuários, mas que trarão um grande impacto para o negócio, e com certeza eles ficarão contra. Isso é ótimo, pois além de você, precisamos ter outras pessoas colocando as pessoas no centro do produto, mas que sem um negócio saudável, não vamos impactar de forma positiva a vida dos usuários.

Contudo, os designers são os seus aliados na elaboração de boas ideias. Trabalhando na Easynvest, eu gostava de sentar ao lado do designer - Salve para o Daniel - para discutirmos sobre diversas ideias. Era ótimo para expandir os limites das possibilidades que poderiam ser feitas no produto. É importante ter em mente que várias ideias são boas, mas se essas ideias não estiverem atreladas a algum problema real de negócio e a uma necessidade real dos usuários, elas são apenas ideias legais com grandes chances de não os levarmos para lugar algum.

É muito comum (aconteceu comigo), no início da carreira, você sentir que os designers estão entrando muito na sua área de gestão, seja por que estão sugerindo ideias de soluções e funcionalidades, seja por estarem conduzindo testes diretamente com os desenvolvedores. Lembre-se que você não é o dono do produto, você gere seus resultados. Embora eles estejam testando algo, você é a pessoa que decide a prioridade, exatamente por que você tem uma visão mais ampla do produto, incluindo não apenas design e desenvolvimento, mas tendo visão de estratégia de mercado e negócio. Por isso, fique tranquilo e deixe que eles exerçam sua criatividade trazendo ideias geniais para você.

Com os Stakeholders, Negócio e diretoria

Stakeholders, pessoas de negócio, diretoria, C-Level, sponsors, seja lá como você chama as pessoas da sua empresa que trazem demandas e problemas para serem resolvidos. Essas são pessoas que estão preocupadas unicamente com o negócio. O produto é apenas um fim e talvez apenas mais uma linha de receita para a empresa. Então, é importante entender que eles têm uma visão de usuário muito mais ligada a rentabilidade do que experiência. Eles até sabem que para o usuário gerar receita para empresa, o produto precisa ter uma boa experiência, mas eles veem a experiência do Produto como um meio para conseguir mais rentabilidades. Vou lhe contar um segredo: eles não estão errados em pensar dessa forma.

Para uma empresa continuar impactando positivamente a vida das pessoas, ela precisa ser lucrativa para se manter no mercado. Obviamente que há um limite saudável aí. Mas como pessoas generalistas, precisamos ter um pensamento moderado sobre resultados de negócio e impacto para os usuários. Essa simbiose precisa ser perfeita e quem orquestra isso é o PM.

Você vai precisar fazer muita gestão de expectativa para negociar datas e entrega e quando houver resultados ruins. Vai precisar fazer bastante política para conseguir priorizar as demandas que eles trazem com as demandas que você acha importante. Vai precisar realizar muito lobby para conseguir obter informações importantes e principalmente para cultivar influência. Isso tudo vai acontecer com mais ou menos intensidade dependendo da empresa que você trabalha. Se for uma cultura muito mais corporativa, bem comum em empresas que não nasceram digitais, você precisará praticar ou adquirir sua resiliência. Se for em empresas que já nasceram no mundo digital, ou seja, que usam a tecnologia como meio para mudar um setor que não é essencialmente digital, você sentirá que o time de produto tem muito mais força e direciona boa parte das decisões da empresa.

Uma coisa é importante: essas pessoas entendem muito mais do negócio do que você. Muitas vezes esses times são formados por pessoas que trabalham na indústria há muito mais tempo que você e que embora não tenham experiência com tecnologia, eles conhecem os meandros do mercado como ninguém, por isso, é importante que você esteja próximo deles para adquirir conhecimento do mercado em que o seu produto atua.

Com os Agilistas

Como você sabe o quanto você pode priorizar para o time? E como você sabe quanto tempo o time precisará para terminar uma determinada tarefa? Como você sabe quando você terá uma hipótese em produção para analisar os dados? O Agilista é a pessoa que analisará a performance do time e lhe dará respostas importantes sobre como você poderá usar o time na potência máxima de entrega.

É muito importante que o PM trate o Agilista como um co-piloto. Ele é o detentor de informações importantes sobre a saúde do time e principalmente sobre o impacto que o trabalho de especificação e priorização do PM está causando na performance do time. O Agilista ajuda a abreviar a entrega de valor para o usuário, fazendo com que a "esteira" (odeio esse nome) funcione sem grandes problemas. Embora ele não seja o gestor do time, ele ajuda o time fazer o seu melhor, facilitando a comunicação, expondo problemas de gargalo e mostrando para o time quando algo está saindo do controle, mobilizando as pessoas a resolverem em conjunto um problema específico.

Um ótimo PM conhece seu papel no processo e tenta executá-lo de forma que o time não seja impactado. Você atrapalha o trabalho do Agilista se você não está presente nas cerimônias, se você cria um ambiente direcionado à entrega e não por resultados. Nesse caso, o Agilista não consegue influenciar o time a ficar do seu lado. Um PM que perde a influencia perante o time, perdeu tudo.

Um bom Agilista sabe quais os objetivos que devem ser alcançados pelo time de produto e tenta potencializar a performance do time, trazendo consciência e relembrando os princípios do mindset ágil. Você é responsável por trazer de forma detalhada esses objetivos para o Agilista, de forma que ele advogue ao lado do PM sobre o cumprimento desses objetivos.

Concluindo

A PM precisa ser alguém que se adapta com facilidade. Ela vai precisar ajustar o discurso, o tom de voz e o comportamento várias vezes durante o dia. É importante lembrar que embora essas adaptações aconteçam durante todo o dia, a PM não pode perder a identidade. Essa identidade precisa ser relacionada com suas habilidades de comunicação, sua habilidade de olhar o todo. Sua identidade pessoal também não pode ser perdida, pelo contrário, ela precisa ser exposta o tempo inteiro, alem do mais, você também tem opinião, desejos, dias ruins e bons.


Share

Share PM Letter Email

Pode nos dar seu feedback? Você responde em menos de 15 segundos.