Gestão de produto de IA no Spotify muda conforme o tipo de problema, dizem líderes de engenharia

O texto da engenharia do Spotify parte de uma crítica: quase tudo o que se publica trata "o PM de IA" como um cargo único. Três líderes da mesma área (Personalization), na mesma stack, descrevem três jobs diferentes. Henok cuida de produto em Tech Research, onde sucesso pode ser uma escolha tecnológica certa, uma metodologia que dá confiança a várias equipes ou um resultado que muda onde a empresa investe. Divita lidera um modelo fundacional de linguagem feito para recomendação, que referencia itens reais do Spotify. Humberto constrói a experiência que o usuário toca, em Sessions.

As diferenças aparecem nas métricas e no cliente. No modelo fundacional, os clientes são times internos, e a mesma máquina precisa atender definições distintas de boa recomendação. O comportamento vem de treino, não de especificação em código, então as alavancas são dados e evals. Avaliações offline explicam o modelo, métricas online mostram o efeito para o ouvinte. Na camada de experiência, o cliente é o usuário final, o input é aberto e A/B test e avaliação offline não bastam. O time monta datasets a partir de uso real, ciclos de feedback e juízes baseados em LLM, e trata avaliação como produto contínuo. Em pesquisa, o impacto pode levar meses e aparecer no roadmap de outro time, o que torna influência parte central do papel.

Para quem gerencia produto com IA, a leitura é prática: antes de copiar um framework de "PM de IA", vale definir em qual camada você atua. Isso muda quem é o cliente, o que conta como sucesso e quando a avaliação entra. O relato do Spotify sugere acordar o critério de sucesso antes da arquitetura, e tratar evals como parte do produto, não como etapa pré-lançamento.