Carta aos iniciantes em produto

Ei, tudo bem? Muito prazer, eu sou a Gabi.

Quero te contar um pouco sobre os principais aprendizados que eu tive trabalhando com produtos. Espero que isso te ajude ou te inspire de alguma forma, sem tecniquês ou clichês, mas também sem muitas respostas prontas. Afinal, isso não existe em criação de produtos, certo?

Então, vamos lá!

Trabalho como Product Manager no Asaas, fintech de gestão financeira com sede em Joinville (SC), há 1 ano e 5 meses.

Mas, Gabi, tu tinha experiência? Passou por empresas famosas? Nubank? iFood?

NÃO!

Eu vim de uma realidade totalmente industrial: trabalhava como analista de PPCP (planejamento, programação e controle de produção) e, antes disso, tive uma experiência com projetos e vendas de móveis sob medida, em uma empresa da família.

Beleza, mas como tu decidiu ser PM?

Cheguei no Asaas em 2018 com a meta de entrar no mundo da tecnologia, que me encantava há algum tempo. Então, agarrei uma oportunidade no CS atendendo e resolvendo problemas de clientes.

Depois de alguns meses, iniciei um setor que tem como objetivo auxiliar os gerentes de contas (e, consequentemente, o cliente) em relação a dúvidas mais técnicas sobre alguns produtos do Asaas, como nota fiscal de serviço e cartão pré-pago.

Foi aí que nasceu a minha vontade em resolver problemas complexos e comecei a colocar o 1º pezinho em produto.

No final de 2019, a empresa sentiu a necessidade de ter pessoas focadas em produto, o que não existia na época. Tudo era resolvido entre diretoria, tech lead e alguns designers que já trabalhavam no time. Foi aí que recebi a oportunidade de entrar no time de produto.

E os perrengues que tu falou lá no começo, o que aconteceu?

Bom, eu vim para um time de desenvolvimento sem saber o que era uma query. Não entendia a linguagem “tecniquês” dos desenvolvedores e entendia muito pouco de design.

Aí você pode imaginar que me bati no início e, sim, foi desafiador. Mas, já no primeiro dia, eu entendi que precisava de conhecimentos que eu não possuía (uma pausa aqui pra agradecer ao Asaas e as pessoas que acreditaram em mim na época: Fernando Chagas, Manoela Gieseler e Alex Willian) e fui correr atrás. Cursos de Produto e SQL, livros etc. foram essenciais nesse momento.

Depois de algumas semanas agarrada em cursos e livros, comecei a me sentir em casa, e é assim que me sinto até hoje. Dizem que ir para uma nova função sem experiência nenhuma é enganação, não vai dar certo etc. Sim, pode dar errado, mas eu sou a prova viva de que se você tem a mínima intuição, já pesquisou sobre a função e acredita que se encaixa, SÓ VAI. Você consegue, com muito suor e lágrimas, mas consegue.

Hoje eu atuo em um time que cuida de 2 pilares do Asaas: Fiscal e Faturamento, com 8 engenheiros, 2 designers e 1 tech lead. O Asaas está passando por uma fase de crescimento acelerado, o que se reflete no time de produto, pois precisamos ser mais ágeis, estruturar melhor os nossos processos sem deixar de entregar valor, fazendo com que o cliente voe junto com a gente.

Mas, beleza. E o que eu aprendi nesse 1 ano e 3 meses que pode te ajudar?

1º — Errar não é um problema

Quando você acredita muito em uma solução e ela dá errado, você fica frustrado. E isso é normal, ninguém gosta de errar. Mas como eu faço pra errar menos? Errar não é o problema, e eu aprendi isso depois de algum tempo.

O problema é o tempo que você leva até errar. Imagina, você e seu time fazendo um discovery longo, com mais 2 meses de desenvolvimento até entregar ao cliente e a solução dá errado?

O tombo é grande. Porém, se você quebrar melhor as hipóteses, testar coisas rapidamente, realizar pesquisas, colocar o cliente para usar um protótipo navegável e outros tantos métodos, você pode economizar muito tempo e já pensar em um plano B, sem gastar recursos desnecessários.

2° — Você não é o seu cliente

Essa frase é clássica, mas é uma verdade. Você trabalha na empresa, usa o sistema diariamente, está acostumado com os erros e conhece as limitações. O seu cliente não.

Perceba que para você pensar em uma solução que faça sentido é muito fácil, mas será que ela vai ajudar a economizar tempo do seu cliente? Ou, será que ela vai fazer com que ele use mais o seu produto?

Não tem como descobrir isso sem entender a fundo a rotina do usuário, qual parte do seu produto ele usa, qual ele não usa porque acha difícil, ou o que você poderia fazer para economizar o tempo no dia a dia dele.

Pesquisas quantitativas (o Google Forms ajuda muito) e qualitativas devem ser o início da validação de uma hipótese. Claro que você não vai usar de pesquisas pra tudo, mas isso é tópico pra outro dia.

O que importa é: ouça o seu cliente. Quando você pensou que já ouviu muito, ouça mais um pouco. Assim, as chances de você lançar um produto de sucesso ou ignorar uma hipótese que não faz tanto sentido aumentam drasticamente.

3º — O time comercial é a porta de entrada para feedbacks de falhas no seu produto. Aproveite isso!

O time comercial da empresa sempre está dando a cara a tapa. Todos os dias, 8 horas por dia. Geralmente, é a fonte mais rica de feedbacks sobre o seu produto, pois é pra eles que o seu usuário vai ligar quando tiver algum tipo de problema. E você precisa aproveitar isso.

Aqui no Asaas, temos um grupo no Slack com todo o time de produto, vinculado a um formulário do Google, que é preenchido pelos gerentes de conta sempre que o cliente tem algum problema ou alguma sugestão de melhoria.

Ainda precisamos melhorar muito, mas por ele já conseguimos filtrar feedbacks sobre algum produto específico ou até priorizar ações no produto X, que esteja trazendo muitas reclamações.

Esse é só um exemplo, mas o fato é que você precisa estar constantemente em contato com o time comercial. Isso pode até acelerar o seu entendimento sobre determinado assunto, pois a quantidade de ligações que o comercial recebe geralmente é alta. Você demoraria muito tempo pra conseguir falar com a mesma quantidade de clientes.

4º — Saiba dizer não

Você está com o seu backlog lindo, priorizado, de acordo com a estratégia e, de repente, BUM! Cai um raio do céu, ou melhor, chega um stakeholder pedindo algo que não se encaixa com o seu planejamento. E aí? O que você faz?

Ouça, ouça e ouça. Tenha empatia para entender o que motivou essa pessoa a dar esse feedback, entenda a fundo qual é a ideia, o que vai impactar, de onde ela tirou isso. Depois, veja se é possível viabilizar essa ação no momento. E se não, diga NÃO.

Confesso que esse ponto não é fácil, e é uma evangelização diária ainda pra mim, pois às vezes esse raio vem do CEO da empresa. Mas o não, não é só não e pronto. Você precisa levar a esse stakeholder argumentos sólidos do porquê não consegue atuar nessa ideia nesse momento e tentar um acordo.

Se você abraçar o mundo, o seu produto e o seu time serão prejudicados. Ninguém consegue resolver 50 problemas de uma vez.

5º — Não abandone o seu designer

Esse foi um dos principais aprendizados que eu tive. Designers gostam de criar, isso é fato. E, para os PMs, pensar em uma ideia e não precisar documentar os detalhes seria um sonho.

Porém, como a pessoa vai entender o caminho, se ela não tiver um Google Maps pra ajudar? Ele até pode achar o caminho, mas quanto tempo vai levar?

Documente, chame o designer para conversar sobre a proposta, mostre a ele qual o objetivo e onde pretendem chegar com isso e acompanhe o seu designer. Se o time de design da sua empresa ainda for júnior, acompanhe diariamente, se possível.

Você vai aprender muito com eles. Isso vai diminuir as chances do designer pegar uma tangente e entregar um resultado totalmente fora do esperado no final, o que acaba com a motivação da equipe.

Eles são incríveis, não fique 2 dias sem falar com eles.

6º — Se apegue a dados

Isso é clássico, mas também é verdade. Estratégia e decisões sobre tudo o que está acontecendo com o produto e onde você e a sua equipe pretendem chegar precisa ser baseada em dados sólidos.

Se você não tem um engenheiro de dados no seu time e os seus devs sempre estão com MIL coisas pra fazer, você vai ficar agoniado e vai querer fazer isso sozinho.

E sim, todo PM na minha visão precisa ter o mínimo de conhecimento em banco de dados (SQL) na missão de conseguir informações e respostas importantes rapidamente. O seu dia a dia será muito mais produtivo.

7º — Seja o melhor amigo do seu tech lead

O seu tech lead é a sua porta de entrada para o mundo do desenvolvimento. É com ele que você vai tirar dúvidas técnicas, é ele que vai te ajudar a motivar o time de desenvolvimento, é com ele que você vai negociar o backlog, é com ele que você vai acertar os ponteiros quando algo começar a sair do rumo.

É o seu braço direito e, se a relação entre vocês for tumultuada, pode prejudicar o engajamento do time e a entrega de resultados. Embates são ótimos no final das contas, mas é importante que depois das 18h fique tudo bem e vocês dois saiam pra tomar uma cerveja.

Espero ter te ajudado de alguma forma, e se quiser me chama que a gente bate um papo 😊