Progressão de carreira de Produto Managers

Minha percepção é que as profissões dentro do mercado de tecnologia evoluem muito mais rápido do que outras. Existem várias hipóteses para justificar isso, como evolução rápida da stack tecnológica e dos métodos e processos utilizados no mercado. Só isso já faz com que os profissionais precisem se atualizar numa velocidade maior que em outros mercados.

A quebra em especializações é outro fator bem interessante que acontece com essas profissões. Se você percebe, todas as especialidades começaram aglutinando responsabilidades, depois tiveram alguns níveis de amadurecimento que criaram divisões e quebras de responsabilidades. Em alguns casos essa quebra faz sentido e foi bem benéfica, em outros casos, na minha opinião, prejudicou mais do que ajudou.

Um dos exemplos benéficos é da área de programação. No início só existiam programadores e pronto. Não quero pegar a timeline histórica muito longa, mas antes só existiam programadores. Geralmente desenvolvedores de software offline ou de hardware. Com a vinda de novas tecnologias como a internet e depois a web, a gente viu os programadores web surgirem.

Ainda no início eram só programadores, mas logo depois uma quebra surgiu, criando programadores back-end, depois front-end. E nessa também alguns já foram para área de arquitetura e infraestrutura. Hoje, programação está em toda parte que faz sentido. Mas não surgiu nenhum tipo de programador que só aperta um tipo de parafuso ou que faz só uma parte muito específica do processo que não pudesse ser feita dentro de um contexto completo. O que não é o caso de design.

Design, para mim, é o exemplo que não houve tantos benefícios. Houve uma linha muito parecida com os programadores. No início eram designers "offline" por assim dizer. Arquitetos entram nessa também. Tudo muito atrelado ao mundo físico. Mesmo aqueles que trabalham com design gráfico. Se você separar por contextos, essas quebras fazem muito sentido.

Quando a web veio, ainda continuou fazendo sentido com os designers dominando e controlando todo processo de design, desde sua descoberta, planejamento, aplicação, manutenção e evolução. Num passado recente isso se quebra em diversas micro-partes, onde seus contextos muito pequenos. Eu entendo que em alguns momentos existem necessidades de execuções muito específicas... mas o problema é que o mercado transformou disciplinas em contextos de execução. Isso vale para research, vale para writing e outros. Hoje, há um movimento de aglutinação dessas especialidades de novo, criando novamente um designer que entende do processo como um todo e sabe se adaptar à necessidade de cada projeto. Mas, esse é um assunto espinhoso, que nem todo mundo gosta de discutir com maturidade. Deixo para próxima.

Essa evolução de maturidade também aconteceu com Gestão. E nem quero me alongar muito, puxando o histórico lá de trás com nomes como Taylor. Quero começar a discussão a partir de agora, da nossa vida mais conhecida e recente. A Gestão de Projetos evoluiu e sofreu disrupções interessantes até chegarmos onde estamos agora.

A gestão de projeto se quebra

Quando falamos sobre gestão de projetos, nós imaginamos ao famoso PMO, Project Management Office, que tinha como principal função garantir que o projeto fosse entregue dentro do tempo, com o escopo pedido e sem furar o budget. Para garantir isso, métodos e frameworks de processos são aplicados e uma série de rotinas de report são feitos para garantir que todos estão alinhados quanto aos principais pontos do projeto.

Logo, quem gere projetos precisa ter uma visão clara sobre processos. Isso não quer dizer que se aplica apenas a software, pelo contrário. Se você pega a história do PMI (Project Management Institute), você vai ver que eles fizeram um aeroporto. Eles participaram do programa Apollo. Eles participaram da criação do primeiro celular feito pela Nokia. Hoje a galera de produtos torce a boca quando fala sobre gestão de projetos, desdenhando de uma especialidade que eles não sabem fazer.

Gestão de produtos é uma derivação (não encaro como evolução) da gestão de projeto. Muitos PMs e líderes de produto não sabem gerir projetos, ou por falta de oportunidade, ou por que migraram de outras áreas, onde essa habilidade não era necessária. Talvez essa seja uma grande causa da síndrome da não entrega. Falta organização e processo. Mas essa é outra história.

Com a vinda da internet e da web, a popularização do smartphone, a evolução da Web 2 e todas as alavancas que fizeram as pessoas ficarem cada vez mais conectadas e viciadas em software, fez com que essa profissão também amadurecesse. A gestão de software é complexa, porque faz parte de um ambiente complexo. Embora construir prédios seja perigoso e pode acontecer uma série de problemas durante o caminho, há um processo bem estabelecido que traz alta previsibilidade da entrega atrelada a alta qualidade. Isso por que embora sejam projetos grandiosos, são projetos que rodam na sua maioria das vezes na camada complicada. Diferente da camada de software, que geralmente está na camada complexa.

A construção e desenvolvimento de software roda na camada complexa e caótica. Nosso esforço em gestão de produtos e gestão técnica é uma vigília constante para diminuir incertezas para tentar posicionar e manter o nosso produto na camada complicada. E muita gente se perde nesse ponto.

Diferente de uma construção de prédio que o trabalho vai ficando progressivamente mais "simples" conforme as partes são construídas, o software vai ficando cada vez mais complexo. E isso se potencializa quando há pessoas usando.

É aí que entram as metodologias ágeis. E quando as metodologias ágeis chegam, a gestão de projetos se quebra. Por que se antes a gestão de projeto cuidava da liderança do projeto cuidava da garantia de que as coisas fossem entregues no escopo, data e budget, agora ela precisa sustentar a continuidade das entregas, então, o budget que tinha um limite claramente estabelecido no projeto, agora precisa ter uma visão mais conectada à sustentação financeira do negócio. Não que o dinheiro é infinito, porque não é, vide os layoffs que temos ultimamente, mas é que nessa visão de produto, a sustentação da continuidade para geração de resultado é mais importante que a finalização do projeto.

O Impacto do Agile

Então, com a vinda do Agile, uma visão maior e estrutura de processo de entrega sustentada, com eficiência e qualidade, com frequência de entregas constantes, se criou na maneira com que criamos produto.

Acontece que há um outro lado da gestão que não envolve apenas processos e métodos, mas geração de valor. A gestão de projeto tinha em mente a geração de valor para o negócio por meio da entrega do projeto. O único problema com isso, é que atualmente, projetos baseados em comportamento de usuário, que procuram entregar valor constante para seus usuários, não tem fim. E se não tem fim, cria-se um ciclo de entrega constante de valor para o usuário, que se reflete com valor no negócio. Então, não dá para entregar o projeto e pronto, tem que entregar, aprender, evoluir, testar e monitorar, para construir e entregar de novo. Daí que vem o Dual Track Agile Discovery Delivery Cicle Hiper Blaster Master Beta Gama que todo mundo fala.

A derivação para a gestão de produto

E quando esse ciclo acontece, a gestão de produto surge. Porque o trabalho de priorização que acontece na gestão de projetos tradicional, se torna um trabalho contínuo, então, a fase de entrega final não acontece. E essa gestão contínua, procurando a eficácia e a diminuição de incertezas, tentando posicionar e manter o software na camada "complicada", evitando que ele entre na área "complexa", enquanto gera valor pro negócio por meio da geração de valor para o usuário.

Então, a gestão de projeto, na verdade, não morreu. Existem ainda projetos que acontecem cross empresa, que precisam de pessoas que façam a costura entre todas as áreas, inclusive a área de produtos, trazendo para mais perto de um objetivo comum. Isso nunca vai ter fim e o pensamento de gestão de produto não se encaixa nesse caso.

E a gestão de produto entra como uma vertente desse tipo de gestão. Gestão de produtos precisa fazer gestão de projetos. Cada feature, cada entrega, cada previsão, roadmap, expectativa, é uma prática de gestão, que migrou da gestão de projeto.

Quando falamos sobre a entrega continuada de valor, nós precisamos definir o contexto de impacto de cada uma das fases e níveis de maturidade de um profissional de produto.

Nomenclatura, cargos e contextos de impactos

Participar do contexto do seu nível de experiência faz parte da evolução da maturidade nessa profissão (e também de qualquer outra). Entender o contexto que você está inserido, também ajuda a não se preocupar com alçadas que você não controla. Isso quer dizer menos desperdício de energia, menos frustração, mais tempo para fazer seu trabalho com qualidade.

Muita gente que entra na área fica preocupada com a sua atuação com um anseio de querer atuar em contextos maiores, mais "importantes". Existe uma percepção errada no mercado de que quanto mais próximo do negócio e do topo da pirâmide, mais importante e mais sucesso você tem. Esse é outro assunto, mas minha opinião sobre isso é que você precisa encontrar o equilíbrio entre conforto, evolução, dinheiro e saúde. Você precisa saber o que é suficiente para você.