O que o RH pode aprender com a lógica de produto, segundo Marty Cagan

Por duas décadas, o americano Marty Cagan trabalhou junto de grandes empresas de tecnologia do mundo para ajudá-las a construir produtos – caso de eBay, Netscape e Hewlett-Packard. Engenheiros, product managers e designers costumam estar no centro de seu trabalho. Mas, na visão do especialista, existe uma consequência quase natural quando essas empresas aprendem a operar dessa maneira: em algum momento, elas começam a se perguntar se poderiam aplicar a mesma lógica aos produtos e serviços usados por seus próprios funcionários.

Essa possibilidade esteve no centro da palestra que Cagan deu durante o Native AI ‘26, evento realizado pela Comp em 28 de setembro, em São Paulo. Em uma fala direcionada a grandes lideranças de RH, o consultor do Silicon Valley Product Group contou como companhias do porte de Apple e Amazon passaram a construir ferramentas internas usando princípios originalmente desenvolvidos para produtos destinados aos consumidores – incluindo soluções de recrutamento e onboarding a treinamento, gestão de desempenho e engajamento.

É um paradigma que está acessível para qualquer RH, como demonstrou Cagan ao longo de sua fala. Para chegar lá, porém, o autor de livros como Inspired e Empowered defende que a área precisa mudar a maneira como pensa sobre essas soluções.

Segundo o especialista, há duas maneiras muito diferentes de construir uma solução. A primeira é o chamado project model, modelo tradicional baseado em projetos. A segunda é o product model, ou product operating model, utilizado pelas empresas que desenvolveram uma cultura mais madura de produto. Entre elas, há uma diferença fundamental. “O modelo de projetos é desenhado para construir funcionalidades, em vez de ser construído para resolver problemas”, disse Cagan.

A lógica é conhecida: alguém identifica uma necessidade, transforma a ideia em um case de negócios, cria um mapa de desenvolvimento, define requisitos, desenha a solução, desenvolve em ciclos e, finalmente, coloca o produto no ar. Parece racional, mas Cagan argumenta que há um problema fundamental: é muito difícil saber antecipadamente qual solução vai produzir o resultado esperado. De fato: segundo uma estimativa citada por Cagan, publicada em um artigo da Harvard Business Review, cerca de 85% do que é construído nesse modelo não gera os resultados de negócio esperados.

Mais importante do que a precisão desse número, para Cagan, é a lógica por trás dele: é difícil saber de antemão o que vai funcionar – e é justamente para lidar com essa incerteza que o modelo de produto existe. “Boas pessoas de produto não são necessariamente melhores em ter ideias. Elas são melhores em saber que a maioria das ideias não vai funcionar”, afirmou.

De funcionalidades para problemas

Ao longo da palestra, Cagan se dispôs também a detalhar o que compõe o modelo de produto. Para ele, o primeiro passo é mudar a pergunta que dá origem ao trabalho. Em vez de começar por uma lista de funcionalidades, o RH deveria começar pelos problemas que precisa resolver – e pelos resultados que pretende alcançar.

Pare de pensar e pedir funcionalidades. Comece a priorizar e identificar problemas para resolver.

O exemplo usado por ele é simples. Imagine que uma dor atual do RH seja um processo de onboarding excessivamente demorado, manual e confuso. Em vez de pedir um novo sistema ou uma determinada funcionalidade, o RH deveria estabelecer um objetivo: reduzir o tempo necessário para integrar um novo funcionário para 30 minutos, sem comprometer a qualidade do processo.

A partir daí, cabe ao time responsável pela solução descobrir como chegar ao resultado. Pode ser necessário desenvolver dez funcionalidades, cinco, nenhuma ou até redesenhar completamente o processo. Nesse processo, mais do que só mudar a perspectiva, é também preciso mudar a cultura do dia a dia. “É quando a equipe deixa de ser um time de mercenários, pagos para construir ou fazer o que é necessário, e passa a ser um time de missionários dedicados a resolver um problema”, disse.

No modelo de produto, portanto, o RH não deveria tratar o time responsável pela solução como um prestador de serviço, mas como parceiro. Além disso, é importante lembrar que o RH não é o cliente da solução, mas sim o colaborador, candidato ou gestor que vai utilizá-la. Ao mesmo tempo, a solução precisa funcionar para outras áreas da empresa. “Não basta funcionar para o head de RH. Tem que funcionar para o jurídico, para compliance, para privacidade”, afirmou Cagan. “É uma colaboração real.”

Um time pequeno, mas com autonomia

Essa mudança exige também uma alteração na composição das equipes. Cagan defende os chamados times de produto empoderados: equipes multidisciplinares que recebem um problema e têm autonomia para decidir como resolvê-lo. Em sua configuração mais simples, especialmente para ferramentas internas, esse time pode ter apenas três pessoas: um gerente de produto (ou PM) um designer de produto e um engenheiro sênior ou líder de tecnologia.

Cada profissional tem uma função diferente. O designer precisa entender profundamente os usuários e suas jornadas, enquanto o gerente de produto precisa compreender o negócio, seus dados e suas restrições. Já o engenheiro deve dominar a tecnologia necessária para construir a solução.

É justamente aí que aparece uma provocação particularmente relevante para o RH. Segundo Cagan, muitas empresas ainda trabalham com profissionais chamados de product owners (PO), mas o papel exercido por eles é bastante diferente daquele que ele espera de um product manager. “Se vocês têm pessoas chamadas product owners, elas não estão preparadas para esse modelo”, disse. Para ele, alguns POs poderiam fazer a transição, mas Cagan estima que isso aconteceria com uma parcela pequena deles – em suas palavras, “talvez 5%”.

O problema, segundo o especialista, é que o product owner costuma ser treinado para administrar um processo de entrega para engenheiros. O gerente de produto, por outro lado, exerce um papel de negócio: precisa conhecer os usuários, a indústria, os dados e as implicações da solução para diferentes partes da organização.

É também por isso que Cagan critica uma prática que, segundo ele, costuma aparecer justamente durante transformações conduzidas pelo RH: simplesmente trocar o nome dos cargos. “Um dos motivos pelos quais vemos transformações fracassarem é que o RH realmente quer – e eu entendo o porquê – simplesmente mudar o título dessas pessoas”, afirmou. “Não funciona.”

Descobrir antes de construir

Outro conceito central da visão defendida por Cagan em São Paulo é a distinção entre descoberta de produto (product discovery, no original) e entrega de produto (product delivery). Antes de construir uma solução que será efetivamente utilizada pela empresa, o time deveria testar hipóteses, criar protótipos e conversar com usuários.

No caso de uma ferramenta de RH, isso pode significar testar uma ideia com funcionários, gestores, profissionais de RH, compliance e outras áreas afetadas pela solução. O objetivo não é perguntar se as pessoas “gostaram” do protótipo. É descobrir se ele resolve o problema e se pode funcionar dentro das restrições da organização. “Só quando temos boas evidências de que temos uma boa solução é que devemos construir algo de verdade”, explicou.

Cagan resume a diferença com outra formulação. “Um protótipo é feito para aprender; já um produto é feito para funcionar”, disse. Um produto que será utilizado pela empresa precisa ser confiável, preciso, resiliente e capaz de lidar com situações que um protótipo não precisa enfrentar. Essa distinção ganhou uma camada adicional com o avanço do chamado vibe coding.

Para explicar, o especialista em produto contou o caso de uma pessoa de RH que criou, usando ferramentas de IA, um pequeno aplicativo para gerenciamento de tempo. Em poucos dias, havia algo funcional. O problema apareceu depois, quando tentou dividir o sistema com outras pessoas: a cada alteração, alguma parte do app deixava de funcionar.

Para Cagan, isso não significa que profissionais de RH não deveriam experimentar com IA. Pelo contrário. Criar protótipos pode ser uma ótima maneira de entender melhor um problema e até mudar de opinião sobre a solução imaginada inicialmente. O erro está em confundir o protótipo com um produto pronto para sustentar uma operação. “Não há problema em desenvolver suas próprias ideias. Só não confunda aquilo que você criou com vibe coding com algo que a empresa pode realmente usar”, disse.

Resultado antes da previsibilidade

Muito do trabalho do RH envolve datas – folha de pagamento, pesquisas, ciclos de avaliação e tantas outras entregas com calendários definidos. É um cenário em que a recomendação de priorizar resultados em vez de previsibilidade pode parecer especialmente difícil.

Cagan não defende que datas deixem de existir. O que ele propõe é separar aquilo que realmente precisa acontecer em uma data específica daquilo que simplesmente ganhou uma data porque o processo tradicional exige. “Se você quer resultados, precisa priorizar resultados”, afirmou.

Há exceções. Uma mudança regulatória, por exemplo, pode ter uma data inegociável. Nesse caso, a previsibilidade é de fato uma necessidade. Mas, para Cagan, transformar toda entrega em um compromisso de data faz com que os times passem a otimizar a entrega, e não necessariamente o resultado. Ele citou uma frase que o Spotify mantém nas paredes de seus escritórios: “100% de previsibilidade é 0% de inovação”.

A provocação vale especialmente para o RH porque, em muitas organizações, a previsibilidade é parte importante da própria legitimidade da área. O risco, segundo Cagan, é transformar essa previsibilidade em objetivo por si só e deixar em segundo plano a pergunta mais importante: o que aquela iniciativa deveria mudar?

Para que esse modelo funcione, porém, a mudança não pode ficar apenas do lado do time de produto. O próprio RH precisa mudar a forma como trabalha com ele. Cagan aponta três coisas que a área deve oferecer: acesso aos usuários, acesso aos dados e acesso aos principais stakeholders. “Sem acesso a essas três coisas, nem vale a pena tentar”, resumiu o americano.

O primeiro ponto parece óbvio, mas nem sempre acontece. Um time que está construindo uma solução para colaboradores precisa conversar com eles. Isso não significa, porém, que a lógica de produto seja simplesmente transformar pedidos das pessoas em funcionalidades. Durante o Q&A, Cagan foi provocado justamente sobre como lidar com solicitações de usuários. Sua resposta foi que colaboradores sabem apontar os problemas que enxergam, mas não necessariamente conhecem as possibilidades abertas pela tecnologia.

“As ideias são apenas ideias”, disse. O papel do time de produto é testá-las – e descobrir se as pessoas de fato usariam aquela solução. Além disso, o time de produto também precisa ter acesso aos dados gerados pela utilização da ferramenta, porque é isso que permite entender se o produto está de fato sendo usado e se está produzindo o resultado esperado. E, claro, precisa ter acesso aos responsáveis pelas restrições do negócio.

Na prática, isso significa que o time pode pedir dez ou 15 minutos de um executivo algumas vezes por semana para mostrar um protótipo. Não para perguntar se a pessoa gostou da cor ou do layout, mas para verificar se a solução viola alguma regra de privacidade, segurança, compliance ou legislação.

A mudança, portanto, não é apenas tecnológica. É também uma mudança de poder. O modelo tradicional concentra decisões: alguém define o que deve ser construído e outra equipe executa. No modelo de produto, a liderança continua responsável por definir o problema e o resultado esperado, mas compartilha com o time a decisão sobre como chegar lá.

Começar pequeno

Mudar de perspectiva não é uma tarefa fácil. Até mesmo o próprio Cagan concorda que implementar todas essas medidas de uma vez é uma transformação grande demais. Inclusive, ele mesmo recomendou explicitamente que nenhum profissional tente fazer isso.

“Não seria inteligente tentar fazer tudo isso de uma vez, mesmo que você esteja completamente convencido”, disse. No lugar, a recomendação é escolher uma única iniciativa e tratá-la como experimento.

Se uma empresa tem dez problemas ou soluções de RH que gostaria de construir, por exemplo, deve escolher uma delas e tentar aplicar ali o modelo de produto. Se funcionar, pode repetir a experiência. Se não funcionar, o custo do erro é limitado.

É uma abordagem de baixo risco, baixo custo e, mais importante, você não sabe o que precisa até ver funcionando.

Há, ainda, uma ironia nessa recomendação. Para Cagan, uma transformação para o modelo de produto não deveria ser conduzida pelo próprio modelo de projetos – com um grande plano de implementação, novos cargos, treinamentos e processos definidos antecipadamente. Em vez disso, o RH deveria experimentar a mudança da mesma maneira que espera que seus times construam produtos: criando uma hipótese, testando, aprendendo e ajustando. “Ou seja: não use o modelo de projetos para tentar implementar o modelo de produto”, disse o americano. “Use o próprio modelo de produto.”