Um pouco da minha jornada nos últimos meses
Contexto
Se você perguntar algo para um profissional de tecnologia, e a resposta for “depende”, pode ter certeza, que a palavra seguinte é: contexto. Ou seja, muitas respostas não são óbvias e dependem do contexto do problema.
O contexto da minha jornada começou em 2021, quando recebi o desafio de participar da construção do primeiro app da Portobello América. A nossa empresa é a operação nos EUA da Portobello, líder no segmento de cerâmica e porcelanato no Brasil. Para deixar o desafio ainda mais complexo, a arquitetura pensada junto ao time seria de um app sem backend/BD.
Para trabalhar nesse contexto, construímos um middleware para conteúdos e disponibilizamos em um endpoint. As consultas de produto, imagem, especificações técnicas, preço, estoque, permissão de usuário… todas elas foram disponibilizadas em endpoints que construíram uma visão completa e complexa de tudo que precisávamos.
Olhando sob o ponto de vista de negócio, nosso objetivo principal é trazer nossas soluções para muito mais perto além de resolver a dor do nosso cliente final e da nossa equipe de vendas. Todas as funcionalidades foram pensadas e discutidas com um fórum amplo com forte participação até do nosso CEO, membros do conselho do grupo Portobello e nosso time operacional.
O nosso app, tem metas internas ousadas, visto nosso estágio de maturidade nos EUA, de vendas, engajamento, e o nosso requisito não-funcional número 1 desde o começo: performance.
Nosso deadline era a Coverings, maior evento do setor nos EUA, e lá seria o lançamento. Frio na barriga? COM CERTEZA. Mas confere aqui comigo alguns checkpoints:
- Publicação na AppStore: Check ✅
- Publicação na Google Play: Check ✅
- Testes com redes locais e 4g: Check ✅
- Testes com permissão/perfil de usuário: check ✅
- Material de marketing: Check ✅
- Estande: Check ✅
Tudo pronto, lançamento realizado, clientes utilizando e sendo tagueados pelas nossas visões no Google Analytics, recorde de vendas no evento.
Trabalho concluído, certo?
ERRADO!
A sustentação
Melhorias, bugs, ajustes e o trabalho só começou. Começaram também todas as métricas relacionadas ao produto e ao impacto no dia a dia da operação. Além monitoramento dos endpoints, garantias de fidelidade das bases espelhadas e muitos outros pontos técnicos se acumulando.
E a primeira pergunta foi:
Por onde começar?
Honestamente, era muito novo pra mim certos desafios sob a ótica de Gestão de Produtos e todo esse viés técnico. Criar um app sob a ótica de um dev, como já aconteceu na minha empresa (@uebile), foi uma experiência bem diferente.
Ouvindo uma palestra do @bernarddeluna dei meu primeiro passo: vou pesquisar!
Primeiro um pouco de teoria
Se você pesquisar no Google, vai encontrar posts de tudo quanto é tipo de abordagem. Tanto com viés que defende que o TPM (Technical Product Manager) seja um ex-dev tanto apenas um PM mais técnico.
Mas separei três definições que gostei bastante:
1) No nosso querido e uma das referências de gerenciamento de produtos, o PM3, a definição é:
Product Manager técnico – na maioria das vezes – tem um background tão técnico que veem facilidade em trabalhar com desenvolvedores em áreas como infra, qualidade de busca, machine learning entre outras zonas mais técnicas. Este tipo de PM consegue trabalhar em um espectro bem amplo de Produtos, desde que tenha as habilidades de negócio necessárias e bom uso de intuição para definir os melhores trade-offs dentro do Produto.
2) Vladimir Kalmykov (Group Tech PM na Booking)
Product Management base (~50% de sucesso): para lidar com os requisitos do cliente, transformá-los em pequenas histórias, priorizar, ter uma visão de curto/médio/longo prazo, entregar, etc. A base insubstituível da liderança do produto. Um exemplo aleatório pode ser priorizar um canal de mensagens específico (por exemplo, SMS) em determinados países porque os clientes preferem exatamente isso.
Conhecimento técnico de tecnologia (~30% de sucesso): Poder revelar insights tecnológicos sobre os quais os clientes nem pensaram, porque para eles é apenas um sistema, e para o Tech PM – o produto em que estão profundamente focados. Continuando o exemplo do canal de mensagens, a contribuição do Tech Product pode estar influenciando uma arquitetura de produto que, por sua vez, permitiria à empresa lançar outros mensageiros instantâneos (por exemplo, Viber, WhatsApp ou Telegram) sem problemas, ou até mesmo liderar essa expansão. Observe a diferença: não apenas o PM prioriza a necessidade do cliente, mas agora também tem uma noção de como essa mudança foi feita, e esse conhecimento (combinado com uma visão de produto de alto nível) pode desencadear novas ideias de negócios.
Domínio do assunto no mercado (~20% de sucesso): um molho de conhecimento de domínio específico no topo: por exemplo sobre pagamentos, aprendizado de máquina ou processamento de conteúdo, permite que o PM faça as perguntas certas e se aprofunde se o produto exigir. Não é uma parte crítica, porque sempre se pode aprender os detalhes se sua base for forte o suficiente. Finalizando o exemplo de mensagens, vamos imaginar que uma área específica (por exemplo, pagamentos online) impõe requisitos adicionais sobre a confiabilidade e a capacidade de ação das mensagens (por exemplo, no caso de serem enviadas para verificar uma compra), e esse conhecimento tornaria o PM um especialista melhor no assunto no contexto fintech específico.
3) Tweet do PM Diego Granado
PM(Product Manager )
WHY and WHAT are we building
Vision & strategy
Business & GTMTPM(Technical Product Manager )
HOW are we building it
Technical requirements
Scale, Reliability, Development⚠️ Not every company makes the distinction between PM & TPM
✅ Do a lot of research for each company/role
Os primeiros abordaram em uma maneira qualitativa e o terceiro foi bem generalista e objetivo. Cabe ressaltar, no meu ponto de vista, que o COMO determinada task/feature vai ser solucionada deve ter a soberania do time técnico.
Por mais técnico que o PM seja, ele não vai ser melhor que o time dev.
Porém ainda não tinha encontrado o que eu queria. O objetivo da pesquisa era ter um guia, um stack default que me preparasse para os desafios atuais e os que ainda estão por vir.
Quando você busca por ai, encontra guias para devs, product managers, project managers, adm de banco de dados, data pm, mas não encontrei nada sobre TPM(Technical Product Manager).
Lembra do contexto?
Comecei a perguntar então, para pessoas que já exercem a profissão em grandes empresas (Nubank, CI&T, Loft, Remessa Online, Olx Portugal, Pier) e todas as primeiras respostas foram: “Depende do contexto”.
Antes de continuar, queria agradecer
agradecer muuuuuuito toda a paciência
que esses profissionais tiveram comigo.
Foi sensacional trocar experiências e
ouvir os desafios de vocês. 💛💜
Visão dos TPM
Com o devido contexto passado, e eu sei que foi um textão até mesmo para o linkedin, o pessoal me sugeriu algumas referências e ferramentas que poderiam ser úteis. Abaixo segue o compilado:
- SQL – Para validar e extrair informações
- AWS – S3, EC2, Lambda, ECS, e os diversos outros serviços, te ajuda a guiar os devs pelas melhores soluções.
- Postman – O famoso aliado do meu dia a dia e de muitos TPM.
- Swagger – Quebra o galho se você não tem o postman
- Conhecer algum linguagem de programação – Não para codar, mas entender das possibilidades e o que isso pode entregar. Ex: com flutter, você pode desenvolver para iOS e Android. Eu até fiz alguns posts sobre flutter a um tempo atrás aqui e aqui.
- Integrações – conceitos de api, endpoint, view(BD), middleware
- BI – Saber criar visões para extrair insights de negócio.
Visão dos devs
Contei com a ajuda de alguns amigos devs, de empresas como XP, Zup, Agile Content para entender o que seria interessante um TPM saber que facilitaria a discussão. O resultado foi esse:
- Data lake/BI: Várias fontes de dados no mesmo local possibilitando criar dashboards, alarmística e afins.
- Noção de arquitetura: sistemas legados e conceitos.
- BDD – metodologia ágil colaborativa que ajuda bastante em entender cenários e possíveis soluções.
- AWS – Como vai ser feito o deploy? fargate?
- AWS RDS – Banco de dados.
- Azure ou Google Cloud – saber diferenças e vantagens.
- Banco de dados NoSQL – Banco de Dados Não Relacionais
- Conhecer algum linguagem de programação – a sugestão é saber pelo menos javascript.
- Segurança – Saber sobre tipos de autenticação e o impacto disso no software e nas integrações
Core/Resultado
O resultado é basicamente a sinergia entre o que há de comum no que os DEVs gostaríam e o que de fato, os Technical Product Managers estão praticando no mercado.
É lógico que fica a nosso critério e o contexto no qual estamos, fazer a triagem e identificar o que mais faz sentido para nossa realidade, mas como guia ou stack default, esse compilado servirá como um primeiro passo.
Espero, de verdade, que isso possa ajudar aqueles que, como eu, estão passando por esses desafios ou estão prestes a começar.
Se você identificou algo que possa colaborar com esse post, me chama no Linkedin ou Instagram, que a gente bate um papo.
Mais uma vez, obrigado a toda a galera que me ouviu nas últimas semanas.