Como é diferente criar produtos com IA — e por que as equipas de produto precisam de evoluir

Galen Low: Há realmente algo assim tão diferente no processo de desenvolver um produto que tenha funcionalidades nativas de IA, em comparação com outros produtos que podem simplesmente aproveitar tecnologias de IA já existentes?

Jyothi Nookula: Sim. Quando se está a criar um produto nativo de IA, estamos a lidar com três coisas diferentes. Primeiro, a IA é fundamentalmente imprevisível.

Galen Low: Qual é a primeira coisa que fazes enquanto líder quando reparas que uma equipa pode não estar toda ao mesmo nível no que diz respeito a compreender, utilizar e até aceitar tecnologias emergentes como a IA?

Jyothi Nookula: Separo o problema em duas questões distintas. A primeira é a competência. A segunda é a predisposição. Se tratares um problema de predisposição como um problema de competência, só o vais piorar.

Galen Low: Quais são as principais coisas que um gestor de produto interessado em desenvolver produtos de IA precisa de ter no currículo ou no portefólio para se destacar?

Jyothi Nookula: Uma delas é ter provas de que construiu algo com IA, e não apenas falar sobre isso. A segunda coisa é...

Galen Low: Bem-vindos ao podcast The Digital Project Manager — o programa que ajuda líderes de entregas a trabalhar de forma mais inteligente, entregar mais depressa e liderar melhor na era da IA. Eu sou o Galen e, todas as semanas, exploramos estratégias do mundo real, novas ferramentas, estruturas comprovadas e, ocasionalmente, uma história de guerra da linha da frente dos projetos. Quer esteja a liderar enormes projetos de transformação, a gerir fluxos de trabalho de IA ou simplesmente a tentar manter o caos sob controlo, está no sítio certo. Vamos começar.

Hoje vamos falar sobre o futuro do gestor de produto, o que é necessário para desenvolver produtos de IA, como a IA está a ser utilizada para otimizar o processo de desenvolvimento e lançamento de produtos e o que os líderes de equipas podem fazer quando as suas equipas de produto têm uma distribuição desigual de competências e atitudes em relação a tecnologias emergentes como a IA.

Tenho hoje comigo no estúdio a Jyothi Nookula. A Jyothi tem mais de 13 anos de experiência a impulsionar a inovação em produtos e plataformas de IA em empresas como a Netflix, a Meta, a Amazon AWS e a Etsy. Detém também 12 patentes de aprendizagem automática e orientou mais de 1500 gestores de produto na transição para funções de IA através da sua empresa de formação, a Next Gen Product Manager.

Jyothi, muito obrigado por estares aqui comigo hoje.

Jyothi Nookula: Olá a todos. Estou muito entusiasmada por estar aqui hoje.

Galen Low: Eu também estou entusiasmado e tenho estado à espera disto há semanas. Quando falámos pela primeira vez, antes de mais, quando estava a consultar o teu perfil, pensei: uau, a Jyothi é uma força da natureza. Há muitas marcas e muitas tecnologias no teu perfil que são dignas de inveja.

E sou sempre um grande fã de pessoas que tentam ajudar a próxima geração de qualquer área a evoluir num mundo cada vez mais tecnológico e agora orientado para a IA. E depois, quando falámos, pensei: uau, temos tanto em comum. Eu estou mais ligado ao lado dos projetos e tu estás mais ligada ao lado dos produtos. Mas estou muito entusiasmado por explorar como as coisas estão a mudar e algumas das coisas que aprendeste ao longo da tua jornada pelos produtos de IA e de aprendizagem automática.

Sei que provavelmente vamos seguir alguns caminhos secundários ao longo do percurso que serão profundamente interessantes e valiosos, por isso espero que isso aconteça. Mas o gestor de projetos que há em mim criou hoje este roteiro para nós. Para começar, queria tirar do caminho uma grande questão que me inquieta — aquela pergunta desconfortável mas urgente cuja resposta acho que todos querem conhecer.

Mas depois gostaria de recuar e falar sobre três coisas. Primeiro, gostaria de falar sobre a identificação e eliminação de lacunas de competências nas equipas de produto. Ao lidar com produtos que utilizam funcionalidades de IA e aprendizagem automática, gostaria depois de explorar alguns exemplos de formas como as vossas equipas utilizaram ferramentas de IA no processo de desenvolvimento de produtos, seja na investigação, análise de dados, design, engenharia, testes com utilizadores ou algo completamente diferente.

Por último, gostaria de explorar como será o futuro da função de gestão de produto. O que é que um currículo ou portefólio precisa de ter para que alguém seja sequer considerado para funções em empresas como a Meta, a AWS, a Netflix, a Etsy e outras marcas importantes orientadas para a IA?

Jyothi Nookula: Adoro. Estou interessada. Esse é o tema quente do momento. Adoro mesmo.

Galen Low: Excelente. Comecemos por essa grande questão. A minha grande questão para enquadrar tudo isto é, claro, sobre IA. Tiveste muita experiência a trabalhar com equipas de produto para desenvolver soluções baseadas em IA e aprendizagem automática para gigantes como a Meta, a Amazon, a Etsy e a Netflix. A minha pergunta é: há realmente algo assim tão diferente no processo de desenvolver um produto que tenha funcionalidades nativas de IA, em comparação com outros produtos que podem simplesmente aproveitar tecnologias de IA já existentes?

Jyothi Nookula: É uma excelente pergunta, porque vai diretamente ao centro do que está realmente a mudar no desenvolvimento de produtos neste momento. E a resposta honesta é fundamentalmente sim, mas não da forma como as pessoas pensam. É isto que quero dizer. Quando se está a criar um produto nativo de IA, estamos a lidar com três coisas que são diferentes do software tradicional ou até de produtos que simplesmente se integram com IA através de uma API.

A primeira é que a IA é fundamentalmente imprevisível. No desenvolvimento tradicional de produtos, escrevemos código determinístico: se isto acontecer, faz aquilo. Ou, se clicar neste botão, passa para o ecrã seguinte. Sempre que clico nesse botão, ele fará a mesma coisa. Mas, com produtos nativos de IA, estamos a trabalhar com sistemas probabilísticos, por isso a funcionalidade de IA pode funcionar de forma diferente de cada vez que é executada.

Isto significa que todo o processo de garantia de qualidade, o tratamento de casos extremos e todas as garantias de fiabilidade têm de ser completamente repensados, porque já não estamos apenas a testar se algo funciona; estamos a testar se funciona suficientemente bem e se funciona de forma consistente todas as vezes, ao longo de uma distribuição de resultados.

Essa é a primeira diferença fundamental: a imprevisibilidade, o determinístico versus o probabilístico. A segunda é que estamos agora a criar produtos sobre terreno instável, porque os modelos subjacentes evoluem de formas que não conseguimos ou não controlamos. Por exemplo, um novo modelo pode alterar o comportamento.

Pode não ser uma alteração incompatível, mas pode mudar ligeiramente o comportamento, expandir capacidades ou introduzir novos modos de falha. E estas coisas acontecem de um dia para o outro, ao ritmo a que tudo está a evoluir atualmente. Ao contrário das dependências tradicionais, em que era possível controlar as versões das alterações incompatíveis e documentar as atualizações.

Estas atualizações dos modelos estão a acontecer mais depressa do que conseguimos acompanhar. E a terceira coisa, que é muito importante, é que as métricas de sucesso têm de ser diferentes. Já não se pode medir apenas se uma funcionalidade foi executada com sucesso. Agora é preciso medir coisas como: o resultado foi útil? Não se trata apenas de ter sido executado; foi útil?

Correspondeu à intenção do utilizador? À pergunta que o utilizador fez? E como é que se define sequer o que é bom para o seu caso de utilização? Acabamos por precisar de ciclos de feedback muito mais apertados com os utilizadores e temos agora de incorporar estes mecanismos de avaliação diretamente no desenvolvimento do produto, o que é muito diferente da forma como o desenvolvimento tradicional de produtos é feito.

Estas são as três coisas muito diferentes nos produtos que apenas recorrem a IA existente, como quando se adiciona uma integração com o ChatGPT. Estes podem continuar a ser como integrações tradicionais. Continuamos a ter métricas de sucesso e aspetos que temos de analisar, bem como avaliações que temos de acompanhar.

Mas, nesse caso, pelo menos existe um contrato. Quando se está a criar o produto como um produto nativo de IA desde o início, é completamente diferente. E é aí que estas três coisas têm ainda mais impacto no desenvolvimento do produto.

Galen Low: É engraçado, porque entrei nesta pergunta a pensar: vou fazer esta pergunta e ela provavelmente vai dizer que é mais ou menos igual, com algumas pequenas diferenças, mas isto muda completamente o jogo.

Adorei o que disseste sobre medir a intenção e sobre a medição, certo? Porque venho do mundo dos projetos e temos o nosso documento de requisitos. É binário. É sim ou não. Fez aquilo que estava indicado na especificação funcional? Mas depois existe toda esta ambiguidade. Primeiro, porque é probabilístico e o resultado não será o mesmo todas as vezes.

E, segundo, porque a arquitetura subjacente é, de certa forma, uma caixa negra e está a evoluir por si própria todos os dias, mais depressa do que os seres humanos conseguem compreender. E penso: isto é, na verdade, muito diferente da forma como penso que a maioria dos produtos digitais foi criada na história recente. Mas faz sentido. É isto que estou a pensar.

Tens mais de uma década de experiência a trabalhar com aprendizagem automática e IA. Muitas pessoas só começaram nos últimos dois anos. É algo novo para elas. O ChatGPT abriu-lhes os olhos para a forma como a IA pode ser utilizada, mas ela já existe no software e nos nossos produtos digitais há algum tempo.

E estou a pensar que, como assististe a isso na Netflix, parece tudo tão simples e provavelmente não é. O algoritmo, a aprendizagem automática, o processamento de dados no sistema — não é apenas porque tudo na Netflix está etiquetado com uma determinada taxonomia; não são simplesmente ligações relacionadas num site.

É realmente uma questão de comportamento e intenção, e é fácil errar. É fácil quase nunca perceber o quão errado está até aparecer aquele comentário no Twitter: meu Deus, a minha Netflix nunca acerta porque vi isto. Agora está a sugerir 18 temporadas de Barney.

Jyothi Nookula: Isso acontece a toda a hora com os vídeos do Instagram e do TikTok. Vou ver um vídeo de alguém a esquiar e depois fico inundada de vídeos de esqui. Sim.

Galen Low: E acho que é algo que tomamos demasiado como garantido. Seria fácil para as pessoas, incluindo eu próprio, pensar: não sei, parece bastante simples, bastante fácil. O mesmo truque, o mesmo conjunto de competências. Mas, quando desmontamos realmente a questão dessa forma, percebemos que não é assim. Perguntava-me se poderíamos recuar um pouco a partir daí, porque, para além do teu impressionante percurso a liderar produtos digitais para marcas como a Amazon, a Meta, a Netflix e a Etsy, também és a fundadora da Next Gen Product Manager, que inclui, entre outras ofertas educativas, algo semelhante a um curso intensivo de cinco semanas para fazer a transição da gestão de produto convencional para a gestão de produtos de IA.

E, francamente, o facto de o teu curso existir diz-me que nem todas as competências convencionais de gestão de produto estão a ser suficientes atualmente. É necessária uma mentalidade e um conjunto de competências de próxima geração ou mais virados para o futuro. E, embora possas ter tido a oportunidade de escolher cuidadosamente as tuas equipas ao longo da carreira, é razoável pensar que nem todas as pessoas das tuas equipas tiveram exatamente as mesmas competências e atitudes relativamente à IA e a outras tecnologias emergentes. A minha pergunta é: qual é a primeira coisa que fazes enquanto líder quando percebes que uma equipa pode não estar toda ao mesmo nível no que diz respeito a compreender, utilizar e até aceitar tecnologias emergentes como a IA?

Jyothi Nookula: Sim, este é um desafio muito prático e real, algo com que lidei bastante e continuo constantemente a lidar. Fui líder de pessoas, a gerir equipas de diferentes dimensões, desde três a cinco, 10 ou 12 pessoas. Passei por todo esse espectro, e a lacuna de competências e de conforto relativamente à IA é a maior que alguma vez vi em qualquer tecnologia ou mudança ao longo da minha carreira.

Quando me deparo com este problema, a primeira coisa que gosto de fazer é separar o problema em duas questões distintas. A primeira é a competência, quando as pessoas não sabem trabalhar eficazmente com IA. A segunda é a predisposição, quando as pessoas são céticas, resistentes ou até estão ansiosas relativamente à IA.

É preciso diagnosticar com qual das duas estamos a lidar. Talvez exista uma combinação de ambas, mas é importante reconhecer qual o problema que se está a tentar resolver, porque, se tratarmos um problema de predisposição como um problema de competência, só o vamos piorar. No caso das lacunas de competência, o meu primeiro passo é criar algum tipo de contexto partilhado através da prática, não da aprendizagem teórica.

É a mesma filosofia que ensino aos meus alunos no meu curso de cinco semanas sobre gestão de produtos de IA, em que aprendem através da prática e não apenas de teoria. Não gosto de enviar as pessoas para formações ou pedir-lhes que vejam tutoriais. Em vez disso, integro imediatamente a IA nos nossos fluxos de trabalho reais e obtenho resultados rápidos.

Trata-se de integrar o Claude ou o GPT para escrever retrospetivas de sprint, sintetizar temas, fazer investigação aprofundada ou preparar resumos de investigação com utilizadores — algo em que as pessoas vejam a ferramenta a fazer trabalho real por elas, sem necessariamente a encararem como uma substituta no espaço de duas semanas. Nas reuniões, pergunto: falem-me de algo que a IA vos ajudou a fazer mais depressa, ou digam-me uma ideia que não teriam identificado sem a IA. Essas experiências partilhadas tornam-se a base para desenvolvermos competências em conjunto.

Para os problemas de predisposição, que estão mais relacionados com resistência ou medo, penso que a melhor abordagem é começar pela curiosidade e não pelo entusiasmo evangelizador. Nas reuniões individuais, costumo perguntar: qual é a tua verdadeira preocupação aqui? E depois fico em silêncio e ouço. Normalmente, o que surge dessas conversas é algo legítimo. As pessoas dizem coisas como: sinto que isto vai desvalorizar o meu trabalho.

Ou: não confio nos resultados porque não consigo verificá-los completamente. Ou ainda: sinto que estou a ficar para trás e que tudo isto é avassalador. Estas são preocupações reais. E foi aí que aprendi que não se consegue fazer alguém deixar de ter medo através da lógica. O que se pode fazer é reconhecer o medo, normalizá-lo e mostrar um caminho em frente.

Para alguém preocupado com a desvalorização do seu trabalho, mostro como a IA pode tratar a estrutura inicial, permitindo que essa pessoa se concentre no trabalho mais complexo e que exige maior discernimento, para o qual antes nunca tinha tempo. Para alguém preocupado com a verificação, digo: muito bem, vamos criar juntos as estruturas de avaliação.

Assim, essa pessoa torna-se especialista na garantia de qualidade da IA. Outra coisa que considero muito eficaz é identificar imediatamente estas pessoas de ligação. Em todas as equipas há pessoas naturalmente curiosas sobre IA. Estão constantemente a experimentá-la e a inovar. São práticas e estão a obter resultados.

Dou-lhes autorização explícita para partilharem o que está a funcionar bem. De forma informal, podem fazer pequenas sessões de partilha nas reuniões diárias. Isto cria aprendizagem entre pares, porque, quando as pessoas veem um colega a adotar a tecnologia e a obter resultados, ficam mais abertas a experimentá-la do que quando um líder lhes diz, de cima para baixo, para fazerem algo.

A última medida pode ser um pouco controversa: avanço rapidamente para estabelecer que a fluência em IA está a tornar-se uma expectativa básica. Sou empática relativamente à curva de aprendizagem e muito paciente com o processo, mas sou clara quanto à direção: isto não é opcional. Tal como todos tivemos de aprender sobre processos ágeis, análise de dados ou, por exemplo, design inicial, isto agora faz parte do trabalho.

Descobri que combinar um elevado nível de apoio com padrões elevados e expectativas claras reduz efetivamente a ansiedade. As equipas que vi terem mais dificuldades são aquelas em que os líderes são ambíguos relativamente às expectativas e também não fornecem apoio real. É aí que surge o ressentimento, porque existe uma grande sensação de impotência.

O objetivo não é colocar toda a gente imediatamente ao mesmo nível. O objetivo é fazer com que todos avancem na mesma direção, com segurança psicológica e ferramentas práticas.

Galen Low: Adoro isso. Antes de mais, adoro essa separação entre competência e predisposição. Fico contente por teres seguido esse caminho. E, enquanto descrevias tudo isso, pensei: isto é quase uma combinação de gestão da mudança e construção de equipas a acontecer em tempo real.

Temos tendência para pensar na gestão da mudança como algo que fazemos quando uma grande mudança está a ser implementada. É quase como uma iniciativa pontual, enquanto isto é quase gestão da mudança em tempo real, todos os dias, com uma equipa. Como disseste, com apoio, e não simplesmente dizer às pessoas para aprenderem sozinhas porque têm de o fazer, mas criando a competência coletiva e a predisposição coletiva da equipa.

É um pouco mais horizontal, um pouco mais orgânico, existe mais clareza e não quero dizer pressão dos pares, mas sim apoio entre pares. Estamos a partilhar conhecimento e informação. E adorei o que disseste sobre algumas das ansiedades legítimas relacionadas com a IA: sentir que se está a ficar para trás, sentir que não há tempo suficiente para fazer as coisas e sentir que o nosso trabalho está a ser desvalorizado. Não há provavelmente melhor forma de encontrar um caminho em frente do que ver os colegas a lidar efetivamente com isso e a pô-lo em prática no dia a dia, e não apenas como teoria.

Na verdade, estão a fazê-lo em conjunto. Gosto mesmo disso. Sou um grande defensor da aprendizagem pela prática, por isso fico muito contente por saber que isso também faz parte da forma como ensinas. E, sinceramente, penso que essa questão da clareza me tocou particularmente. Os teus padrões são elevados, as tuas expectativas são elevadas, mas o apoio existe e é a clareza que nos fará avançar.

Porque a decisão sobre se isto é apenas uma tendência passageira que se pode ignorar ou se vai tornar-se tão normal como escrever num teclado — já ultrapassámos essa fase, pelo menos a nível organizacional, para muitas das pessoas com quem trabalhaste. A decisão já foi tomada: não podemos ignorar a IA. Portanto, vamos avançar, mas precisamos de o fazer em conjunto.

Jyothi Nookula: Sim.

Galen Low: Mencionaste algumas coisas sobre pequenas experiências e projetos-piloto para dar às pessoas contacto prático com a IA e desenvolver as suas competências e confiança. Imagino que exista uma grande variedade de formas de expandir isso e de áreas onde a IA pode ser utilizada no desenvolvimento de produtos que são, por natureza, também produtos de IA.

Poderias dar-nos alguns exemplos de outras formas como as tuas equipas têm utilizado a IA na conceção e no desenvolvimento dos produtos?

Jyothi Nookula: Sim. Posso dar-te exemplos concretos de todo o ciclo de vida do desenvolvimento de produtos.

Galen Low: Adoro.

Jyothi Nookula: Começando pela descoberta e investigação. Utilizar a IA para comprimir drasticamente a geração de ideias. Normalmente fazemos muita investigação com utilizadores, por exemplo, 15 a 20 conversas. Em vez de passarmos uma semana a identificar os temas, introduzimos as transcrições no Claude e pedimos-lhe que identifique padrões, contradições ou casos extremos.

Mas a questão fundamental é que não se deve aceitar o resultado isoladamente. Continuamos a analisá-lo com o investigador, que o revê, questiona e aperfeiçoa. Essa intervenção humana é muito importante. A IA fornece um primeiro rascunho muito forte numa hora, em vez de numa semana, e o investigador pode dedicar o seu tempo ao trabalho que exige mais discernimento: decidir que ideias são realmente importantes, qual delas desafia os nossos pressupostos e o que devemos investigar a seguir.

O investigador de utilizadores e o gestor de produto podem trabalhar em conjunto para identificar esses padrões. O mesmo acontece com os pedidos de suporte. Se o produto já estiver no mercado, o volume de suporte é sempre enorme. Em vez de rever manualmente esses pedidos para identificar padrões, analisamos milhares de conversas de apoio ao cliente para perceber quais são os pontos problemáticos.

Qual é a dimensão desses problemas? Qual é o seu alcance? A IA identifica padrões de uma forma que não conseguiríamos manualmente, simplesmente devido ao enorme volume que chega através dos canais de suporte. Depois, enquanto gestor de produto, consegues ver a investigação com utilizadores e os padrões do volume de suporte.

Ficas numa posição mais forte para perceber o que deve ser prioritário resolver e quais as funcionalidades que deves realmente priorizar nos teus planos. Mesmo na documentação ou na comunicação, por exemplo, a IA está a eliminar o trabalho repetitivo. Temos visto pessoas a utilizar IA para redigir documentos de requisitos de produto, resumir revisões de impressão e até criar atualizações para as partes interessadas.

A IA consegue criar primeiros rascunhos sólidos de todas estas coisas. Um dos meus gestores de produto disse-me: costumava passar 30% do meu tempo a escrever documentação e agora passo 30% do meu tempo a editar e aperfeiçoar essa documentação. Isso é muito mais valioso, porque agora tens um bom ponto de partida sobre o qual construir.

Também estamos a utilizar a IA para tornar a documentação mais acessível. Alguém pode perguntar: o que decidimos sobre a reformulação do fluxo de pagamentos? E obter uma resposta sintetizada a partir de três conversas diferentes no Slack, duas reuniões e um documento de requisitos, por exemplo. A IA também está a ajudar a tornar essa documentação mais acessível.

Ao longo de todo o ciclo de desenvolvimento do produto, desde a experimentação à documentação e até à forma como interagimos com a engenharia, inicialmente nós, enquanto gestores de produto, éramos responsáveis por criar e escrever documentos de requisitos. Estes documentos não vão desaparecer. Continuam a existir, mas há agora um novo componente: o protótipo.

Por que razão havemos de fornecer apenas uma lista de histórias quando podemos experimentar e criar um protótipo? Podemos obter um simples sinal de adequação produto-mercado e entregar o protótipo à engenharia como uma ideia. É uma nova forma de criar um documento de requisitos: temos um documento que capta a visão, as avaliações, como deve funcionar, quando deve funcionar, como é um bom resultado e como é um mau resultado.

Mas também temos um protótipo que descreve a interação, a capacidade de interação e a forma como o produto deve ser imaginado. Estamos a ver isto em todo o ciclo de vida do desenvolvimento de produtos.

Galen Low: Gosto que tenhas levado a conversa até aí, porque falei com algumas pessoas de produto ainda na semana passada e estávamos a discutir se os documentos de requisitos de produto, os PRD, estão mortos.

Quando falei com uma colega, ela disse que não, porque ainda é necessário ter essas ideias e elas ainda têm de ser boas ideias. Ela tinha criado uma pequena aplicação que ajuda a desenvolver essas boas ideias e a fundamentar por que razão o produto se adequa ao mercado, que funcionalidades deve ter e quais são prioritárias.

Depois ligamos isso novamente à prototipagem. Ainda é necessário ter essa visão; a IA não vai encontrar sozinha todas as respostas criativas e isso ser suficiente. Continuamos a precisar de uma visão estratégica para o que o produto faz, como satisfaz as necessidades dos utilizadores e como o levamos ao mercado.

Mas gosto da ideia de que existe uma mudança no trabalho de alguém. Conheço muitos gestores de produto e, sim, o trabalho é pesado em documentação, o que também se tornou uma superpotência, porque, como disseste, agora passam a maior parte do tempo a editá-la. Mas a documentação já fazia parte do processo, o que significa que é possível treinar a IA com base nela.

Ao contrário das pessoas que antes não escreviam nada. Agora têm de começar a documentar para conseguirem beneficiar da IA. De certa forma, os gestores de produto estão numa posição avançada. E adoro a ideia destas máquinas de primeiros rascunhos. Tinha uma pergunta, porque no mundo dos projetos sei que há muitas pessoas que dizem: sim, é ótimo para um primeiro rascunho.

Estás a descobrir que as tuas equipas utilizam apenas esse robô de primeiros rascunhos e depois avançam para as outras partes do processo? Ou estão a devolver-lhe informação para poderem melhorar a máquina, para que ela se torne cada vez melhor a criar primeiros rascunhos, introduzindo os resultados e as versões editadas?

Jyothi Nookula: Chamamos a isso uma abordagem de tentativa única. As pessoas assumem que é uma coisa de uma só tentativa com a IA: introduz-se algo, ela fornece um relatório e depois podemos avançar. Raramente é assim. Normalmente, obtemos apenas um primeiro rascunho forte, mas depois iteramos, acrescentamos as nossas ideias e pedimos uma crítica às nossas posições ou às áreas que podem ser aperfeiçoadas.

Depois ela apresenta as suas ideias e podemos dizer: esta parte faz sentido, mas não concordo com a outra. É como ter um parceiro com quem podemos continuar a aperfeiçoar o resultado até nos sentirmos realmente bem com o ponto a que chegámos. Se tratarmos os sistemas de IA como uma forma de lhes dar algo, obter uma resposta numa única tentativa e avançar simplesmente com ela, isso raramente funciona.

O que tenho visto melhorar o valor é trabalhar iterativamente e aperfeiçoar o resultado. É por isso que dizemos que é fácil ensinar como fazer, mas é muito difícil ensinar bom gosto. O bom gosto continua a ser algo que o gestor de produto tem de assumir.

Galen Low: Gosto desse conceito de bom gosto. Achas que muitas pessoas pensam: agora 30% do meu trabalho não consiste apenas em editar documentação, mas também em falar com um robô? Em vez disso, como disseste, grande parte da função de gestor de produto é bastante humana, certo? Fazemos entrevistas e investigação com utilizadores e, sim, vamos ter grandes volumes de dados com os quais não teremos uma relação individual com uma pessoa, e a IA pode ajudar definitivamente nesse ponto. Mas sentes que existe uma perda de humanidade na gestão de produto do ponto de vista de alguém que tem essa predisposição?

Talvez uma das ansiedades ou preocupações seja: passo a maior parte do tempo a falar com um robô e a ensiná-lo, e não é a mesma coisa que falar com uma pessoa.

Jyothi Nookula: Não sei se é tanto uma questão de falar com um robô, porque, como disse, se formos apenas nós e o sistema de IA a falar, então é diferente.

Mas continuamos a ter de convencer as partes interessadas e falar com a equipa de engenharia. Os gestores de produto estão num ponto central em que têm de ligar diferentes equipas. Por isso, de certa forma, é mais como ter um assistente útil com quem podemos fazer uma sessão de ideias. Tenho visto os meus gestores de produto, líderes e colegas utilizarem-no dessa forma.

Correm até ele e conversam com a ferramenta para fazer uma sessão de ideias. É menos robótico e mais uma forma de começar e perceber as coisas, tendo um companheiro disponível 24 horas por dia, sete dias por semana, com quem se pode falar.

Galen Low: Fazendo de advogado do diabo, trabalhaste em alguns lugares onde tenho quase a certeza de que alguém te perguntou: Jyothi, porque não podemos simplesmente automatizar este processo?

Porque é que é necessário ter uma pessoa envolvida? Não poderíamos simplesmente recolher todos os pedidos de suporte, passá-los por um agente, pedir-lhe que definisse a prioridade de novas funcionalidades, desenvolvesse essas funcionalidades e as lançasse sem que ninguém estivesse envolvido? Não precisas de me dizer se isso aconteceu ou não, mas podes fazê-lo.

E a minha pergunta é: como reagir a uma abordagem centrada primeiro na tecnologia, em vez de uma abordagem centrada primeiro nas pessoas ou nos utilizadores, especialmente ao nível em que trabalhaste, em grandes empresas tecnológicas onde existe pressão para dizer: sim, mas não poderíamos simplesmente utilizar esta tecnologia e decidir mais tarde o que fazer com ela?

Como reagir a isso e defender a importância de manter uma pessoa envolvida no processo?

Jyothi Nookula: Sim, deparo-me muito com isso, inclusive quando presto consultoria a muitas destas empresas e com os meus alunos, que dizem: estou nesta situação; como devo trabalhar? É quase uma doença atualmente: toda a gente quer começar pela IA. Para o melhor ou para o pior, sinto que estamos a esquecer-nos dos utilizadores e dos seus problemas e estamos a começar pela tecnologia, o que é muito contraintuitivo.

O mais difícil é reagir, porque os incentivos institucionais estão todos a apontar na direção errada. Temos executivos que leram os mesmos três artigos sobre a IA ser uma questão existencial. Temos investidores a perguntar qual é a estratégia de IA em todas as chamadas de resultados.

E temos engenheiros genuinamente entusiasmados; vemos isso nos eventos de programação intensiva. A pressão para fazer algo com IA é enorme. Mas o que digo é que devemos regressar aos primeiros princípios do produto: começar pelo utilizador e pelos problemas, e não pelo algoritmo. Digo sempre isto nas minhas aulas: os utilizadores antes dos algoritmos.

Quando alguém aparece muito entusiasmado ou um vice-presidente diz: existe esta nova capacidade de IA, é multimodal, é voz ou seja o que for que é novidade, não se consegue vencer dizendo não. Em vez disso, reformulo a questão: essa tecnologia é muito interessante. Que problema estamos a tentar resolver com ela? Faço com que a pessoa articule qual é o problema, não como uma armadilha, mas pedindo-lhe que me explique o dia do utilizador.

Onde é que isto se enquadra? O que é que os utilizadores estão a tentar fazer atualmente? Qual é a alternativa se isto não existir? Normalmente, uma de três coisas acontece. A primeira é perceberem que se trata de uma solução à procura de um problema, porque o entusiasmo desaparece naturalmente quando não conseguem articular uma necessidade convincente do utilizador.

Não é necessária qualquer confrontação. Ou descobrem que existe um problema real, mas que a tecnologia — especificamente a tecnologia de IA — provavelmente não é a melhor solução. Talvez seja melhor resolvê-lo com uma experiência de utilizador melhor, uma integração inicial melhor ou a correção de outro processo que esteja a falhar. Ou talvez seja melhor utilizar uma versão determinística e mais simples da tecnologia, porque a IA seria excessiva.

A terceira possibilidade é o melhor cenário: encontram um problema real em que a IA desbloqueia algo novo. Isso é extraordinário e é aí que a inovação realmente acontece. Na Amazon, uma das coisas que fazemos de forma conhecida é o processo de trabalhar de trás para a frente, em que escrevemos um comunicado de imprensa.

Peço aos meus gestores de produto, ou aos colegas com quem estou a trabalhar, que escrevam efetivamente um comunicado de imprensa para o produto. Têm de falar sobre o impacto do produto e talvez incluir um testemunho de um utilizador. É muito difícil fingir que algo é extraordinário quando se passa por esse exercício. Acho que isso tem sido muito útil para orientar essas conversas.

Também haverá momentos em que a decisão vem de cima, por exemplo, quando o diretor de tecnologia decidiu. É muito difícil ir ter com um diretor de tecnologia e discutir contra essa decisão. Nesses casos, aprendi a reformular a questão: muito bem, se vamos fazer isto, vamos pelo menos fazê-lo de uma forma útil. Vamos encontrar e resolver um problema real, em vez de lutar contra este caso de utilização específico.

Assim, mudo o foco: isto é ótimo, mas existe outro problema em que poderia ser realmente útil. Temos os dados, temos um caso de utilização e o retorno do investimento. Trabalho todas essas propostas para dizer: sim, vamos utilizá-la, mas este problema é mais urgente do que aquele.

Estas são algumas técnicas que funcionaram comigo no início da carreira. Costumava pensar que o meu trabalho era proteger a visão do produto contra distrações. Agora percebo que o meu trabalho é canalizar a energia: aproveitar o entusiasmo pela nova tecnologia e orientá-lo para a utilizar da forma correta, sempre em direção a resultados que realmente importam.

O problema não é o entusiasmo; é perceber como canalizá-lo de uma forma útil para os utilizadores. Por isso, devemos regressar sempre aos primeiros princípios do produto: pensar no utilizador e no problema, em vez de começar pela tecnologia. Não começaríamos por dizer: hoje abri um documento do Word, o que devo escrever? Comecem por escrever qualquer coisa.

Galen Low: Onde está o Clippy quando precisamos dele? Penso sinceramente que isso foi uma aula magistral resumida sobre como lidar com a política de produto, porque considero a tua perspetiva sobre a função muito útil. Conheço muitas pessoas de produto e, enquanto pessoa de projetos, também me identifico com isso: sentes que és o guardião, a defesa.

És a pessoa que recua e aponta os problemas, que coloca as pessoas no seu lugar para podermos manter aquilo que nos propusemos fazer. Mas gosto muito da ideia de canalizar a energia, porque isso pode levar a bons resultados. Achei interessante o teu terceiro ponto: estamos a fazer isto; pelo menos vamos torná-lo útil.

Não é uma perspetiva que ouça muitas vezes, mas é refrescante e corresponde à forma como conheço as empresas. A qualquer escala, por vezes não temos escolha. E nem sempre tem de ser: vou obter essa decisão por escrito para poder dizer mais tarde que tinha razão. Também pode ser algo construtivo.

A energia pode trazer benefícios. Venho de uma área de design centrado nas pessoas, por isso fico sempre entusiasmado quando ouço pessoas a trazer a conversa de volta para o utilizador e para o seu benefício. É uma reformulação muito útil: que problema estamos a tentar resolver? E fazer com que também pensem nisso.

É até colaborativo. Em vez de uma postura defensiva e de tentar encontrar uma forma de dizer não através de jogos políticos, podemos raciocinar em conjunto e encontrar o melhor resultado. A propósito de resultados, vou roubar a ideia do comunicado de imprensa. É, sem dúvida, algo que fazemos quando trabalhamos de trás para a frente, mas não até ao ponto de chegarmos ao comunicado de imprensa. No entanto, é a forma máxima de descrever o que fizemos, porquê e qual foi o seu impacto.

Que ferramenta tão útil para levar as pessoas a pensar no resultado, e não apenas em lançar algo. Não se trata apenas de receber ordens e concluir o trabalho, mas de imaginar o resultado que queremos alcançar. O que vai fazer pelas pessoas? Do que teremos orgulho em falar quando terminarmos? É muito interessante. Adoro.

Jyothi Nookula: Sim, adoro o conceito do comunicado de imprensa. Sempre o utilizei, mesmo depois de sair da AWS, há muitos anos. Continuo a utilizá-lo no meu trabalho. Traz uma perspetiva muito útil.

Galen Low: Adoro. É muito útil.

Perguntava-me se poderíamos terminar falando um pouco sobre o futuro, porque penso que, ao longo desta conversa, ficou bastante claro que a área da gestão de produto está a mudar bastante. Os próprios produtos estão a mudar, as ferramentas e os métodos estão a mudar e as expectativas relativamente à compreensão técnica, à compreensão do negócio e à estratégia de entrega também estão a mudar.

Quais são as três ou quatro principais coisas que um gestor de produto interessado em desenvolver produtos de IA precisa de ter no currículo ou no portefólio para se destacar?

Jyothi Nookula: Obrigada por fazeres esta pergunta, porque é uma questão muito prática. Honestamente, aquilo que procuro num currículo mudou drasticamente nos últimos dois anos.

É isto que atualmente faz alguém destacar-se. Primeiro, provas de que construiu algo com IA, e não apenas falou sobre isso. Enquanto gestora de contratação ou recrutadora, tenho uma posição para preencher. Não estou à procura de um espaço de investigação. Quero ver que a pessoa lançou efetivamente uma funcionalidade ou produto nativo de IA.

Não algo como: trabalhei numa equipa que utilizava IA ou contribuí para uma estratégia. Quero saber que problema estava a resolver com esse produto de IA, o que é que a IA fazia efetivamente, como avaliou o resultado e que aprendizagens o surpreenderam. Para quem já lançou produtos de IA, isto faz sentido.

Mas muitas pessoas ainda não lançaram produtos de IA e perguntam como podem comunicar essa experiência. É por isso que digo: criem algo. Alguns projetos pessoais. É algo que também digo nas minhas aulas, onde fazemos muitos projetos práticos. No final, os alunos constroem efetivamente um portefólio completo.

Digo-lhes para não começarem por tratá-los como simples projetos; têm de os transformar em produtos. Não é terminar, fechar o computador e ir embora. Isso é um projeto. É preciso convertê-lo num produto, partilhá-lo com amigos e com a comunidade e fazer com que as pessoas o utilizem.

Peçam-lhes feedback e depois melhorem o produto com base nesse feedback. Talvez possam adicionar uma integração com o Stripe e cobrar um euro ou 50 cêntimos — não importa — mas transformem-no num produto que gere receitas. Se for esse o modelo do vosso produto, convertam-no num produto tão próximo quanto possível de um produto real. Isso terá muito mais impacto no currículo do que simplesmente dizer que trabalharam num projeto de IA.

É preciso criar produtos, seja no trabalho ou fora dele. A segunda coisa importante é demonstrar fluência técnica. Não é necessário ser engenheiro de aprendizagem automática. Não preciso que saibam programar, mas preciso de ver provas de que conseguem ter conversas credíveis com engenheiros sobre o funcionamento destes sistemas.

No currículo, isto pode surgir como estruturas de avaliação que utilizaram, se fizeram testes mais abrangentes ou quais foram as decisões de compromisso que tiveram de tomar. Latência versus qualidade, custo versus capacidade ou tipos específicos de modelos e arquiteturas com que trabalharam.

A linguagem utilizada é importante. Se o currículo disser: utilizo IA para melhorar a experiência do utilizador, isso não me diz nada. Mas, se disser: criámos esta arquitetura RAG para reduzir alucinações nas respostas de apoio ao cliente e melhorámos a precisão de X para Y, então sei o que está a ser construído.

O teste que costumo utilizar é: consegue explicar a um engenheiro por que razão devemos utilizar a técnica A em vez da técnica B neste caso de utilização? E consegue explicar a uma parte interessada do negócio por que razão essa decisão técnica é importante e como afeta os resultados empresariais?

Enquanto gestor de produto, está na interseção entre estas áreas. A sua principal função é traduzir possibilidades técnicas em resultados e valor para o negócio e converter isso novamente em estruturas técnicas. É esse o gestor de produto de IA que tem melhor desempenho.

Por último, é importante ter experiência a lidar com a ambiguidade e com esta iteração rápida. Como já disse, os produtos de IA são diferentes. Os modelos são atualizados e as capacidades evoluem, por isso é necessário sentir-se confortável com a ambiguidade, e isso deve aparecer no currículo.

Por exemplo, se me disser que lançou produtos do zero em ambientes de ritmo acelerado, isso diz-me que teve de lidar com a ambiguidade. Ou, se demonstrar uma mentalidade de experimentação, com prototipagem, testes e aprendizagem rápidos, mesmo nos projetos pessoais que transformou em produtos, é aí que tudo começa a tomar forma.

Estas são algumas capacidades que penso que farão alguém destacar-se ou ajudarão os candidatos a destacar-se. O que definitivamente não procuro é uma sopa de palavras-chave.

Não preciso que ninguém diga: utilizo aprendizagem automática para criar sinergias e otimizar processos. Isso não me diz nada. Também não é necessário fazer seis certificações diferentes no Coursera ou dizer que se é apaixonado por IA. Essas coisas não farão alguém destacar-se.

Se tiver de indicar um padrão, é a velocidade de aprendizagem. Com que rapidez consegue avançar? Até que profundidade técnica consegue chegar? Compreende como estes sistemas funcionam em conjunto? Se está a tentar entrar na gestão de produtos de IA e não tem experiência direta, pode criá-la. Pode construir algo. Ninguém o impede de construir.

Não há problema se o seu trabalho não lhe oferece oportunidades relacionadas com IA, mas ninguém o impede de construir algo. Também pode escrever sobre aquilo que está a aprender enquanto constrói. Existem muitos desafios quando se começa a criar.

Contribua, crie estudos de caso sobre produtos de IA que admire, faça análises detalhadas e descubra como os melhoraria. A barreira de entrada é agora muito baixa. Não é necessário ter um orçamento enorme para desenvolver uma ideia.

Além disso, na indústria, poucas pessoas têm 10 anos de experiência em IA. Estamos todos a tentar perceber as coisas em conjunto. O que realmente distingue as pessoas é o facto de estarem efetivamente a fazer o trabalho necessário para descobrir como tudo funciona, em vez de esperarem por autorização.

Galen Low: Foi uma descrição tão boa desse dilema. Tenho a certeza de que ouves isto constantemente: mas sou gestor de produto; não devia ser esperado que programasse.

Existe, contudo, uma camada intermédia, e penso que a explicaste muito bem. Talvez não seja necessário programar, mas é preciso ter o vocabulário para fazer esta tradução, compreender as necessidades do negócio e dos utilizadores e perceber as implicações técnicas.

Também é necessário ter uma mentalidade de construtor, compreendendo suficientemente a tecnologia para saber onde existem pontos de fricção e o que pode correr mal. Não basta dizer: fiz aquilo que me mandaram enquanto trabalhava numa grande empresa de tecnologia. Por isso, sou uma boa contratação.

Como disseste, enquanto gestor de contratação, não faço ideia se essa pessoa consegue atravessar a ambiguidade, se compreende o utilizador ou se consegue falar a linguagem das equipas multifuncionais com que vai trabalhar.

Tudo o que sei é que trabalhou numa grande empresa X numa determinada função. Pode simplesmente ter seguido a liderança de outra pessoa, sem necessariamente ser ousada, aprender rapidamente e ter a velocidade e a abertura necessárias para se envolver com a tecnologia e deixar que ela melhore o seu trabalho, em vez de pensar que esse é o problema de outra pessoa.

Jyothi Nookula: É por isso que digo: não esperem por autorização, façam simplesmente. A barreira de entrada é agora muito baixa para experimentar.

Galen Low: Jyothi, muito obrigado pelo tempo que passaste comigo hoje. Foi muito divertido. Antes de te deixar ir, onde é que as pessoas podem saber mais sobre ti?

Jyothi Nookula: Podem encontrar-me no LinkedIn, procurando por Jyothi Nookula. Também podem visitar nextgenproductmanager.com, onde podem saber mais sobre os cursos que disponibilizo nas áreas de gestão de produtos de IA, IA com agentes e PM Accelerator.

Galen Low: Fantástico. Também vou incluir essas ligações nas notas do programa para quem estiver a ouvir ou na descrição para quem estiver a ver. Jyothi, mais uma vez, muito obrigado.

Jyothi Nookula: Muito obrigada. Diverti-me imenso.

Galen Low: Muito bem, pessoal, é tudo por hoje no episódio do podcast The Digital Project Manager. Se gostaram desta conversa, subscrevam o programa na plataforma onde estiverem a ouvir. E, se quiserem ainda mais ideias práticas, estudos de caso e guias de execução, visitem thedigitalprojectmanager.com. Até à próxima, obrigado por ouvirem.