Eu decidi fazer esse artigo, porque eu vejo que não há uma literatura difundida ou aprofundada e prático sobre com Product Owners, APMs ou aqueles que acabaram de entrar na área de Produto devem se comportar ou agir quando encontram sua primeira oportunidade na área. Aparentemente esses profissionais deveriam se comportar como CEOs das empresas que lhe deram essa oportunidade, com visão estratégica aguçada, métricas, SQL, low-code, gestão de time e boa comunicação com stakeholders (essa é difícil, hein?).
Acalma o coração. Não existe castelo sem alicerce.
O lado bom de ser um pouco ansioso e inquieto é que em pouco tempo na área de Produto é que eu já tive oportunidades em várias empresas, o que me trouxe um pouco dessa visão mais holística. Esse guia é pautado na minha experiência, mas tenho certeza que se aplica para a maioria dos casos.
É importante começar fazendo o famoso trabalho de Produto que é falar “depende”, haha. Porque realmente depende muito de qual tipo de produto você está trabalhando e qual escopo exato que a empresa procura, mas essas dicas são extremamente necessárias para qualquer contexto ou escopo, pois elas te ajudar a pegar contexto e te preparar para sair do tático e pensar mais na estratégia do produto e assim alavancar sua carreira.
1. Escreva bem User Stories e épicos
Veja, escrever boas User Stories não significa escrever muito, nem tão detalhadamente, mas definitivamente é transmitir para o time de tecnologia exatamente o que precisa ser feito. A verdade inconveniente que Product Managers odeiam ouvir, é que nem sempre você vai ser a pessoa que dita as oportunidades e pratica a cultura da experimentação com testes AB.
As empresas contratam pessoas de produto para “traduzir” demandas de negócio para o time de tecnologia desenvolver. Principalmente quando você está no começo da sua jornada, não tem contexto para opinar sobre o caminho que as coisas estão indo, salvo exceções onde você está sendo promovido para trabalhar num produto no qual você era o “cliente”. Ex: você é Analista de Crédito, e vai trabalhar no produto de análise de crédito da sua empresa. Eu costumo fazer nessa ordem:
- Como (para quem é a funcionalidade);
- Quero(o que eles querem fazer e não conseguem);
- Para (porque eles precisam fazer isso?);
- Problema (qual é o problema atual);
- Impacto (qual impacto da sua não implementação);
- Solução (qual solução estamos desenvolvendo para resolver esse problema?);
- DoR ou Definition of Ready (definição breve de como dever a funcionalidade quando estiver pronta).
Uma última dica é, utilize fluxos para explicar o passo a passo da operação como está atualmente, além de como ficaria após o desenvolvimento da funcionalidade. Visualmente é muito bom para expressar o que é preciso fazer.
2. Tenha agendas recorrentes com pessoas-chave
Faça 1:1 com seus principais stakeholders, descubra se há alguém bom em sheets ou nas integrações, controles e dados que existem da área, quaisquer outras pessoas que tenham uma proximidade maior com a operação para te dar uma visão proativa, assim você não precisa perder um tempo gigante da sua agenda semanal para ver como time está trabalhando, pra dividir essa bola com os designers, além de ser uma fonte saudabilíssima de insights. Aproveite esse tempo para pegar contexto sobre a área e tirar dúvidas mais genéricas.
Além disso, pratique fazer semanalmente também reuniões com quem chamamos aqui de “squad estendida” que é uma reunião com todos os envolvidos no produto, marketing, business process, operação, designers, desenvolvedores. Crie uma pauta semanal para que todos estejam alinhados e opinem sobre o que o time tech está desenvolvendo e próximos passos, apresentar backlog e roadmap.
3. Desenvolva um relacionamento muito bom com todos, especialmente de Design e Engenharia
Não me interpretem mal, se vocês não tiverem um relacionamento bom com todos ao seu redor, você não terá uma caminhada fácil. Entretanto, design e engenharia são caminhos críticos para que vocês consigam atingir seus objetivos, e aqui é muito mais uma relação de troca ao modelo de hierarquia, é sobre você ter a parceria deles para que eles possam sugerir ideias melhores que a sua.
E cuidado: não seja apegado às soluções, e sim aos problemas. Ouça atentamente e mude de ideias se fizer sentido, se não fizer, discorde respeitosamente e cheguem a um consenso, mas é importante haver um canal aberto e seguro. Eles precisam estar comprados e com você na empreitada, se não vai ser díficil gestionar o restante.
Faça 1:1 com todos eles, faça pautas para resolver problemas de trabalho, mas foque em se conectar com as pessoas, saiba quem elas são, onde moram, se tem pets. Saiba quem é a pessoa por trás da pessoa desenvolvedora ou designer que está ali compartilhando diariamente os problemas que você sugere resolver.
Concluindo
Pra finalizar queria trazer aqui uma regra primordial para o início na carreira em Produto para quem está vindo de outras áreas, inclusive quem está se capacitando com cursos e certificações: você não precisa saber de tudo para começar na área.
Assim como tudo na vida, precisamos ter em mente que é um aprendizado constante, e assim como já ouvi de muitos líderes de Produto, é mais importante trazer um pessoa com fit cultural e com boas soft skills, do que trazer alguém muito bom tecnicamente, porque skills relacionadas à competência técnica podem ser desenvolvidas como uma boa gestão e contexto. Erros vão acontecer, e quando isso ocorrer, é importante ter um canal aberto com seus pares e stakeholders e humildade para receber feedbacks e melhorar o que foi apontado.
É sobre legado, trabalhar para o que vem depois, e não focar somente no dia a dia de trabalho. Para quem quiser desenvolver a conexão com as pessoas, sugiro fortemente ler o livro (cujo título não é muito bom mesmo, mas o conteúdo é ótimo) “Como fazer amigos e influenciar pessoas”.
Leia também:
