Mesa de Produto #106 - O que faz um Product Engineer: Definir, Construir e Lançar
📌 Formação Product.Engineer + PM3: seis semanas ao vivo para definir, construir e lançar seu produto, com mentores de Airbnb, Hotmart e Zup. Candidate-se à próxima turma:
👉 https://www.product.engineer/pt-BR/PM3
Neste episódio do Mesa de Produto, Raphael Farinazzo recebe Felipe Barreiros para falar de um tema inédito no programa: A carreira de Product Engineer. É um episódio remoto, com o Felipe direto do Texas.Felipe é Senior Product Engineer na AWS. Criou o primeiro bootcamp de tecnologia do Brasil, já contratou mais de 600 desenvolvedores, empreendeu duas vezes no Brasil e vendeu uma de suas empresas para o Banco Modal. Na conversa, ele define o Product Engineer pelo mesmo ciclo que dá nome à formação que assina em parceria com a PM3: define, constrói e lança.Assuntos do episódio:
• O que é Product Engineering e por que o termo ganhou relevância agora
• Definir, construir e lançar: os três eixos que Felipe usa para descrever o papel
• Os três perfis que estão migrando para a área: engenharia, gestão de produto e Builder
• A diferença entre Builder e Product Engineer, com foco em arquitetura, escala e segurança
• Como o tempo de trabalho se inverteu: menos execução, mais definição, teste e validação
• Times em pods de duas a três pessoas, donas de um escopo de ponta a ponta
• Impacto, escopo, ambiguidade e complexidade como balizadores de senioridade
• O que muda para quem está começando e por que júnior precisa de menos ambiguidade
• Projetos pessoais e paralelos como treino real de habilidade
• O caso do profissional de cibersegurança que nunca tinha aberto um terminal
• A queda da barreira de entrada em tecnologia e o papel da educação formal
🎯 Deixe seu like e se inscreva para mais conteúdos sobre produto, IA e tecnologia.
#ProductEngineer #ProductEngineering #GestãoDeProdutos #CarreiraEmTech #IA #MesaDeProduto
- A definição e o papel do Product Engineer no cenário atual de tecnologiaProduct Engineering·Inteligência Artificial·Engenharia de Software·Gestão de Produtos
- O papel dos projetos pessoais no desenvolvimento de habilidades de Product EngineerDesenvolvimento de habilidades·Empreendedorismo·Inteligência Artificial
- A formação Product.Engineer para definir, construir e lançar produtos digitaisProduct.Engineer·PM3·Desenvolvimento de produtos
- A distinção entre Builder e Product Engineer e suas responsabilidadesBuilder·Arquitetura de sistemas·Segurança de sistemas
- A mudança no tempo de trabalho: mais definição e validação, menos execuçãoDesign de solução·Testes e validação·Inteligência Artificial
- A importância da senioridade e a gestão da ambiguidade para Product EngineersImpacto·Escopo·Ambiguidade·Complexidade
E o que acaba surgindo é um mix onde esse profissional, na minha definição, ele faz 3 coisas: define, constrói e lança. Define visão, define prioridade, define métricas. Constrói com IA, constrói com segurança, constrói com uma arquitetura que escale. E de fato lança, para você poder ter usuários, você acompanhar como que eles operam dentro da tua plataforma e fechar o ciclo de feedback.
Olá, seja muito bem-vindo, muito bem-vinda a mais um episódio do nosso Mesa de Produto. Hoje temos um episódio remoto especial porque nosso convidado está no Texas, é o Felipe Barreiros da AWS. Felipe, seja muito bem-vindo. Ao Mesa de Produto.
Obrigado, super feliz de estar aqui, Farina. Obrigado pelo convite.
Valeu demais. E hoje a gente vai falar sobre um tema que é inédito aqui no Mesa de Produto, que é Product Engineering, ou a carreira de Product Engineer, que enfim, começamos a ouvir esse termo aí recentemente. Na verdade, o termo é mais antigo, né, mas o termo ganhou muita relevância recentemente aí depois que as IAs começaram a codar e fazer muitas coisas por nós. Mas o Felipe, que é especialista no assunto, é quem vai dizer para gente, Felipe, O que é exatamente o Product Engineer ou a disciplina de Product Engineering?
Eu, obrigado, assim, esse é um termo que de fato tá começando a ter muito mais relevância por conta de IA, mas muito por conta de uma mistura de, na minha visão, de duas grandes carreiras que são muito tradicionais, principalmente nos Estados Unidos é muito tradicional, a gente vê o engenheiro de software, a engenharia de software no geral, e a gestão de produtos, uma gestão de produto técnica, não só uma gestão de produto de acompanhamento, de entendimento do processo de construção de um produto que não necessariamente precisa ser técnico.
E o que acaba surgindo é um mix onde esse profissional, na minha definição, ele faz 3 coisas: define, constrói e lança. Define visão, define prioridade, define métricas, constrói com IA, Constrói com segurança, constrói com uma arquitetura que escale e de fato lança para você poder ter usuários, você acompanhar como que eles operam dentro da tua plataforma e fechar o ciclo de feedback. Acho que é essa, essa nova, esse novo cargo, essa nova forma de trabalhar, ela vem justamente porque a engenharia fala assim: eu posso definir um pouco mais de produto, produto fala assim, eu consigo entregar um pouco mais agora que eu tenho IA para poder me apoiar, porque eu não preciso desenvolver código na mão.
E essa nova, novo cargo, nova área, ela tá começando a fundir. E cada vez a gente vê empresas abrindo mais vagas sobre isso, empresas mudando os seus cargos para que elas possam ter esse tipo de profissional. E a própria, o próprio profissional querendo ir para essa vaga, querendo estar nesse papel onde ele possa ser dono do, da ideia, o impacto. É isso que eu trabalho. Você não só tem ideia, você não só constrói, você não só avalia o impacto, mas você faz o processo como um todo.
Muito bacana. Eu tenho várias perguntas até mais para frente, pessoal. A gente vai conhecer mais da carreira do Felipe. Eu vou perguntar como ele chegou nisso. Mas antes, agora que você falou que ele define, constrói e lança, para a gente entender em termos de carreiras que já existem, quando você traz dessa forma, eu penso na carreira de gerente de produto, eu penso na carreira de um designer de produto, na carreira de um engenheiro de produto, um engenheiro, né, de dev mesmo, um arquiteto de solução também, arquiteto de código, e até do Product Marketing Manager, que é a pessoa que lança de fato, né, que cria GTM, posicionamento.
Essa cadeira, ela engloba qual desses papéis, ou quais desses papéis, assim, ou todos?
Espetacular você ter perguntado isso. Eu lembro uma conversa, vou trazer um caso pessoal aqui, que no final de 2025 Eu moro no Texas, eu moro em Austin, e aqui tem um boom de profissionais de tecnologia, é um grande polo de tecnologia aqui na cidade. E um engenheiro chegou para mim e ele falou assim: Felipe, eu estou profundamente preocupado com o que eu estou focado hoje na minha área, no que eu fiz e no que eu investi a minha carreira em cima disso, porque eu tô vendo que os modelos estão se aproximando para poder executar exatamente o que eu faço todos os dias.
E esse é um profissional que ganha $350 mil no ano, não é pouca coisa, profissional muito bem colocado, com respeito gigantesco. E ele falou, eu deveria ter gastado mais tempo olhando ou focado minhas habilidades para olhar mais para negócio, para crescimento de business, etc. Eu foquei muito na parte técnica. Acho que por razão, durante muitos e muitos anos, durante décadas na verdade, é uma das carreiras mais bem remuneradas aqui nos Estados Unidos.
Então o que eu vejo é um profissional de dev querendo sair desta bolha apenas de desenvolvimento. Eu vejo também as pessoas que ficam ao lado da carreira de engenharia, que é o gestor de projeto, que é o gestor de produto, são as pessoas que o QA, né, o Quality Assurance Engineer, a pessoa que faz os testes padronizados para garantir que isso passe, etc. Então essas pessoas que normalmente trabalham com a engenharia E numa terceira camada aqui, Farina, eu vejo um profissional que é um profissional que eu chamo de builder, que é o gerente de marketing, que é o pessoal de operações, que é o pessoal que trabalha no financeiro, que está olhando para isso, está construindo seus dashboards, está construindo suas aplicações.
Algumas vezes são profissionais de cibersegurança que nunca teve nada relacionado a desenvolvimento, mas olha assim, ó, eu sou um profissional de tecnologia, Eu tateio ali um pouquinho de tecnologia, será que eu posso me atrever a entrar nesse mundo? Então veja esses 3 grandes perfis, colocaria não como se fosse um foco, né, mas eu colocaria 3 grandes perfis. Perfil de um profissional de desenvolvimento que olha assim, eu preciso olhar um pouco mais para estratégia e negócios.
Um profissional que ele já está inserido junto com o cliente, com o consumidor ali, assim, eu posso me arriscar um pouco mais aí, desenvolver mais as minhas habilidades técnicas. E esse terceiro profissional, que é o profissional builder.
É legal você ter tocado no builder porque tem essa distinção entre o builder e o product engineer, de certa forma, né? Você trouxe bastante assim, ah, o builder é a pessoa de marketing, financeiro, do RH. Até curiosamente a gente teve uma pessoa de marketing aqui na PM3 que entrou recentemente e começou a buildar um monte de coisa, dashboards, ferramentinhas, etc., nos primeiros 3 meses. Eu falei, cara, você é mega builder, né?
E ele falou assim, É mesmo? E foi um insight assim, nossa, sou mesmo, nunca tinha parado para pensar nisso, né? E ele falou, pô, engraçado, eu pensava em builder como a pessoa de engenharia, né? A pessoa de engenharia que tava usando IA, ou até um PM que tava usando IA, mas não eu de marketing. Ele falou, cara, mas você é mega builder assim, você é um dos maiores builders dessa empresa agora. E teve esse clique. O que que é isso assim, né?
Você vê, a pessoa ainda associava o builder a produto, engenharia, mas você trouxe vários outros papéis. Ao mesmo tempo tem o product engineer, É a mesma coisa? Não é a mesma coisa? O que que um precisa saber mais ou menos do que o outro? Não sei, não vamos colocar assim um melhor do que o outro, mas realmente áreas de saber diferentes, né?
Excelente pergunta. Eu vou fazer um comentário em relação do Builder, porque quando eu comecei a falar de Product Engineering, sobre Product Engineer, ou muitas vezes quando eu traduzo para o português eu trago como a engenharia de produto digital, as pessoas olham e fala assim: é isso. É isso que eu quero, é isso que eu quero seguir. As pessoas olhavam, entendiam que elas queriam se tornar mais técnicas, ou a galera de engenharia sabia que elas queriam estar mais próxima de estratégia, e elas olham esse termo e falam, é isso aqui.
E é super curioso você ter falado isso do builder, porque são pessoas que estão se sentindo agora com um arcabouço, com ferramentas aqui para poder de fato construir. O que que eu definiria como builder? Acho que o builder é um princípio por uma carreira mais profunda de Product Engineering, Porque o Product Engineer tem que ser responsável pela arquitetura, pelo design do sistema, pela segurança do sistema. O que a gente mais vê hoje em dia são plataformas.
E assim, eu acabo falando com muitos amigos que são builders, eles construíram plataformas, etc., e são muito bons de venda muitas vezes. Eu tava recentemente falando essa semana com um colega meu, ele tem 20 mil usuários dentro da plataforma, ele tem 6.400 conversas de suporte que estavam completamente abertas. E tinha, desculpa, 60 mil clientes, 20 mil comprovantes de pagamento e 6.400 conversas com suporte dele que estavam completamente abertas.
Então o que que eu vejo é, muitas vezes o builder, ele tem a competência porque ele sabe muito bem da dor do cliente, ele sabe muito bem a experiência que tá sendo construída. E a minha sugestão para o builder é Builder entenda um mecanismo para você poder garantir que ninguém vai acessar isso aqui ou ninguém vai poder entrar e roubar algum tipo de dado. Então muitas vezes o Builder, o que ele faz? Ele cria uma automação interna, ele cria uma automação que roda dentro da companhia, é um dashboard, é uma apresentação que você vai fazer com, ao invés de usar PPT, ao invés de usar Keynote, você vai usar um Cloud Code da vida, etc.
Quando eu vejo um Product Engineer, é alguém responsável por dar suporte a dezenas ou centenas de milhares de pessoas. É alguém que vai entender como diferentes componentes dentro de uma aplicação vão funcionar, eles vão interagir para garantir que você tenha uma boa aplicação. Então o processo do Product Engineer, minha visão é justamente alguém que é dirigente, é alguém que vai olhar a experiência e vai entender a longo prazo para onde a gente tá chegando.
Então se eu tô construindo uma experiência aqui, que é assim, acho que a grande raridade hoje em dia É a gente pensar de fato para onde a gente tem que ir, o que que a gente tem que construir, porque construir tá cada vez ficando mais abundante. Então se eu colocasse, se eu fosse plotar aqui dentro de uma, de um gráfico, antigamente como que a gente tinha? A gente passava pouco tempo fazendo design, pouco tempo na ideia, bastante tempo na execução, no coding, entender arquitetura, etc., e aí pouco tempo em testes e pouco tempo em validação mesmo se teve impacto.
Eu acho que esse gráfico ele girou. Então a gente passa hoje, deveria passar muito mais tempo entendendo o que a gente vai fazer e para onde a gente tá fazendo, construindo o design dessa solução. E aí design eu falo de arquitetura, eu falo de segurança no geral. Pouco tempo construindo porque a gente pede para IA fazer, e aí você vai dormir, você volta quando você tem um long-running prompt, né? Você tem aqueles prompts que rodam durante horas e horas e horas, você pede para poder verificar uma série de coisas.
Mas depois você passa bastante tempo fazendo teste, bastante tempo entendendo se a experiência tá certa, bastante tempo para ver se tem um impacto certo. Então para mim essa é a diligência do Product Engineer, é alguém que vai entender não só o que a gente tá fazendo e por que a gente tá fazendo, mas também garantir que a gente vai ter uma roadmap de longo prazo, garantir que as coisas encaixam, que a ideia do produto se encaixa, e também que a parte técnica, que a gente tem os componentes certos, que a gente tem a segurança certa para a gente vazar nenhum tipo de dado.
Que legal! Você tem visto, quando você traz dessa forma assim, parece que você descreveu mais o trabalho— vou te dizer assim, se a gente tivesse em 2019, eu ia falar assim, pô, Felipe descreveu o trabalho de um squad. E aí a gente tá aqui anos depois e você tá descrevendo o trabalho de um profissional. É uma pessoa, é um squad de uma pessoa só, é assim, ou não? Você vê, não, geralmente trabalham 3 ou 4 product engineers juntos, ou Cara, é um sozinho, ele é um squad, ele é um squad, ele se resolve sozinho ou não, ele precisa de pares, ele precisa de outras disciplinas.
Como que você tem visto isso, não só na AWS, né? Você é instrutor de curso de Product Engineer, enfim, tá super imerso nisso. Como você tem visto isso no mercado? Não sei nem se tá igual aí Estados Unidos e Brasil.
Eu tenho visto o seguinte, acho que o Product Engineer ele tem uma competência de começar sozinho, porque ele vai ter ideia, ele vai colocar isso, ele vai mostrar. Mas por definição, quando um produto ele começa a ficar mais maduro, ele, você vai trabalhar em pods, que eu chamo. Então não é uma squad mais, eles são pods, são pods de 2 a 3 pessoas que são altamente assim committed, são donas do começo ao fim daquele módulo, daquele produto de onde você vai ficar trabalhando.
E a minha dica assim, se você é gestor de pessoas, se você é gestor de tecnologia, gestor de produto, Uma das coisas que eu tenho dado muitas dicas para CTOs, CPOs, etc., é o seguinte: se você quiser implementar um pouco mais de Product Engineering dentro da tua companhia, entenda qual que é o nível de ambiguidade ou complexidade que as pessoas vão trabalhar. O que eu quero dizer com isso? Se é um profissional júnior, se é um estagiário, você vai dar uma função para aquela pessoa.
Ela vai ser dona do começo ao fim. Então, para desenhar para que serve essa função, e aí você vai construir a função, e quando você lançar, quantas pessoas estão utilizando, se você tá tendo rate limiting, se você tá tendo throttling, se você tá tendo algum tipo de problema, estão com os alarmes certos, você colocou os canaries certos, você fez os testes para garantir que aquela função esteja rodando. E aí você vai subindo, então de uma função você vai para um componente, você vai para um widget, depois um profissional sênior você vai para um produto, que essa é minha definição.
O Product Engineer é um profissional sênior que tem exposição na tecnologia tem exposição a negócios e é responsável do fim a fim, é responsável da ideia ao impacto. E aí a gente busca esse profissional, a gente busca fazer, incentivar com que as pessoas cheguem para que você possa ser dono de um produto. E aí logo depois disso tem um profissional principal, um profissional staff que você vai encontrar, que é um profissional que vai olhar para múltiplos produtos, muitas vezes dentro de uma companhia, seja uma companhia grande, seja uma companhia média, você vai encontrar múltiplos produtos, você vai ser não responsável por executar 100% disso, mas por influenciar os times para que estes produtos possam se casar, para que esses produtos possam se conversar.
E aí, num outro passo, que eu chamo de Distinguished, que é o que a gente chama aqui nos Estados Unidos bastante de Distinguished, que seria o Senior Principal no Brasil, Senior Staff no Brasil, seria um profissional que vai incentivar uma mudança de comportamento da indústria. Então, se a gente pegar, por exemplo, o comportamento de indústria de receitas, como que médicos fazem receitas para os seus pacientes, A mudança não é apenas dentro da tua companhia, dentro dos produtos ou da série de produtos que você tem dentro da companhia.
É como você consegue mudar e incentivar com que a indústria mude. E aí tem mecanismos para poder fazer isso, para que você possa fazer uma mudança sistêmica, eu vou colocar aqui. Então a minha sugestão é sempre essa: você trabalhar em pods de 2 a 3 pessoas extremamente comitadas e donos 100% desse processo, mas de fim a fim determinados escopos. Então você pode ser de uma função, de um componente, de um produto, de múltiplos produtos, ou de fazer uma mudança da indústria como um todo.
Essas 3 pessoas seriam 3 engenheiras de produtos digitais, ou não? Um é Product Engineer e os outros 2 têm outro perfil?
Eu sugiro chamar essas pessoas de Product Engineers. No final do dia, você vai trazer o teu melhor para campo, né? Então, por exemplo, eu sou uma pessoa, eu adoro a parte de UI, adoro a parte de UX, eu adoro entender experiência, ver se as pessoas encontram ou não. Mas se você vai ver no meu dia a dia, eu tenho um trabalho extremamente técnico de construção de arquitetura, etc. Mas eu penso arquitetura de informação, arquitetura do que que eu tô colocando ali, mas também arquitetura dos componentes.
Quando eu vou trocar, por exemplo, trabalho hoje com data engineer, espetacular, assim, genial. Ele também constrói software, ele também constrói a parte de back-end, ele também constrói os componentes. Então, mas o que que a gente traz para campo na hora que precisa resolver um problema super crítico de dados? Ele que vai resolver, é ele que vai trabalhar. Quando eu preciso trabalhar com alguma questão sobre a parte funcional, ou seja, entendimento do negócio específico que eu tô trabalhando, eu trabalho com uma outra profissional que trabalha comigo também, que a gente A gente troca, faz essa troca.
Então a reflexão aqui que fica é: você não vai deixar de ser você mesmo, mas o que você vai trazer para campo vai poder fazer essa grande diferença dentro desse pódio.
Isso é muito legal, porque eu vejo ainda o profissional inteiro, né, que a gente já fala há tantos anos, né, da pessoa que é generalista e tem uma especialidade. Às vezes as pessoas falam até que tem que ter mais de uma especialidade ali, um M, um W, sei lá qual é a letra. Mas é isso, parece que a sua área de origem ela de alguma forma vai moldar quem você é, né? Você tava falando assim, ah, eu gosto muito de UI e tal. A minha área de origem é marketing, eu fui copywriter, eu sou de textos.
Então até quando eu era PM, ainda antes da IA mudar tudo, né, nos squads, eu lembro que a parte de writing, de escrita, sempre ficou mais em design do que em produto. Mas dentro do meu squad, o meu designer falou, cara, eu não sou bom nisso e você claramente é, vamos trocar, faz você assim, né? Traz você a proposta lá na design review, eu levo a proposta do squad que é sua. Como a proposta do Squad. Eu que apresento, eu que defendo ela, mas faz você.
E essas trocas no nível de time, que para mim inclusive são indícios de times maduros, times que conseguem olhar e falar, pô, tem a job description, mas tem no que cada um é bom aqui. Se você for ver, a job description provavelmente dos product engineers vai ser a mesma dentro da organização, mas você coloca 3 num time, acontece o que você falou, tem um que é mais de data, tem um que é mais de UX, tem um que é mais de negócio, Quase que a gente poderia dizer que é o velho trio de produto de novo funcionando, só que botando os pés nas outras áreas. É isso mais ou menos? Tô errado?
Dá uma olhada um pouco nas empresas, nos laboratórios de IA. Então vamos dar uma olhada aqui rapidinho em laboratório de IA. A gente pode pensar na Amazon AI Labs, a gente pode pensar numa Anthropic da vida, a gente pode pensar numa OpenAI. O que o pessoal tem trazido muito, uma ZEI, O que eles têm trazido profissionais, eles têm colocado eles como part of the technical team. Então assim, eu sou uma pessoa, eu entrei para dentro da equipe e eu faço parte da equipe técnica.
Mas qual que é o teu título? Não, faço parte da equipe técnica. O problema que eu vou resolver depende muitas vezes da organização, da estrutura que você está. Mas o que eu acredito que o Product Engineer deveria ter, e o member of the technical staff, é assim que eles chamam, member of the technical staff, você tem que procurar qual que é o problema que você vai resolver. Você vai entender, porque você é um profissional sênior que tem exposição à tecnologia, tem exposição ao negócio, sabe muito bem, e você tem exposição aos dados que estão ao seu lado também.
Então você vai lá e você vai entender qual que é o tipo de problema que você precisa resolver. Será que é fazer com que mais pessoas saibam sobre a empresa? Será que é criar mecanismos para poder educar as pessoas? Ou será que é resolver um problema gigantesco que pode ter na parte de research para você poder desenvolver um novo tipo de treino ou de, enfim, faz parte do teu perfil. O que que você traz para mesa? Então, o que que os laboratórios estão fazendo?
Eles estão reduzindo a necessidade de você pensar nesse tipo de desafio, assim, qual que é exatamente o meu cargo. Não, vem para cá e vem resolver problema. Você é uma pessoa técnica, você é uma pessoa que tem exposição suficiente Ah, o negócio é entender onde a gente tá e eu preciso que você me traga qual que é o impacto que você está fazendo, qual que é o escopo que você tem. Tem 4 palavrinhas que eu gosto bastante, que é impacto, escopo, ambiguidade e complexidade.
Então, quando você olha para esses 4, eles acabam sendo balizadores para ver de fato se você está indo para uma direção ou está indo para outra, ou se você poderia aumentar escopo, consequentemente você acaba aumentando o seu impacto. Mas de vez em quando você não tá resolvendo problemas tão ambíguos. Um Product Engineer Sênior, acredito eu, é uma pessoa que tem uma ambiguidade enorme e precisa fazer a decisão. Para onde que eu vou?
Para a esquerda, para a direita, para cima, para baixo, para frente, para trás? Então eu acho que o Product Engineer ele acaba sendo mais libertador, inclusive, porque ele não te trava onde você é UX Designer e você vai fazer UX Design. O que eu mais tenho ouvido, tenho falado com vários CTOs aqui nos Estados Unidos, é Meus UX designers agora estão entregando código, estão entregando funcionalidade para produção. E aí a reflexão é: como que eu construo?
Eu como CTO, né? Como que eu construo uma pipeline, eu construo uma experiência de desenvolvimento para que pessoas não técnicas também comecem a entregar? Então, de vez em quando, o trabalho do Product Engineer pode ser até como que eu escalo a construção da solução através de outros, não eu construir a solução eu mesmo.
Cara, isso é maravilhoso. Eu tenho tanto assunto para abrir aqui que acho que a gente vai precisar de uns 3 episódios, mas eu vou escolher um que eu acho que a gente precisa falar dele, que é de soft skills, tá, de habilidades comportamentais e humanas. Quando você traz esse cenário, eu acho maravilhoso. Eu falo assim, pô, eu, se eu tivesse, se eu não fosse eu, tivesse no mercado aí de tech, eu ia estar, cara, emocionado com esse cenário.
Mas isso exige, do ponto de vista de soft skills, uma habilidade de lidar com incerteza, com imprevisibilidade. Por assim, qual é o meu cargo? Quando eu vou ser promovido? Quando que eu posso pedir aumento? No próximo ciclo, o que que eu vou colocar na minha performance review para defender que eu preciso ser promovido? Assim, você tira completamente a previsibilidade e os guardrails de carreira, vamos dizer assim, o que geralmente para uma pessoa sênior é assim Beleza, nunca quis esse negócio mesmo, tá ótimo.
Mas você pega um júnior, ele vai falar: não, pera aí, quando que eu viro sênior, né? E aí a gente— e aí eu queria diferenciar na pergunta que eu vou te fazer assim: vamos pensar que existe júnior, pleno e sênior, ou senioridade, vai, tem várias escalas, não precisa ser 3. Existe a senioridade em hard skills e capacidade de entrega, mas existe a senioridade em soft skills. Me parece que a pessoa que é mais júnior tem menos senioridade em hard skill para fazer um negócio desse, já precisa ter maturidade, em vez de senioridade, maturidade de soft skill para lidar, como você falou, com ambiguidade, com complexidade.
Entrei aqui, sou membro do time técnico. Tá, mas o que que você faz? Como é que você é promovido? Quanto você vai ganhar? Como é que você pede aumento? Não sei, eu vou ter que achar um problema. Fica aquela coisa assim, meu Deus, parece que vão me jogar aos leões. Isso tira um pouco, né, ou vamos dizer assim, isso sobe a régua de exigência de maturidade do profissional, mesmo para o júnior. Ou não, o júnior a gente deixa entrar, ele vai ficar meio maluco no começo e a gente trabalha essa maturidade aqui dentro.
Eu colocaria os— excelente pergunta. Eu tô pensando aqui em alguns modelos, mas a pergunta é super excelente, porque quando você traz— eu lembro de uma conversa que eu tive com um profissional que trabalha no McDonald's, e esse profissional falou o seguinte para mim: a minha, o meu incentivo, parte de RH, parte de pessoas, é fazer com que a gente tenha a melhor experiência de primeiro emprego do mundo. Se você precisar de RH, então a minha, o meu trabalho, a empresa ela gira para que você possa ter a melhor experiência de primeiro emprego.
Então, para que você saiba, declaradamente é primeiro emprego, é o primeiro legal. Então, porque você vai trazer horário para essa pessoa, você vai trazer a responsabilidade que ela precisa ter uma entrega clara vai trazer processos, porque a gente tem um processo para fazer cada um dos sanduíches, cada uma das limpezas, cada uma das XYZ. E eu acho que aqui nos Estados Unidos tem uma competência de que você pode ter múltiplos cargos.
Eu sei que no Brasil, dentro da CLT, não é permitido isso, mas que você, durante aquele período que você tá trabalhando para empresa, você pode desde lavar o banheiro até você fazer um hambúrguer, até você atender a pessoa dentro do caixa. Então te expõe também a uma série de questões de você lidar com as pessoas, de você lidar com a produção que você precisa, de você lidar com uma série de coisas que permeiam construir, permeiam tocar uma operação como essa.
Então o que que eu vejo? Para um profissional júnior, ele precisa de guia, precisa ter menos ambiguidade, porque senão a pessoa se perde também. Porque para onde que eu vou? O que que eu faço? E um cargo desse de Member of Technical Staff acho que não seria adequado para um profissional júnior.
Ah, tá.
Mas ao mesmo tempo, não é um cargo assim que já entra com esse perfil. Member of Technical Staff não necessariamente. Para Product Engineer, o meu guia de que existe, porque você entrega uma função para essa pessoa clara do começo ao fim, da ideia ao impacto, e você pede para pessoa resolver este tipo de problema. Ou seja, você reduz a ambiguidade. É um caso muito claro. E aí precisa de coaching, você vai precisar acompanhar essa pessoa, você vai precisar instruir essa pessoa.
Mas ao mesmo tempo, quando você mostra a barra, você fala assim: eu quero que você aumente o teu nível de complexidade, e como consequência eu vou te dar menos respostas e vou te trazer mais perguntas. Eu espero que você faça mais perguntas de maior qualidade é onde a pessoa começa a entender para onde que ela deveria ir. E assim, hoje em dia, por conta, talvez por conta de Instagram, por conta de YouTube, por conta dos jovens estarem cada vez mais expostos a empreendedorismo, eles querem construir, eles querem fazer.
Eu tava fazendo um treinamento com uma companhia de Goiânia, eles trouxeram 20 pessoas para fazer um treinamento de Product Engineering junto comigo, e um dos membros mais juniores da companhia Ele falou, Felipe, mas quando que é a hora de eu sair para empreender? Eu falei, você sabe que todos os seus líderes estão aqui, né? Eu pensei, eu não falei isso na hora, mas eu falei uma resposta que eu acredito assim, o melhor momento de você empreender é com dinheiro dos outros, é você estar em uma outra companhia, de você estar em um outro lugar, tem vários benefícios.
A empresa já tem nome, a empresa já tem cliente, você consegue expandir um determinado cliente com o produto que você fez. Então, a gente tá falando de PM3, eu trabalhei durante 3 anos dentro da FIAP. E na FIAP, assim, dentro do grupo, né, falando de PM3, falando do grupo, e lá dentro o quanto a gente conseguiu experimentar, construir, entender, fazer uma série de experimentos. E foi um momento espetacular para mim, porque eu pude promover e pude colocar vários projetos ali na frente.
E a minha reflexão para esse profissional E para profissionais juniores, assim, entregue o seu trabalho, entregue o que foi pedido para você. Vamos colocar nesse caso aqui de uma função, de um resultado aqui que eu espero de você muito claro, mas comece a sugerir novos projetos, comece a sugerir novas formas de fazer. E assim, é muito raro com que isso aconteça. As pessoas normalmente não promovem, não sugerem isso. E quando você chega, você começa a sugerir novos projetos, você consegue sugerir.
Ah, eu fiz uma sugestão de novo projeto. Ah, mas ninguém adotou. Tá bom, como engenheiro de produto, o que que você deveria fazer? Entender por que que o comportamento não tava lá. Era oferta que tava errada? Era navegação que tava errada? A pessoa não queria navegação nenhuma, só coloca aqui dentro do meu código para eu poder utilizar. Assim, tenta entender o comportamento do usuário, por que que você não conseguiu trazer ele.
E aí volta toda a disciplina, que a PM3 fala muito bem sobre isso, uma disciplina de research, uma disciplina de entendimento do cliente, enfim, de você buscar toda essa informação. Então a minha reflexão aqui é, mesmo que eu tenho falado bastante isso, mesmo que você não seja um Product Engineer efetivo dentro da tua companhia, minha sugestão é atue como um e sugira para tua liderança para você poder fazer exatamente isso. A partir de agora eu queria começar a ser dono do fim a fim, vou pegar Vou continuar fazendo o que eu tô fazendo, mas eu vou pegar um desafio aqui, eu vou sugerir uma nova forma, vou sugerir um novo projeto, vou sugerir um novo produto.
E assim, aconteceu isso dentro de uma companhia de mais de 1 milhão e meio de funcionários, que é onde eu estou hoje, dentro da AWS. Eu sugeri isso para uma nova liderança e eles falaram: ótimo, vamos fazer esse projeto novo. Então eu acho que você consegue construir projetos e construir formas novas dentro de dentro de companhias. E foi essa resposta que eu dei a esse profissional. Eu falei assim: constrói onde você tá, acho que você vai aprender muito e você não precisa se expor tanto, e você consegue contar com todas as pessoas que estão aqui à volta para poder te dar o feedback, cara.
E eu lembro muito do— tem um termo que eu gosto bastante, que eu aprendi até num curso de Harvard, que é o Entrepreneurial Gap, né? Quando eles falam de job description, que é o gap empreendedor que existe sempre entre a quantidade de recursos que que você tem na mão e o tamanho da responsabilidade que você tem. E eles chamam esse gap, né, entre um e outro, de Entrepreneurial Gap, que é o quê? Quando você tá empreendendo, você vai ter muito menos recurso do que a responsabilidade que você tem.
Porque primeiro, imagina que você é um empreendedor solo, né? Você bota um negócio no ar, você não pode forçar o cliente a usar o seu produto. Então só por aí você já não tem recurso. Você não tem recurso de obrigar o cliente a usar. Você geralmente não tem dinheiro, né, quando você começa uma empresa do zero, a menos que você ou seja herdeiro ou já comece ali com um cheque grande de algum VC. Geralmente você não tem muito dinheiro, você não tem muito recurso, você não tem quase nada na sua mão, e você tem uma responsabilidade enorme de fazer um negócio crescer.
E o trabalho de PM especificamente, de gerente de produto, mas tenho certeza que o de Product Engineer também, é um trabalho que tem um entrepreneurial gap muito grande, né? Você foi trazendo aqui os casos, eu fui pensando em objeções. Minha cabeça de marketing é objeção, né? Qual que é a objeção do cliente quando eu apresentar isso aqui? Ah, mas na minha empresa eu tenho limitações, na minha empresa eu só posso usar o Copilot, na minha empresa eu não sei o que lá, por conta de governança não tem uma conta de IA.
Esses dias falei com, tem um mês mais ou menos, falei com um amigo meu de infância que ele é gerente financeiro e ele falou, pô, na minha empresa não me deram nenhuma licença, eu quero fazer dashboards, eu quero construir coisa e eu não tenho licença e eu tô tendo que ir lá pleitear uma licença, pelo amor de Deus, de IA. Eu falei, por que que você não faz na sua conta pessoal, né? Ele, ah não, que eu não posso fazer com os dados de cliente.
Mas faz com dado bocado. Mostra o dashboard com dado fake, mostra, falou, é isso aqui que eu quero construir. Ele falou, ah, mas na minha conta pessoal. Falei, pô, você não tem cento e pouco, você é gerente financeiro, vai, você tem R$100 para pagar um ChatGPT, para pagar um cloud. E esse é o gap empreendedor, você tem pouco recurso, a empresa não te deu uma licença, a empresa não quer saber de você, falou, não, se vira. Você tem que achar alguma coisa, né, um jeito de entregar aquela responsabilidade com esse recurso pequeno.
E eu fui pensando nessas objeções, falei, cara, legal isso do Felipe, mas já consigo imaginar algumas pessoas falando, ah, mas na minha empresa é diferente, diferente, na minha empresa é diferente. Nossa, era uma empresa de 1 milhão e 500 mil pessoas. Ah, mas é a AWS, é a Amazon, cara. Mesmo assim, eu imagino que você tenha um monte de limitações aí também, né?
Você, as dificuldades são enormes também. E como uma companhia muito grande, para você fazer determinados movimentos, eu posso te colocar todos os desafios que eu tenho aqui, posso ficar rasgando até o final do podcast todos os problemas que eu tenho. Mas ao mesmo tempo, a gente pode olhar para um outro lado, e aí um lado de abundância, sobre quais que são as ferramentas que eu tenho acesso e eu posso utilizar hoje. E se não, como que eu consigo desenvolver as minhas habilidades para que eu possa chegar mais próximo disso?
Você tava comentando de fazer conta pessoal. Por mais que você não entregue maior impacto utilizando IA dentro da tua empresa, como é que você consegue desenvolver esse tipo de habilidade construindo projetos pessoais? E aí eu vou dar um caso específico. Aqui dentro de casa a gente fez uma avaliação de 5 distritos ou 5 grandes lugares que a gente gosta bastante sobre educação. Então existe um padrão de ensino, isso falando para os meus filhos, né?
Existe um padrão de ensino texano, um padrão de ensino americano, um padrão de ensino brasileiro, singapureano e japonês. A gente pegou os standards de cada um desses países, de cada um desses lugares, e a gente fez uma referência, uma cross-reference, assim, a gente começou a entender o quanto desses, desses casos aqui, ou dessas habilidades, elas fazem um match com esses outros, e quais são os que sobram, quando não tem nenhum match, para a gente poder entender se a gente estava expondo os nossos filhos às habilidades certas, o que eles precisam agora, que é matemática, língua, língua secundária, lógica e álgebra.
E foi super bacana, porque a partir desse processo a gente entendeu, a partir de uma pergunta, E se a gente pudesse expor os nossos filhos à melhor educação do mundo? Ele falou, qual que é a melhor educação do mundo? Não sei, existe uma melhor educação para eles, mas ao mesmo tempo existe alguns padrões que foram construídos por diferentes lugares. A gente gosta bastante também de alguns lugares asiáticos, como Singapura e Japão, mas ao mesmo tempo tem benefícios, etc.
A parte de metodologia de matemática exata, a gente começou a olhar alguns para E aí a gente começa a refletir sobre assim, como que você consegue desenvolver? Nesse nosso caso foi uma aplicação para poder acompanhar os marcos evolutivos das crianças. Então assim, esse marco existe, esse marco foi observável, a gente observou a partir de um prompt, ou esse marco foi observado através de— desculpa o inglês aqui— de free play, de one-on-one, etc.
Então assim, eu consegui ver a criança contando até 20 sozinha, porque tava brincando de esconde-esconde. Então, opa, tem um marco de desenvolvimento aqui. De 0 a 20 é um marco de desenvolvimento que existe em 3 países, em 3 jurisdições. Como que a gente sabe disso? Porque a gente pediu para fazer a comparação. Então, por mais que você não consiga fazer no seu dia a dia, a gente fez um app. Então é um app, você abre ele tanto no browser quanto no celular, você observa algum comportamento, você pode digitar ele vai tentar fazer um match de uma coisa que você olhou e você falou, nossa, que legal.
E aí qualquer pessoa pode fazer isso. Eu posso fazer, minha esposa pode fazer, meus pais podem fazer, a pessoa que acompanha a TV junto com eles pode fazer.
Não, é um mundo completamente diferente.
Existe uma complementariedade bizarra assim, porque é um mundo de artes plásticas, é um mundo de ciências sociais, é um outro tipo de mundo que eu não habito. E aí eu tô de carona num mundo como esse.
É o mesmo caso aqui. Engraçado que você foi falando, a gente já conversou algumas vezes, viu, gente? Eu e o Felipe, a gente não tá saindo do personagem aqui não, mas a gente já viu várias semelhanças assim. A minha esposa também trabalhou com saúde mental, educação infantil, e são as mesmas dores aqui de— acho que os nossos filhos regulam de idade também, são as mesmas dores. E exatamente isso que eu tenho visto aqui também. Você coloca para resolver um problema pessoal, cara, isso abre possibilidades, né?
Eu vejo ela aqui, eu vejo esse meu amigo financeiro, depois ele conseguiu a licença Maravilhado, maravilhado. Cara, isso aqui muda minha vida e abre possibilidades de carreira, né? Então eu queria falar um pouquinho de carreira contigo. Primeiro, a carreira de dev, eu brinco que sempre foi a medicina da nossa época, né? Porque muitas famílias, é um fator de ascensão social gigantesco, né? Geralmente medicina é uma carreira que paga super bem, mas quem que conseguia fazer medicina?
O filho do médico, né? E engenharia, dev, código, já não. Eu conheci muitas pessoas que falavam assim, cara, eu sustento meus pais porque eles me deram um computador quando eu era criança, eu aprendi a programar e hoje eu sustento eles, né? Conheci muita gente, muito dev nesse sentido. Então a barreira de entrada para dev, né, sempre foi muito menor do que medicina, direito, algumas carreiras daquelas que tradicionalmente não é regulado, tem uma série de outras coisas também.
Exatamente. Você acha que agora diminuiu mais ainda a barreira com a IA, com assim Por exemplo, uma pessoa pode se tornar Product Engineer estudando, faz um curso, faz alguma coisa, né, começa a testar, programar e tal, e dá.
Eu vou trazer um caso de um aluno meu, e ele sempre esteve em tecnologia, nunca desenvolveu uma linha de código, nunca abriu um terminal assim, ficava horrorizado e assim super com medo de terminal, de linha de código, etc. Mas por muitos anos Ele cresceu dentro do mundo de cibersegurança, ele começou com suporte técnico, suporte a usuários, e aí ele desenvolveu inglês. Então começou a desenvolver uma habilidade para poder fazer suporte técnico em inglês dentro de uma empresa multinacional, foi para o interior de São Paulo para trabalhar numa multinacional inclusive.
E aí recentemente ele começou a ver, ele falou assim, nossa, mas tem uma ideia de fazer. Ele faz triatlon. Ele falou assim, todas as vezes que eu termino um ciclo dentro do Strava, eu preciso olhar lá. Ah, é super bacana, compartilha, todo mundo gosta, é muito social isso, mas eu queria saber como eu posso melhorar. Se eu tivesse um coach que avaliaria o meu trajeto de bike, etc., que eu fiz, e falasse assim, ó, nesse momento aqui você podia ter puxado mais, ou você treinou muito nos últimos 5 dias, acho que agora se você for andar de bike de novo Reduz.
Eu falei, nossa, adoraria receber isso por WhatsApp. Falei, você já tem o produto, é só construir agora. O que você acabou de falar para mim, fala para o teu prompt e constrói. E aí, com uma característica de builder, um profissional de tecnologia, de cibersegurança, que nunca desenvolveu, começou a fazer um building. E aí ele entrou para o nosso curso de Product Engineer, na formação de Product Engineer, e aí a gente começou a guiar ele em relação às coisas que ele precisava prestar atenção.
Em conteúdos que ele não tinha antes. Então, sobre arquitetura de sistemas, sobre como é que você faz um desenho de fluxo de usuários, como é que você faz um desenho, um system design, para você poder entender: eu preciso de autenticação, eu preciso de uma base de dados aqui, quais são as tabelas que eu preciso construir. Uma parte da própria segurança do código, com segurança da pipeline, se eu tô entregando isso de uma maneira correta ou não.
Enfim, uma visão completa até sobre como eu crio oferta. Como que eu crio oferta, quem é o meu ICP, quem é o meu cliente ideal. Mesmo que eu não tenha o entendimento de que mesmo que este cliente não é ideal, eu ainda posso prestar serviço para ele, mas eu estou buscando um cliente ideal. E aí este tipo de mentalidade assim entrou assim, ele sacou, e ele me mandou uma mensagem uma semana atrás, ele falou: Felipe, quando é que eu tô pronto para falar que eu sou Product Engineer no LinkedIn?
E assim, uma pessoa que tinha medo de trabalhar com esse tipo de coisa, ele falou, a minha vida mudou nos últimos 6 meses. Eu entendi que, um, eu posso fazer esse tipo de coisa, mas outra, eu entendi que eu posso aprender sobre esse tipo de habilidade também. E honestamente, assim, para mim, eu falei, é libertador, porque você consegue colocar as coisas que você tem interesse, que você tem paixão, lá para frente. E a gente fez um one-on-one essa semana e ele falou, porque assim, Você tá me incentivando demais nessa aplicação, você tá me incentivando demais nesse app.
O que que você vê que eu não vejo? Aí eu comecei a fazer algumas contas. Se você tivesse tantas pessoas pagando tanto por mês, você fizesse um plano anual, essas pessoas entrassem, tal, tal, tal, tal, tal, gastei um carro por ano. Você consegue trocar de carro todo ano, não só vendendo teu carro, mas consegue comprar um novo carro todo ano em uma brincadeira, cara, um aplicativo assim, assim, assim.
Ele mora aqui ou aí?
Ele mora no Brasil, ele mora no Brasil.
Então o carro é mais caro ainda, então é uma receita boa, né?
Porque a gente entendeu quem que é o perfil dele. O ICP é o cara que já faz, o cara, mulher que já faz assinatura do Strava. Eu falei, ótimo, então você já tem que buscar quem são os assinantes de Strava no Brasil, onde essas pessoas estão, como é que você busca, qual que é a oferta, o que que as pessoas querem. Enfim, é só um caminhozinho para você montar uma empresa. Porque no fim do dia, ser um Product Engineer é você montar uma empresa, um produto, uma nova unidade de negócio, uma prestação de serviço em uma empresa existente ou com uma nova marca.
No final do dia, eu reduzo isso a você construir um novo produto ou continuar crescendo, né, um produto existente. Então a reflexão que eu deixo aqui é: a barreira diminuiu porque você pode construir isso no final de semana. Porque você pode construir isso das 6 às 9 da tarde, da noite, que você consegue construir isso também das 6 da manhã às 9 da manhã. Então o incentivo acaba sendo muito mais sobre algo que eu me importo muito.
E muitas vezes, porque você se importa muito, você acaba se dedicando tanto que quando você vai trazer isso para o teu trabalho, para o teu trabalho das 9 às 6, as habilidades estão ali. Então você tá no fundo, no fundo, se desenvolvendo. Existe um estudo que fala que metade dos tokens dentro das empresas são gastos para itens pessoais. Honestamente, eu acho que é espetacular, porque da mesma forma como eu abro o meu Gmail no meu computador do trabalho, eu abro o meu, o meu cloud da vida, eu preciso, eu quero, etc., eu começo a utilizar.
Mas eu estou desenvolvendo habilidades, eu estou me acostumando mais com esse modo de trabalhar, que uma hora que eu for trabalhar em um problema, um desafio corporativo, putz, minha habilidade já tá lá. Então é espetacular ver como este tipo de habilidade vem sendo desenvolvido nas pessoas.
Cara, eu sou um grande incentivador de projetos paralelos assim, né? A PM3 surgiu como um projeto paralelo dos founders que tinham seu trabalho CLT e tocavam isso fora do horário. O Product Camp era um projeto paralelo, né? Eu tinha meu trabalho CLT, o Marcel também, a gente tocava fora do horário. Claro, de vez em quando tinha uma reunião com patrocinador em horário comercial, Mas assim, o que que é uma horinha de reunião numa semana que você tá falando com patrocinador?
Para o teu CLT assim, fala, pô, perdi esse cara por uma hora com uma reunião. Cara, assim, ele tá entregando, tá fazendo, tá aprendendo um monte de coisa. Eu aprendi tanto no Product Camp que na época eu trabalhava na Envolves, depois na Sherpa, que essas duas empresas, eu tenho certeza, elas se beneficiaram das coisas que eu aprendi ali, sabe? Tinha, era bom assim também eu estar ali. Então eu sou um grande incentivador de projeto paralelo.
Acho que as pessoas, muita liderança, principalmente executiva assim, o pessoal tem mais tem medo, né, assim, fala, mas aí a pessoa não vai fazer nada aqui. Se ela não fizer nada aí, você pode desligar ela, né? Você não é obrigado a ficar com ela para o resto da vida.
Aí tá errado porque a pessoa não tá fazendo nada ali, é outra questão.
Exato, o erro não é o projeto paralelo, o erro é a pessoa não tá entregando o que ela se comprometeu. Então aqui também, assim, a gente tenta liberar ao máximo os tokens e tudo mais. É claro que a gente, PM3, né, não é uma empresa gigantesca com dinheiro infinito. Então assim, também não é, os tokens não são open bar, mas a gente tenta ser bem generoso assim também com essas questões para que as pessoas aprendam. A gente aqui tem um valor nosso, né, que é o espeto de ferro, que eu gosto de explicar com: a gente ensina o que a gente faz aqui dentro e a gente faz aqui dentro o que a gente ensina, sabe?
Então não tem por que eu falar para as pessoas assim: não, se arrisca aí, se arrisca, constrói um negócio, faz um projeto paralelo. Aí aqui dentro assim: não, ninguém pode ter projeto paralelo. Cara, o meu discurso tem que ser um só, né? E eu vejo isso assim, eu concordo contigo, a barreira diminuiu muito, né? A barreira diminuiu muito. E eu tenho visto pessoas que eu nunca imaginei que eu ia falar de tecnologia com essas pessoas, né?
Eu tenho um, curiosamente assim, eu tenho um hoodie, né, um casaco do GitHub, né? E às vezes eu uso ele assim para ir para academia e tal, não sei o que lá. E uma pessoa já reconheceu, falou, cara, o GitHub, você trabalha com tecnologia? Eu falei sim. E a pessoa não trabalhava. Com tech.
Olha só, ela reconheceu já.
É, ela falou, ah, eu vi, eu ouvi falar, parece que é um negócio de código, né, e tal. Só que eu falei, é, exatamente. E a pessoa não trabalhava com tech. Então assim, até marcas, né, coisas que a gente vê assim, pô, o Ruri do GitHub, se a pessoa reconhecer na rua, é nerd, né? Não necessariamente agora. Então eu tenho visto essa diminuição dessa barreira e tenho visto a importância da educação, né, da educação formal assim também.
Claro, não é você abrir o tool, abrir o cloud lá, falou, pede qualquer coisa vai sair, como você falou, vai sair um negócio que pode não ter segurança, que pode não ter, que vai ser alvo de ataque, que pode expor dados às vezes sensíveis que você não quer expor e tudo mais. Como eu queria falar um pouco da tua formação de Product Engineer, né, a gente tá junto inclusive na próxima turma, pessoal. Para quem tá assistindo a gente, existe uma formação do site product.engineer.
O Felipe vai falar um pouco mais a respeito, que essa é minha pergunta para ele. E tem lá um benefício para quem é aluno da PM3, para quem tá na comunidade da PM3. Daqui a pouco eu falo, mas primeiro eu queria ouvir do Felipe. Felipe, como é que é essa formação? Como é que você desenhou isso para que ela seja realmente efetiva?
Eu comecei de trás para frente. Como que uma pessoa consegue se tornar Product Engineer? E essa é uma vaga que tá muito disponível nos Estados Unidos. A gente consegue ver uma série de vagas com o título Product Engineer. Dentro dos laboratórios de IA e fora também. Existe uma empresa muito famosa chamada PostHog, muito queridinha aí por gerentes de produto no geral, e eles há muitos anos eles têm Product Engineers dentro da companhia.
E eu fui procurar, tá bom, como é que uma pessoa se torna Product Engineer? E não existe formação, não existe uma forma, não existia, não é uma faculdade, não tem uma uma carreira clara. E eu comecei a fazer entrevistas com múltiplos Product Engineers para entender como que eles caíram nesta vaga, nesta área, etc. Eu comecei a encontrar também, inclusive, outras vagas com outros nomes que exigiam habilidades essencialmente de Product Engineers.
Quando a gente vai para uma Big Tech, é muito difícil você abrir uma vaga com um título diferente, porque como é que eu vou encaixar isso dentro do meu mapa, dentro da ontologia que eu tenho aqui? E aí as pessoas acabam abrindo, gestores acabam abrindo vagas para profissionais que, dos títulos que eles já têm, para frente. E aí eu comecei a trabalhar de trás para frente. Como uma pessoa que trabalha dentro da AWS, da Amazon, a gente é quase que doutrinado a trabalhar de trás para frente, entender qual que é o problema e para onde eu quero chegar.
Então tá bom, deixa eu mapear quais são as habilidades que uma pessoa que vai aplicar e vai trabalhar como Product Engineer deveria ter. E eu trabalhei de trás para frente para montar essa formação. Então a nossa intenção é uma formação de 6 semanas, 2 encontros por semana. Então são 12 encontros que a gente tem de 1 hora e meia cada um, onde a gente tem uma masterclass e o que eu chamo de working session. Porque não adianta só falar, não adianta a gente só apresentar e expor as pessoas a determinadas habilidades.
A gente precisa aplicar, a gente precisa abrir a máquina. Vem cá ver como eu construo, vem cá ver como determinada pessoa que constrói. Então a gente trouxe profissionais desde negócios que têm conhecimento de produto muito forte, profissionais extremamente técnicos, porque a ideia é a gente levantar a barra. Assim, eu normalmente eu falo que eu não ensino para média, eu ensino para justamente te expor a uma determinada, acho que você ficar desconfortável para você poder ter terminologia e buscar mais.
Obviamente a gente tem os nossos mentores, não só os instrutores, os mentores também que dão suporte. E eles têm, cada um deles, eles têm uma sessão que eles entregam junto com a turma. Mas a ideia é você sair melhor do que você chegou, você construir produtos e você conseguir lançar. Então, como você define, como você constrói e como você lança. O curso, ele tem esse design, ele tem esse desenho, ele te expõe a mecanismos de definição, mecanismos de construção e mecanismos de lançamento.
Fala sobre oferta, fala sobre colocar como que você observa clientes, como você fecha o ciclo de feedback, mas também fala sobre tecnologia, fala sobre arquitetura, fala sobre como você constrói algo sólido, e também fala sobre priorização, para onde o mundo tá indo, como que os SaaS estão sendo construídos hoje no mundo, como que eles estão entendendo, como é, qual que é o diferencial. Não é só colocar IA, como que empresas do Vale do Silício eles estão mudando a forma como os produtos são construídos no geral.
Então é uma exposição gigantesca, a gente tem um conteúdo massivo durante esse processo e a gente incentiva com que os nossos alunos eles construam algo novo. Ao final, a ideia é a gente ter algum produto que você vai construir dentro da tua empresa, vai construir um produto novo fora e começar uma jornada para você ter um produto que vai valer R$10 milhões. Então é como é que você tem esse processo de construção, esse processo de proposição para que você chegue ali no final e fala assim: agora estou pronto para uma esteira para eu construir um produto de R$10 milhões.
Esse é o grande incentivo, assim, como que a gente consegue tirar você onde você não conhecia habilidades de Product Engineer, mas eu tenho um projeto, eu quero construir alguma coisa, para eu estar pronto, capacitado, eu tenho as habilidades certas, eu tenho meus prompts certos, eu tenho meu harness certo para poder chegar lá.
Maravilha. Não quer dizer que a pessoa vai terminar o curso como empreendedora especificamente. Ela pode se empreender, obviamente, mas ela também pode fazer isso dentro da empresa, como você falou, né? Dentro de uma empresa, com o dinheiro, com o capital dele, dentro da empresa.
Muitos fazem isso. O que a gente vê bastante gente dentro de companhias, inclusive, é incentivando. Eu tenho duas empresas que fizeram junto com a gente. Uma trouxe quase 20 pessoas e outra trouxe 11 pessoas, porque eles falaram: nós precisamos mudar como a nossa equipe trabalha. Então, a minha equipe de gestão, eu quero que eles sejam Product Engineer Leaders a partir de agora. Eu preciso que eles adquiram essas habilidades para que eles possam ter terminologia para os contribuidores individuais da companhia.
Então, concordo, não necessariamente é uma nova empresa que você vai formar. A nossa sugestão é: se você já é responsável por um produto, ou se você gostaria de começar a ser responsável por um produto, ele pode ser construído do lado de fora, do lado de dentro. E da mesma forma, o speech, ele tem que seguir o que a gente faz. Eu trabalho dentro da AWS, então eu sou responsável por um produto dentro da companhia, eu vou continuar dentro da companhia, e a minha intenção é como que aumenta o escopo, complexidade, ambiguidade e o impacto dentro desse produto que eu sou responsável, e como que eu crio um mecanismo de crescimento para que ele cada vez impacte mais pessoas, para que cada vez tenha uma complexidade maior, ele seja mais completo.
Então não necessariamente é para você poder virar empreendedor, você pode construir inclusive dentro da tua empresa ainda.
Muito legal, cara. Quando você traz esses episódios de empresas pagando assim, a gente tem também, a gente faz muito curso dentro de empresa, tem uma expressão que eu gosto muito aí dos Estados Unidos que é, eu vou falar traduzido livremente, que é o colocar o seu dinheiro onde as suas palavras estão, né, onde tá a sua boca, né. E para mim esse é um dos principais fatores para você observar a cultura de uma empresa. Onde que ela gasta dinheiro.
E muitas vezes eu trago isso para mim também, né, para eu observar o meu comportamento, minha conduta, os meus valores. Assim, cara, onde que eu tô botando o meu dinheiro, né? Onde eu tô gastando? Geralmente você tá gastando naquilo que— porque gastar é doloroso, né? Você não quer gastar. Então você tá gastando naquilo que você mais valoriza, mesmo que você não diga que valoriza aquilo. Se você tá gastando ali, você valoriza, você tá gastando ali.
E um truque, né, vou dar um truque aqui para as pessoas gastarem menos, né, inclusive gastarem menos, inclusive com educação. Existe um cupom PM3, né, para o curso de Product Engineer, que a gente sabe que tem um desconto que eu não vou falar quanto é. Então você vai lá, vou pedir o pessoal colocar o site aqui, product.engineer. É esse site mesmo, product.engineer. Pode ser com www, sem www. Se você digitar product.engineer do jeito que tá escrito aqui, você vai ver o curso ali.
A PM3 é super parceira desse curso do Felipe. E você, na hora de você comprar, você coloca o cupom PM3 e vai ter um desconto surpresa. Que não diremos quanto é, né, Felipe?
Não, esse aí tem, e pode ter até alguns perks se você vier da PM3. Conforme for, você tem alguns, algumas coisas a mais. Eu tô super feliz de estar junto com a PM3 nesse processo. Acompanha a história da PM3 não só quando estive no Brasil, mas continua acompanhando o que vocês têm feito. Respeito bastante o mercado que vocês desenvolveram. Era um mercado que não existia, um mercado de um produto de ensino de produto, tinha bastante de gestão de projetos.
A gente via uma outra área e a visão de produto que vocês trouxeram, por conta da maturidade que o Brasil também teve de construção de produtos, as empresas referências que estão construindo isso, acho que super bacana. A gente não podia fazer se não tivesse próximo de vocês.
Perfeito, Felipe, super obrigado aí pelas palavras. Eu vou, eu vou deixar aqui um espaço para você dar um recado final. A gente tá chegando no final, vou até fazer um compromisso o público aqui de que a gente precisa gravar mais episódio, que ficou um monte de assunto para falar ainda, né?
Mas enfim, quando a conversa é boa, a gente quer falar mais, não tem como, cara.
É verdade, a gente precisa fazer uma parte 2 ou em algum outro lugar a gente conversar mais. Quando estiver no Brasil, a gente vai tomar um café também. Mas enfim, queria deixar esse finalzinho para você dar suas palavras finais aí, dá um último recado, algo que você acha que faltou falar nesse primeiro episódio junto.
Eu, uma das coisas que eu gosto todas as vezes que a gente vai fazer alguma coisa nova Eu gosto de alinhar conceito, eu gosto de alinhar também quais são os incentivos. E aí eu queria deixar aberto aqui sobre qual que é o meu incentivo da gente fazer isso. Eu realmente acredito que a gente pode ser dono do fim a fim, que a gente pode aumentar o nosso, a gente pode, eu fui empreendedor no Brasil, a gente acabou não conseguindo falar sobre isso.
Eu comecei como engenheiro mais novo da Microsoft aos 19 anos, fui empreendedor duas vezes no Brasil. E vendi uma das minhas empresas para o Banco Modal, uma empresa de capital aberto. Fui sócio de uma empresa de capital aberto por um ano e meio até que a gente fez a venda para XP. Eu vim para os Estados Unidos e o meu incentivo é fazer com que mais pessoas tenham essas mesmas habilidades, fazer com que mais pessoas consigam desenvolver isso.
Então o Product Engineer para mim é uma habilidade clara para você poder ser dono do fim a fim, para você da ideia à execução, de você colocar suas ideias em prática. Para você poder fazer o pitch para as pessoas, para você poder construir a oferta certa, para você construir uma ferramenta que de fato vá fazer com que você tenha suas habilidades aplicadas. E um outro incentivo meu é fazer com que mais empresas no Brasil abram vagas de Product Engineer, para que mais empresas incentivem com que seus profissionais de fato possam crescer e mais projetos possam ser construídos.
Eu acho que no ano que a gente tá, no momento que a gente tá, é o momento exato para você poder construir cada vez mais. A gente pode ser muito mais produtivo com IA hoje A gente sabe as habilidades que elas trazem e o nosso push aqui é qual que é o projeto que você deveria construir, qual que é o caminho que você deveria construir, como você observa os usuários para você poder construir as coisas certas. Então, o meu maior incentivo é para que mais pessoas virem Product Engineers e para que mais empresas abram vagas de Product Engineer.
Por isso que eu tô aqui. Então, convido vocês a acessarem www.product.engineer. É um domínio super curioso porque o TLD dele é o .engineer, então não é .com. Mas lá a gente tem recursos para, se você quiser operar hoje como Product Engineer, a gente tem recursos abertos, como mecanismo de fazer discovery, como fazer os 5 porquês. A gente tem uma série de ferramentas lá que você pode operar e vou colocar aqui, copiar aquele projeto e trabalhar onde você tá trabalhando hoje.
Se você quiser começar a operar como Product Engineer, entra lá, a gente tem uma série de ferramentas para você poder fazer isso. E te convido para fazer parte da próxima formação que eu tô junto com a PM3. Para a gente poder fazer Product Engineer e o código de desconto PM3.
Perfeito, Felipe, super obrigado. E pessoal, para você que acompanhou a gente, que gostou desse episódio, não esquece de deixar o seu like se você tiver no YouTube, a sua 5 estrelinhas se você tiver no Spotify. Isso ajuda esse conteúdo a chegar para mais gente, a gente cumprir com o propósito do Felipe de mais pessoas saberem do Product Engineering. Eu também tenho esse propósito. Quando a gente trabalha com educação é mais gostoso porque a gente trabalha junto com o nosso propósito de vida.
E então deixa o seu like, deixa suas 5 estrelinhas, assina o nosso canal. Isso vai dando para a gente feedback também do tipo de conteúdo que você gosta de ver aqui, de que você gostaria que a gente trouxesse mais aqui para o Mesa de Produto. Muito obrigado, um grande abraço e até a próxima.
Até a próxima!
PM3
Formação Product Engineer