Quais foram os desafios e resultados alcançados

Contextualização do cenário

Contei aqui sobre minhas experiências antes de mudar para a área de Produto.

Eu tinha um background técnico atuando como analista de sistemas e desenvolvedor, e depois que fiz a transição de carreira para Produto só trabalhei com produtos que tinham interface com o usuário final.

Dessa forma, sempre atuei em squads multidisciplinares com Product Designers, Engenheiros Android, iOS, Front-end, Backend e QAs.

Depois de algumas atuações nesse modelo, abracei um desafio onde meu produto seriam APIs (Application Programming Interface), com uma atuação bem técnica mas ainda com viés de produto.

Agora você pode estar pensando: é um produto como outro qualquer, não?

Trazendo um pouco do contexto da época, a empresa atuava no modelo B2B2C (Business to Business to Consumer). Isso quer dizer que meus usuários eram empresas e cada empresa utilizava uma plataforma diferente que iria se conectar com as APIs para, aí sim, interagir com o usuário final.

O modelo de trabalho ficava dessa forma:

Considerando isso, precisaríamos pensar em como atingir nossos objetivos atendendo às necessidades dos nossos parceiros comerciais através de APIs, sem desconsiderar também as necessidades que os desenvolvedores teriam sendo os usuários que fariam a integração com nosso produto (Spoiler Alert: no começo eu desconsiderei os desenvolvedores como usuários hehe).

Quais foram os desafios e como lidei com eles

Enxerguei três desafios bem claros para o produto:

• Mostrar o valor do que está sendo feito para stakeholders;
• Explicar para o time de desenvolvimento a importância de impactar o negócio;
• Atender às expectativas de usuários diferentes no mesmo produto.

Para lidar com esses desafios, segui alguns caminhos:

Mostrar o valor do que está sendo feito para stakeholders

Por ser um produto menos tangível para quem não conhece tanto de tecnologia, no começo senti bastante dificuldade de mostrar o valor dele para os stakeholders, e algumas coisas me ajudaram bastante nesse processo:

1. Explicar o que é o produto: é muito difícil que as pessoas enxerguem valor em algo que não entendem, então me certifiquei de que estava sendo o mais claro possível sobre o que era o produto. Nesse contexto eu usei — MUITAS — analogias para relacionar APIs com produtos ou contextos com os quais as pessoas já estavam habituadas.
2. Entender as necessidades dos nossos parceiros comerciais: como os parceiros tinham contato direto com stakeholders, uma vez que eu entendi suas necessidades e gerei algumas entregas junto com o time, os próprios usuários começaram a falar para os stakeholders que aquele produto tinha valor :)
3. Definir objetivos para o produto que impactem o negócio: de forma geral, não importa se estamos atuando em um produto mais técnico ou mais customer facing, produto precisa impactar o negócio positivamente e definir os objetivos certos é o primeiro passo para isso.

Explicar para o time de desenvolvimento a importância de impactar o negócio

Quando temos um viés mais técnico é bem fácil — e tentador — olhar bastante para o “como” e esquecer o que queremos alcançar com as entregas.

Been there, done that.

Na minha visão, quando estamos olhando para um produto mais técnico a chance de isso acontecer fica bem maior.

Era comum termos conversas em que o time estava querendo buscar o “estado da arte” da API, a melhor arquitetura, o melhor sistema de monitoramento… a lista pode se estender bastante com exemplos.

Minha postura foi sempre trazer para a mesa nessas conversas lembretes sobre os objetivos que estávamos buscando como time e as necessidades dos nossos usuários (vou contar um pouquinho sobre o discovery mais abaixo), e aí sim cruzar isso com o que estava sendo discutido.

Outro ponto: sendo bem sincero, meu squad nesse produto tinha algumas das pessoas mais incríveis com quem já trabalhei (tanto pessoal quanto profissionalmente), então sempre conseguíamos ter discussões super produtivas onde todos saíam felizes.

Tá bom, vai, também tínhamos conversas mais acaloradas em alguns momentos (hehe).

Mas, independente do tópico, sempre nos tratamos com respeito mútuo e sabíamos ouvir todos os pontos de vista para chegar em um consenso :)

Atender às expectativas de usuários diferentes no mesmo produto.

Lembram que eu tinha explicado o modelo B2B2C, né?

Isso fez com que o produto tivesse dois tipos de usuário:

• Time comercial de cada empresa parceira: eles eram os usuários dos sistemas das empresas que estavam conectando nas APIs. E por usarem plataformas diferentes, só aqui já surgiram muitas — muitas mesmo — necessidades diferentes.
• Time de desenvolvimento das empresas parceiras: eram as pessoas desenvolvedoras que conectariam meu produto em cada uma das plataformas, então eles eram um grupo de usuário muito importante também.

Para resolver as dores do time comercial de cada empresa, comecei restringindo o público alvo às dez parcerias com as quais tínhamos os maiores volumes de receita sendo gerada.

Além disso, estruturei um discovery básico que me ajudou a entender muito bem por qual caminho eu deveria começar:

• Entrevista com stakeholders: a principal pergunta a ser respondida aqui era “o que meus stakeholders sabem sobre as reais necessidades dos clientes?”;
• Matriz CSD (Certezas, Suposições e Dúvidas): me ajudou a alinhar internamente o entendimento, expectativas e definir quais dúvidas e suposições seriam tratadas num primeiro momento;
• Entrevistas com parceiros que utilizariam nossas APIs: montei um roteiro básico para um bate-papo, e isso me ajudou a entender as principais dores dos clientes que utilizariam nosso produto.

Unindo esses três itens que comentei acima, consegui chegar em um caminho inicial que faria sentido seguir e fui para a última etapa que teria nesse momento.

• Benchmark: considerando que já tinha uma noção de por onde seria necessário começar, fazer uma pesquisa de mercado também me ajudou a entender o que já existia e estava sendo utilizado por outras empresas ou plataformas. Com isso, consegui ter uma ideia inicial do “como” fazer também.

Um lição aprendida muito importante

Inicialmente não considerei as necessidades dos desenvolvedores dos parceiros comerciais.

Isso foi um problema porque eles não estavam entregando as integrações de maneira satisfatória, o que gerava frustração tanto no squad que estava desenvolvendo as APIs quanto nos parceiros comerciais que estavam esperando a conclusão da integração.

Para resolver esse problema começamos a colher feedbacks das pessoas desenvolvedoras que já estavam fazendo a integração com nossas APIs e conseguimos contornar a situação antes que ela se agravasse e acabasse impactando o resultado final esperado.

Se eu fosse trabalhar com um produto desse tipo de novo, com certeza incluiria um discovery com o usuário desenvolvedor desde o início!

Por causa de todos os pontos que trouxe, eu diria que esse foi um dos produtos mais complexos com os quais já trabalhei e, como vocês puderam ver, também foi um dos que mais trouxe aprendizados.

E os resultados?

Após alguns meses — pois é, não foi algo rápido — começamos a receber feedbacks positivos e, em um dos parceiros que conectamos as primeiras APIs conseguimos medir um incremento de quase 100% na produtividade do time de backoffice dele. Ou seja, o esforço do time para realizar as mesmas atividades reduziu pela metade!!!

Isso ajudou a mostrar o valor do produto para o squad, para os stakeholders e, principalmente, para os próximos parceiros comerciais que ainda estavam se conectando em nossas APIs, o que fez com que conseguíssemos acelerar alguns processos de integração também :)

Gostou do texto ou viu algo que gostaria de falar?

Me manda uma mensagem no LinkedIn ou faz um comentário aqui. Seu feedback é muito importante!

Valeu, e até a próxima.

Como aumentar o engajamento do time utilizando essa estratégia

Já se encontrou em um cenário onde o time não parece estar muito feliz e fazendo as coisas apenas por fazer? E pior, às vezes até deixando de entregar ou colocando empecilhos nas propostas que são apresentadas?

Pois agora seus problemas acabaram!!!

Brincadeiras à parte (hehe), nesses casos geralmente é necessário um diagnóstico para entender tudo que pode estar acontecendo, mas um motivo bastante comum nas minhas experiências é o time simplesmente não enxergar valor no que está sendo feito e não se sentir parte do todo.

Considerando esse cenário, trabalhar com dual track pode ser uma estratégia que te ajude a resolver este problema.

Você já deve ter visto alguém falando sobre dual track e explicando seu funcionamento. Se não viu, no próximo parágrafo eu trago uma breve explicação (e no final do texto também coloquei dois links muito bons que explicam o processo de forma detalhada).

Dual track é, basicamente, um processo onde discovery e delivery de produto andam lado a lado, ou seja, a descoberta de novas formas para resolver problemas e alcançar objetivos acontece ao mesmo tempo em que o time de desenvolvimento está implementando o que já foi definido.

De maneira geral, podemos separar esse processo em algumas etapas:

1. Definir o objetivo do discovery: mais importante que um processo de discovery de produto bem feito, é entender por quê ele está sendo feito. Afinal, se não sabemos aonde queremos chegar, qualquer resultado serve (e você não vai querer qualquer resultado, NÉ???);
2. Envolver o time no processo: se você vai fazer entrevistas com usuários, montar uma pesquisa ou fazer análises de dados, por que não abrir para alguém do time participar também?
3. Mostrar a evolução: o time não pode ficar sabendo sobre todo o processo de descoberta só quando ele acaba. É extremamente importante trazer a visibilidade do processo enquanto ele acontece. Você pode usar uma parte da daily para isso ou puxar uma conversa separada;
4. Comunicar sobre resultados e plano de ação: uma vez que aquele ciclo de discovery tenha chegado ao fim, é importante deixar claro para todos qual foi o resultado, quais foram as conclusões e qual será o plano de ação para aproveitar os insumos coletados. Afinal, ninguém tem um xeroque rolmes no time :)

Apenas para ressaltar: os passos acima devem acontecer num loop e não em uma sequência quando o anterior acaba.

Além disso, você também pode utilizar alguns parâmetros para ver se essa estratégia de engajamento está funcionando:

• O time começa a se enxergar como responsável pelo produto: o impacto do trabalho que está sendo realizado vai além da entrega da feature. Todos questionam sobre os resultados para o produto, usuário e negócio;
• Existe uma preocupação genuína com a experiência que será entregue: discussões e dúvidas sobre a usabilidade do produto começam a aparecer com frequência nas conversas do time;
• Desenvolvedores trazendo sugestões para o produto: desde ideias sobre a próxima feature que o time pode trabalhar ou até mesmo um benchmark sobre uma coisa legal que viram em algum lugar e que poderia ser aproveitada de alguma forma;
• Aumentam os questionamentos sobre os resultados alcançados: querer entender o porquê da priorização de uma feature específica ou então perguntar sobre o desempenho de uma entrega recente são coisas que você vai começar a ver também.

Importante: não existe separação entre “time de produto” e “time de tecnologia”. O time é um só e precisa estar totalmente focado em resolver dores dos usuários e trazer melhores resultados para o negócio.

E, por último, não desencoraje as pessoas!

É natural que, por ainda não terem tanta familiaridade com essa abordagem, as pessoas tragam coisas que podem não fazer muito sentido. Nesses casos, o recomendável é sempre direcionar para o caminho mais apropriado e continuar incentivando a participação de todos no processo :)

Gostou do texto ou viu algo que gostaria de falar? Me manda uma mensagem ou um comentário. Seu feedback é muito importante!

Links que citei:

• Dual Track Agile: Focusing on Customer Value
• PM Letter

Procurar vagas internas ou no mercado?

No artigo anterior escrevi sobre como foi meu processo de preparação para atuar com gestão de produtos.

Agora vou falar sobre os critérios que avaliei para a tomada de decisão entre continuar na mesma empresa atuando com produto ou procurar oportunidades no mercado.

Para começar, quero te fazer uma pergunta: você acha que existe o caminho perfeito, que todos devem seguir para fazer essa transição?

Se sua resposta foi "sim, é isso que estou buscando aqui", só tenho uma coisa para te falar:

O melhor caminho vai depender do cenário no qual você se encontra, e o que eu quero aqui é justamente te ajudar a entender esse cenário e decidir por onde seguir.

Enxerguei dois caminhos a partir do momento em que decidi mudar de área:

1. Procurar no mercado uma oportunidade onde eu já poderia atuar com produto;
2. Fazer uma transição interna para a área de produtos na empresa onde eu estava trabalhando.

Primeiro vou te contar quais foram os critérios que avaliei e depois qual caminho eu decidi seguir (nada de spoilers!).

O que considerar para escolher entre os dois caminhos?

Tenha em mente que os critérios não estão em ordem de prioridade, pois é o cenário no qual você se encontra que vai definir o peso de cada um deles. :)

Oportunidade de aprendizado

Como seria minha primeira atuação com gestão de produtos, era muito importante estar em um lugar onde eu pudesse aprender muito.

A empresa na qual eu atuava passava por um momento de transformação digital, então com certeza eu teria muitos desafios atuando com gestão de produtos por lá, o que poderia significar muitas e muitas oportunidades de aprendizado dentro de um ambiente que já era habitual para mim.

Além disso, eu já conhecia pessoas da área de produtos que com certeza estariam dispostas a me ensinar e me ajudar durante esse processo de aprendizado.

Considerando uma vaga de mercado esse critério não ficava tão claro, já que não tinha como ter certeza sobre as oportunidades que eu teria uma vez que mudasse de emprego.

Remuneração

Fazendo uma transição interna, meu salário com certeza não diminuiria, mas poderia não aumentar. Consegui ter uma noção da faixa salarial da área de produto conversando com pessoas que eu conhecia e que já estavam lá.

Por outro lado, ao fazer uma transição para o mercado, meu salário poderia cair, se manter ou subir (parece algumas previsões que vemos por aí, né? 😅).

Para saber mais ou menos o que esperar de remuneração ao olhar para o mercado, usei bastante o antigo Love Mondays (atual Glassdoor) para pesquisar o salário de cargos de entrada em produto em várias empresas, e isso me ajudou bastante. No meu caso, existia uma alta probabilidade de um incremento salarial.

De qualquer forma, esse critério acabou não pesando tanto porque, de acordo com meus compromissos financeiros na época, eu poderia até me dar ao luxo de ter uma queda momentânea na entrada de dinheiro.

Velocidade de transição

Quando eu olhava para o mercado, o leque de oportunidades era muito maior do que as oportunidades de movimentação interna, pois existiam dezenas ou talvez até centenas de empresas anunciando vagas em produto (hoje em dia o cenário continua o mesmo).

Além disso, olhar para o mercado me colocava totalmente no controle da situação já que eu estaria procurando ativamente, enquanto que para vagas internas eu precisaria ser mais passivo e esperar o surgimento de algo que se encaixasse no que eu estava buscando.

Por mais que eu seja uma pessoa ansiosa — minhas unhas que o digam — , avaliar somente a velocidade na qual eu poderia fazer essa mudança sem considerar outros critérios acabou ficando algo vazio, já que velocidade por si só não me ajudaria a ter sucesso nesse momento.

Sabendo disso, considerei esse critério em conjunto com os dois abaixo.

Clareza do destino

Aqui a pergunta que eu sempre me fazia era: "Já está claro onde eu quero chegar?". Em momentos de mudança, ter clareza do destino vai te ajudar muito na definição do caminho.

Como eu tinha o costume de sempre conversar com meu líder sobre meu PDI — Plano de Desenvolvimento Individual — e nós estávamos sempre refinando esse documento, três meses foram suficientes para definir um plano de transição com ações específicas para me ajudar nesse processo.

Dessa forma, fiquei mais confortável com a possibilidade de esperar uma oportunidade interna, já que meu líder sabia do meu objetivo e me avisaria assim que surgisse alguma coisa.

Um plano bem traçado também me ajudou a ter mais clareza sobre quais tipos de vagas buscar olhando para o mercado.

Se você ainda não tem um PDI, acredito que três meses seja tempo suficiente para ter um desenho inicial definido, e já que o Medium não tem a opção de anexar arquivos no artigo (fica a dica, PMs do Medium), caso você precise de ajuda com esse plano eu tenho um modelo e dicas que podem te dar uma luz. É só chamar! :)

Direito de arrependimento

Por mais que meu plano estivesse claro, ainda assim eu começaria algo completamente novo, e nunca dá pra ter certeza de que vai ser como a gente espera, né? 😬

Olhando para o mercado eu poderia fazer uma movimentação mais rápida com pouco direito de arrependimento. Afinal, para onde eu voltaria sendo que só teria trabalhado com produto?

Fazendo uma transição interna — mesmo que mais lenta — eu poderia alinhar com meu líder a possibilidade de voltar caso as coisas não fossem exatamente como eu pensava.

Uma coisa que me ajudou a ter mais certeza sobre essa mudança foi começar a fazer atividades relacionadas à gestão de produtos no meu cargo atual (ter o PDI alinhado com meu líder ajudou bastante na priorização dessas atividades).

Ponto para a mudança interna nesse critério.

Qual caminho eu segui?

Quem desceu o texto sem ler só para saber qual foi minha escolha vai bater o dedinho do pé na quina da cama, viu?

No final, eu fiz uma transição interna porque estava em um momento muito bom na minha área e cargo atual — e isso me ajudava a ter mais paciência nessa transição — , além de estar muito bem alinhado com meu líder, que vinha me ajudando muito a desenvolver os pontos que eu precisava para trabalhar com produto.

Sendo assim, não foi um sacrifício esperar um pouco mais para fazer essa mudança!

Mudar de carreira — por experiência própria — pode ser um processo bem confuso e desgastante, então se você precisar de ajuda é só me chamar no LinkedIn :)

Até a próxima!

Como eu comecei a trabalhar com produto

E como minha experiência pode te ajudar nesse processo

Já faz alguns anos que migrei para a área de gestão de produtos e decidi contar como foi esse processo para mim na esperança de que possa ajudar quem está começando agora.

Sou formado em Análise e Desenvolvimento de Sistemas e desde o começo do curso eu tinha certeza de que queria trabalhar como desenvolvedor.

Atuei por volta de quatro anos com desenvolvimento e gestão de projetos, e por mais que eu estivesse feliz nessa área de atuação, ainda sentia falta de estar mais próximo do processo de definição da estratégia e do entendimento dos problemas (da empresa, dos clientes, do produto) que precisavam ser resolvidos.

Considerando esse desejo e o plano de carreira que eu vinha desenhando, começou a fazer muito sentido migrar para a área de Produto.

Se você — assim como o André de alguns anos atrás — também está pensando em fazer essa transição, tenho algumas coisas para falar que te ajudarão no processo. :)

1. Converse e siga pessoas (não literalmente, por favor 😆) que já atuam com gestão de produtos

Esse é um primeiro passo muito importante que vai te ajudar a:

• Entender o dia a dia de alguém que trabalha com produtos e ver se é aquilo mesmo que você se vê fazendo;
• Conhecer as soft e hard skills que são necessárias para trabalhar e ter sucesso nessa carreira;
• Ver as vagas que surgem na área e entender o que você precisa desenvolver para estar preparado para elas.

2. Estude, estude e estude!

Você vai estudar muito! Mas tudo bem se precisar de um pouco de descanso.

Começar a trabalhar com gestão de produtos vai exigir muito esforço e dedicação. Você terá uma atuação completamente multidisciplinar e isso exige estudar sobre vários assuntos para poder navegar entre todas as áreas.

Por isso, é importante você procurar por cursos, livros, artigos, podcasts e qualquer outro meio que te auxilie nessa fase.

Lembra do item 1? As pessoas que você conhecer também te ajudarão muito a entender por quais caminhos seguir e quais temas estudar.

Vou te dar um spoiler e listar alguns assuntos pelos quais você pode começar a estudar e que são importantes para trabalhar com gestão de produtos.

Ah! A lista vai muito além disso, o que eu quero aqui é apenas te ajudar com os primeiros passos. :)

Soft skills

• Comunicação, com dois temas principais: oratória e storytelling;
• Negociação;

Hard skills

• Gestão e construção de backlog;
• Discovery de produto

3. Tente aplicar na sua função atual o que você tem aprendido

Por mais distante que seu trabalho atual fique da gestão de produtos, procure no seu dia a dia atividades nas quais você pode começar a aplicar os conhecimentos que vem adquirindo. Talvez alguma estratégia de priorização para suas próprias tarefas, ou então alguma técnica de definição e resolução de problemas que você leu em um livro.

Também é muito importante que você não se prenda exclusivamente ao que aprendeu: tenha sempre em mente que na prática a teoria é outra!

O que eu quero dizer com isso é que os estudos te darão a base teórica necessária para atuar com gestão de produtos, mas o que realmente vai fazer a diferença é a forma como você utilizará esses conhecimentos para resolver os problemas que surgirem no decorrer do caminho.

Quando eu fazia gestão de projetos, por exemplo, consegui aplicar técnicas de priorização de produto para equilibrar escopo e prazo das demandas que chegavam para serem desenvolvidas.

4. Você tem um background em outra área, use isso a seu favor

Grande parte das pessoas que conheci e que trabalham com gestão de produtos hoje em dia vieram de áreas totalmente diferentes: Marketing, TI, Jornalismo, Gestão de Projetos, Design, Psicologia.

Um conselho: aproveite muito todas as suas habilidades e conhecimentos adquiridos anteriormente, porque com certeza isso te ajudará na carreira em Produto.

E por fim — porém de maneira alguma menos importante — , o que eu preciso te dizer é:

5. Você nunca vai se sentir totalmente preparado para esse momento

Calma! Não precisa se desesperar! 🤯

É absolutamente comum que você tenha a sensação de que não está preparado e que ainda falta muito para chegar lá.

E aqui vai mais um conselho (é o último por hoje, prometo): não tenha medo de perguntar, aplicar o que você estudou, errar, aprender, perguntar mais uma vez, aplicar de novo, errar novamente e aprender mais ainda… é exatamente esse ciclo que vai te ajudar ainda mais no momento de transição :)

Espero que esse conteúdo tenha te ajudado de alguma forma.

E para quem quiser trocar ideias sobre esse ou qualquer outro tema em Produto, é só me chamar no LinkedIn.

Até a próxima!