RH como produto: o que eu trouxe do NATIVE'26

Na segunda passada, 28/09, eu passei a noite no NATIVE’26, o evento da Comp sobre RH e IA em São Paulo. Foram cinco horas com um painel de líderes de People do Nubank, da Uber e da Stone, uma palestra do Pedro Bobrow (cofundador da Comp) sobre o RH do futuro e o Marty Cagan fechando a noite com “HR as a Product”.

O evento era de RH, mas eu saí com a sensação de que quase tudo que foi dito serve pra qualquer área que está tentando implantar IA. Por isso resolvi organizar aqui os insights que eu anotei, bloco a bloco, com o que cada pessoa defendeu.

Em uma lista, pra quem tem pouco tempo

• A ideia que amarrou a noite foi RH como produto: partir de um problema com métrica, em vez de começar pelo pedido ou pela ferramenta. O Nubank opera assim há três anos, e hoje 20% do time de RH deles é de produto, design e engenharia.
• A IA entra por último. Na tese do Pedro, um RH AI native se constrói em três camadas, e quase todo mundo começa pela de cima.
• O RH precisa largar o papel de tomador de pedido. Quando a área pede “um pleno de engenharia”, a primeira pergunta deveria ser por quê.
• Para o Cagan, o modelo de projeto entrega feature e o modelo de produto entrega resultado. O time recebe um problema e a métrica de sucesso, e precisa de acesso aos usuários, aos dados e a quem decide.
• Ninguém sabe medir direito o ROI da IA. A resposta mais honesta da noite foi da Suzana, do Nubank: “não sei”.

Como foi a noite

O formato foi de três blocos de conteúdo com intervalo pra jantar no meio, e as perguntas da plateia chegavam por um QR code na tela. O painel foi mediado pela Gabriela, do time fundador da Comp, que abriu pedindo menos tese e mais caso real. Funcionou: os três painelistas contaram inclusive o que deu errado.

• Painel de cases: Suzana Kubric (Chief People Officer do Nubank), Rafael Arroyo (Director of People LATAM da Uber, depois de nove anos na Amazon) e Fabio Kapitanovas (Chief People and Operations Officer da Stone).
• “O RH do futuro”: Pedro Bobrow, cofundador da Comp.
• “HR as a Product”: Marty Cagan, autor de Inspired, Empowered e Transformed, com o Pedro mediando o Q&A.

Os insights que eu trouxe

1. Tudo começa no problema

Foi o ponto em que os três blocos concordaram sem combinar. A Suzana falou em “se apaixonar pelo problema, e não pela solução”, o Pedro falou em parar de tirar pedido, e o Cagan pediu pra gente dar ao time problemas pra resolver e medidas de sucesso, em vez de uma lista priorizada de features. A régua que ele deixou me parece servir pra qualquer projeto de IA: se você ainda não consegue dizer qual problema aquilo resolve e como vai medir se deu certo, você não está pronto pra gastar dinheiro com isso.

2. As três camadas: dado embaixo, interface em cima

A parte que mais me marcou foi o modelo que o Pedro mostrou de como se constrói um produto AI native, e que a Comp aplica ao RH:

1. Fundação: dados estruturados. O Pedro lembrou que isso já se falava há dez, vinte anos e mesmo assim não acontece, e a plateia riu porque todo mundo sabia que ainda vive em planilha. Sem esse dado não dá nem pra perceber que os últimos três plenos contratados pra mesma vaga saíram em dois meses.
2. As jornadas: a lógica de produto, as regras de negócio e a experiência. A Comp quebra o RH em dez jornadas (recrutamento, admissão, onboarding, performance, remuneração, offboarding e por aí vai), cada uma desenhada de ponta a ponta.
3. O sistema operacional contextualizado: uma camada única de engajamento por onde as pessoas usam tudo isso. A aposta dele hoje é uma interface agêntica, com uma ressalva que eu achei honesta: “talvez daqui a três anos não seja”.

O que me parece valer pra qualquer área é a ordem. Quase todo mundo que implanta IA começa pela camada de cima, porque é a que aparece (o chat, o agente, a interface), e descobre depois que ela fica em pé em cima de dado bagunçado e de processo que ninguém desenhou. Eu já tinha escrito sobre a régua de maturidade em IA do Pedro e do Christophe Gerlach, e esse modelo de camadas é o mesmo raciocínio aplicado a uma área inteira.

3. O RH como tomador de pedido

O Pedro abriu com um paradoxo: todo mundo concorda que pessoas são o ativo mais importante da empresa, e o RH cuida de pessoas, então o RH deveria ser a área mais importante. Na prática, a gente sabe que não é. A explicação dele passa por uma matriz simples de importância e esforço cognitivo: escolher o almoço é baixo nos dois, uma M&A é alta nos dois, e a decisão de pessoas é a exceção, com altíssima importância (a folha está entre os maiores investimentos da empresa) e quase nenhum esforço de pensamento, fora da pauta do board.

O sintoma que ele deu é bem reconhecível. Na mesma empresa, o recrutamento usa quatro notas, porque “não quero ninguém em cima do muro”, e a avaliação de desempenho usa cinco, porque “tenho gente atendendo a expectativa”. Ninguém está errado, mas também ninguém parou pra pensar nas duas juntas. E o exemplo do pedido de contratação ficou comigo: “Com qual frequência o RH está realmente entrando e falando assim, por que eu quero contratar um pleno?”.

Ele fez questão de dizer que, até ali, tinha falado a palavra AI uma vez só, porque o ponto é pensamento com intenção, uma discussão que existe desde muito antes do ChatGPT.

4. A esteira deveria ser um loop

O RH costuma ser desenhado como uma linha: atrair, contratar, integrar, engajar, desenvolver, avaliar, reconhecer e desligar. A proposta do Pedro é que cada etapa alimente as outras, de modo que o desligamento ensine algo sobre o engajamento e a avaliação ensine algo sobre quem contratar. E ele lembrou quem é o cliente desse produto: o colaborador, o gestor e a empresa. “Nota quem não está aqui: o RH.”

No demo, um vendedor fecha um negócio e o agente pergunta pra quem trabalhou com ele como foi. O feedback deixa de ser a nota de seis em seis meses e vira, nas palavras dele, “um vídeo contínuo, não uma foto”. Com isso, o RH consegue cruzar skills, metas e vagas abertas, prever que a meta de NPS do time não vai ser batida e propor um plano de pessoas antes do trimestre acabar.

5. O que deu errado, contado por quem estava lá

O que eu mais gostei no painel foi ouvir os erros, porque eles ensinam mais que os acertos:

• A triagem de currículos da Amazon, contada pelo Rafael: a IA aprendeu os critérios dos gestores e reproduziu o viés deles, e começou a mandar sempre o mesmo perfil de candidato até alguém levantar a bandeira e o projeto ser corrigido.
• O primeiro bot de atendimento ao funcionário da Amazon, também do Rafael: ele respondia “procure seu RH” pra quase tudo, e quando um funcionário que tinha perdido alguém da família pediu ajuda e recebeu um manual seco de volta, a ferramenta foi desligada.
• O programa de reconhecimento do Nubank, contado pela Suzana: pontos pelo Slack trocados por prêmio. Nas áreas em que foi lançado, a percepção de reconhecimento caiu, e eles encerraram o programa. “Eu mato com tanta dor no coração.”

A lição que a Suzana tirou disso é a frase que o time dela repete: “você não é o usuário”.

6. Product owner com outro nome continua sendo product owner

O Cagan foi bem direto aqui. Pra ele, a primeira causa de fracasso na migração pro modelo de produto é o RH simplesmente trocar o título de quem era product owner pra product manager. O PM desse modelo é um papel de negócio, que precisa entender usuário, dados, finanças, compliance e jurídico, e pela estimativa dele são poucos os POs que fazem essa transição.

7. Previsibilidade e resultado brigam pelo mesmo espaço

Quando todo pedido vem com uma data, o time aprende a bater a data cortando tudo que não cabe, e entrega output. O Cagan não pede pra abolir prazo: ele separa a data que é de verdade (uma lei entrando em vigor, por exemplo) e diz que o resto deveria ser cobrado pelo resultado. Ele citou o cartaz que a Spotify tem nas paredes: “100% predictability equals 0% innovation”. Quando alguém do RH perguntou como fazer isso numa área que vive de calendário (folha no dia 5, ciclo de avaliação em março), a resposta foi a mesma, com uma frase boa: “se tudo é data, nada é data”.

8. Comece por um piloto

No painel e no Q&A o conselho foi igual. O Fabio disse pra escolher um problema, colocar um squad nele, aprender e só depois espalhar. O Cagan foi além: não adianta usar o modelo de projeto pra migrar pro modelo de produto, porque o plano de treinamento e as descrições de cargo escritas antes de ver o time funcionando provavelmente vão pro lixo. Primeiro você vê um time operando assim, e aí sabe do que precisa pra ter mais.

9. Vibe coding é ótimo pra aprender

Essa parte conversa direto com o que eu vejo nas minhas turmas. O Cagan contou de uma pessoa de RH que criou sozinha, com IA, um app de apontamento de horas em poucos dias e desistiu em uma semana, porque cada mudança quebrava o resto. Ele não condena o exercício, pelo contrário: acha que todo mundo deveria prototipar, porque você muda de ideia várias vezes no processo. A distinção que ele faz é entre protótipo, que serve pra aprender, e produto, que serve pra empresa rodar e precisa ser confiável, rápido e correto. “A prototype is to learn, a product is to earn.”

10. O papel humano muda de lugar

A Suzana contou que o Nubank tentou reinventar o ciclo de performance do zero e, pra infelicidade dela, chegou “muito perto do que já fazia”. A diferença é que agora os agentes cuidam das etapas, e o julgamento fica com as pessoas. O mesmo aconteceu com a carta-proposta, refeita com a Comp: o trabalho de compensation e de recrutamento muda de complexidade, mas continua existindo. O Cagan disse algo parecido no fim: na maioria dos trabalhos, as tarefas podem ser automatizadas, mas o pensamento não.

Como cada um mede o retorno

Uma das perguntas da plateia foi sobre ROI da IA, e as respostas foram bem diferentes entre si:

• Stone: pelo problema que está sendo resolvido. O exemplo do Fabio foi o tempo que um vendedor novo leva pra chegar à média do time, que caiu de seis pra quatro meses. Se chegar a dois, dá pra calcular quanto vale em venda.
• Nubank: a Suzana disse que não sabe. Eles olham métricas imperfeitas (horas salvas, que são autodeclaradas, e indicadores de produtividade de engenharia que medem mais output do que resultado) e acompanham a receita por funcionário.
• Uber e Amazon: o Rafael citou custo e receita por headcount, mais a economia de tempo em atividades específicas, que foi a única métrica com a qual eles conseguiram enxergar algum ganho.

Sobre custo, também não houve consenso. Pra Suzana, a estrutura encarece no começo, porque PM, designer e engenheiro ganham mais e “agora a gente tem as pessoas e os tokens”. Pro Fabio, a eficiência do RH da Stone quase dobrou em três anos e o custo total (pessoas, software e tokens) caiu.

A pergunta que eu mandei

Eu mandei uma pergunta pelo QR code, e a Gabriela leu no palco: se a IA assume o trabalho de entrada que formava os juniores, como as empresas vão garantir que ainda vão ter seniores daqui a cinco anos?

O Fabio contou que a Stone mantém mais de 70 programas de formação, de estágio a jovem aprendiz, dimensionados pras vagas que vão precisar no futuro. O Rafael lembrou que isso é um movimento da sociedade e pede intencionalidade, do mesmo jeito que a gente teve com diversidade.

A resposta da Suzana foi a que eu mais levei pra casa. Pra ela, o problema mais difícil é formar julgamento e estratégia em quem nunca fez o trabalho que constrói esse julgamento, e ele aparece em cinco a dez anos, quando a gente precisar de seniores capazes de avaliar o que a IA faz (as evals). O caminho que ela enxerga é mentoring e shadowing, e defender o orçamento dos programas de entrada mesmo que, por um tempo, o júnior esteja ali só acompanhando alguém mais experiente. Me parece um dos assuntos mais importantes que quase ninguém está discutindo, e devo voltar nele por aqui.

Algumas frases que eu anotei

• “Você não é o usuário, não é a sua dor que a gente está resolvendo.” (Suzana Kubric)
• “Eu sou um tomador de pedido.” (Pedro Bobrow, descrevendo o RH de hoje)
• “Vou tentar otimizar o fluxo que não deveria existir.” (Pedro Bobrow, sobre o que evitar)
• “It’s not Accenture’s fault, it’s your fault.” (Marty Cagan, sobre quem erra quando o projeto terceirizado não entrega)
• “In most jobs the tasks might be automated, but the thinking is not.” (Marty Cagan)

Se eu tivesse que resumir a noite numa coisa só, talvez fosse a ordem: problema e dado primeiro, jornada no meio, ferramenta por último. Ela vale pro RH, e me parece valer pra qualquer área que esteja olhando pra IA agora.